Let’s share the experience
I’ve been thinking about Test Management and Management in general a lot in the last couple of months having observed both the good, the bad and the downright ugly approaches. Stuart Reid in the Foreword to Essential Test Design from Torbjörn Ryber says “… I would argue that the majority of software testing problems stem from poor test management …”. I’m sure that context dictates what the majority would be and that it depends on how it’s measured but I agree with the sentiment – that test approach, process, technology and technique all have a role to play but that good or bad management will dictate for many a project if it succeeds or fails (This is also true for work done outside a project).
A couple of weeks ago I had chat with a colleague from another department about my test team. He told me that he and others wished they could be part of that team – not because they wanted to test but because they wanted a part of that team spirit and ambience that comes with it. I was quite flustered – it was one of the nicest compliments I ever got as I put that team together. If people want to get in not because they like the work or pay but because it’s cool I must have done something right. I’ll try to put into words what I believe that is over the next few entries.
It’s all about connections man...
A Test Manager like everyone else in a company structure is a link in the chain of business responsibilities. There’s a link leading to your team and there’s a link towards Senior Management; and possibly several more to your peers (Having no identifiable peers is a sign something went wrong but that’s another story). If you consider yourself as a key ring to which many chains are attached that picture works best for what I’m trying to convey.
Each direction is a relationship with slightly different expectations and requirements at the end of it. My approach for each relationship in every direction in the past has been the same – read: show the same courtesy and listen to everyone about what their requirements are, no matter what their position. Each person at the end of the relationship chain has their own needs and requirements that I may be involved with. Some will be the same across all levels, others differ wildly from person to person.
Some want help with their career, others want to be left alone as there’s enough going on in their lives already. Some want gentle pushing some object violently. Some can be rewarded with money, others with flexible work hours, visits to conferences. A pat on the back when something was well done has never hurt and is the strongest reward that people will not ask for.
It helps to have worked in similar jobs comparable to that of the person at the end of each chain. In other words, if you worked in support before it’s easier to understand the needs and requirements of a support role. Imagine walking a mile in their shoes. That’s a bit harder if you look up at the food chain but as the requirements of the CTO or other Senior Managers become clearer building a team that can satisfy their high level goals becomes a lot easier.
If you haven’t worked in a comparable job before sit down with the person in question and ask them to tell you about what the tasks you just gave them means for them. Is it a 5 minute job? Is it a long nightmare tasks because of complications that you haven’t foreseen? Talk to them and say that you genuinely want to know. Of course it has to be heartfelt or that one backfires... A few months ago I asked for something that I considered to be a half hour job, restructuring some of our virtual machines and renaming some URLs. Turned out it would’ve been a week or more with serious impacts on another team. I sat down with the person that I requested it from and subsequently now know more about networks and VMs. These kind of sit downs were great learning experiences for me. Next time I won’t make this particular unreasonable request as my knowledge has increased.