Johanna Rothman: Life as a New Test Manager

Life as a New Test Manager

© 1999 Johanna Rothman

These notes represent the opinions of the BOF attendees. Where I couldn't resist, I added my comments.

We had about 50-60 people attending the BOF. Demographics were:

Currently a manager: most
1 year or less management experience: 10
1-5 years of experience: 12
> 5 years experience: a few

We discussed what we would talk about:

Subject Interest level
Power and Influence in the Organization higher
What do I do moderate
How much testing do I do? lower
Balance freedom vs. guidance and coaching of staff higher
Make people thinkit was their idea moderate
tracking tasks and juggling moderate
Get technical people to test vs. develop, including keeping people in test and keeping people in the company lower
recruiting moderate
motivate people who need to do better higher
performance assessment moderate
justifying and determining size of testing effort lower
Influence

* Interpersonal skills required!
* Negotiation
* Get a track record
o Start small
o Get data
* Organizational agreement
o What is test's role?
o Be part of the lifecycle
o But how to get management's attention?
+ Data
+ Terse text (JR note: I think this is where I said senior managers prefer to read bullets and graphs to prose)
* Need to understand the project cube of time-to-market, cost-to-market, functionality, defects (JR adds the people and the work environment)
*
* One must be flexible
* Do quick project retrospectives
* Disasters catch attention
o "Significant emotional event"
* Demonstrate influence on the bottom line
* Logic, Pilot, Challenge ("I dare you"), Shame and Guilt ("xxx does this")
* Continuous communication upwards
o Be in their face
o Continuous mindshare
o Before the test plan
* "Hiring us was your idea"
* "Why? What risks do you see?"
* Talk about risk of features and cost of testing
* We asked about attendee's peers:
o More experience than you (some, small number)
o Do they have an effect on your influence (mixed results)

We talked about influence issues for about 45 minutes, and started talking about trust. If you're not trusted in the organization, how can you get things done?
Trust

* Hard due to the nature of the job
o Find errors in development work
o See Brian Marick's paper, "Working Effectively With Developers" about one way to work with developers
* Establishing credibility vs. being some kind of expert
* Write good bug reports. Make them complete
* Defer to developer expertise (but ask questions
* Remind development: "I'm on your side"
* Target major issues, not minor (in development experience)
* Know end user - specialty
* Don't feel moral superiority over development. Sometimes the problem is us.
* Help them specify
* Feed them
* Pair new tester with developer to help with developer testing and learn something about developer's code
* Your staff reviews you
o Skip level reviews (your manager talks to your reports)
o Managers are judged by the people in the team

Freedom to do the job vs. coaching

* Don't wait too long to look
* Hiring people hurts overall performance
* Dealing with passive/aggressive
o Challenge them, make them step up, set expectations
o Listen to them
* Structure communications
o Give freedom within bounds
* Be clear about goals. All else is situational.
* Status report contents
o Planned work done
o Planned work not done
o Unplanned work done
o Planned work going forward
* Look at strength of whole department
o Buddy systems work
o Brian's pointer on the web to a live example of programming pairs: http://www.armaties.com/Practices/PracPairs.html (this link seems to be broken, 7/29/02 -- JR)
* Meet with your staff 5-10 minutes every morning, on their schedule
* 1/2 hour one-on-one weekly
o How much should you prepare in advance. (JR's opinion: Your staff should know what to expect, but leave time for them to bring up issues)
o Encourage your staff to know you
o They own their careers, you're their to mentor them and remove obstacles
* Weekly report (learn how to estimate)
o Objectives
o Planned date of completion vs. actuals. Learn from these as they become actuals.
* Sometimes it's the little things that count
o Get staplers
o Buy lunch
* Find opportunities for your staff to do what they don't know they'll enjoy

Dealing with Shortfalls (of resources)

* How do you quantify your work?
* Make visible work that will be done and won't be done
o Give a choice
* Convincing management there is a shortfall:
o Work out what last project's decisions cost (in engineer years converted to dollars). Now what do you want to do?
o What does customer support cost you? Where are the problems. Now what do you want to do?
* Recruit developers to expensively do what testers are cheaper at. Now what do you want to do?

When you have too many direct reports

* Break into teams of 4 or less (JR says 6 or less)
* Learn from general management literature
o Jon Hagar's list
+ Competitive Advantage, Michael Porter - pretty dry but a good approach to evaluating competition, markets, etc in order to create a competitive advantage; I think the concepts can be applied to an organization as well as a company
+ Danger in the Comfort Zone, Judith Bardwick - changing demographics and attitudes that affect productivity
+ Lean Thinking, Womack and Jones - Getting big companies to the right size
+ Getting to Yes, Fisher and Ury - opening negotiation options rather than closing them down, applies to more than just contract negotiations
+ Crossing the Chasm, Moore - marketing and selling technology products to mainstream
+ Type Talk, Kroeger and Thuesen - understanding differences in people and how they can affect the work environment - applies to understanding self and how you work/are perceived by others as well as understanding those you work with/for/over
+ Managing for results, Drucker - good intro book to management issues (he has other books)
+ Passion for excellence, Peters and Austin - a little dated given how American industry has transformed itself, but still applicable
+ The New Rational Manager - Kepner and Tregoe - great book on risk management and problem solving
+ Good Authors:
# Jack Stack - teach everyone from the stockroom employee up how to read financials and to understand how what they did contributed to the bottom line.
# Deming - I think everyone should read his "rules" list
o Anything from Peter Drucker, especially The Effective Executive and Managing for Results
o Watts Humphrey, Managing Technical People
o Steve McConnell, Rapid Development
o Steve Maguire, Debugging the Development Process
o Ken Blanchard, The One Minute Manager

Taking over a group

* Sit back
* Spend a lot of time listening
* Remove obstacles
* Ask what can change, help it happen
* Give credit to people

Who's Your Successor?

* If you don't have someone to succeed you, you're stuck



Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.