Trials and Tribulations of a Test Manager (Part IV)

You may want to read Trials and Tribulations of a Test Manager (Part III) if you haven't done so already.


The stuff they didn’t tell you about when you got the job

Some of the most challenging and tragic but also some absolutely hilarious things happened in this category. Some were sort of harmless where I found out some time after I started that the Test Manager job meant that I’m also expected to take the role as the Environment and Configuration Manager for the test environments at least.

Some examples of the more serious situations were that I had people come to me telling me they’ve been diagnosed to be bipolar; partners with failing kidneys; alcoholics; parents in hospital with live threatening illnesses; current divorce proceedings and the list goes on. At times like these the people approaching me were usually quite vulnerable. So while knowing that the next project will surely be impacted by sometimes grave news what they want to hear is that I’m taking care of the business side and say “Don’t you worry, I’ll take care of the work side, how can I help you – do you need time off, flexible working, etc?”

I always gave people leeway in situations like these mostly because it’s the right thing to do and I would like to be greeted by understanding from my line manager myself. But at the end of the day there isn’t really an alternative. Under pressure people will put their personal interests above the company anyway. Sometimes without knowing, sometimes with full understanding they don’t really ask for permission for time off / flexible working hours / understanding/ etc. They are only letting me know that their work will be impacted for some time. They do the right thing and expect the same in return.

Once they get a positive response it usually makes their lives a bit easier with one thing less to worry about. I had several instances where people then put in double the amount of effort and working hours once the situation was resolved, far in excess of what they took in the first place. Sometimes HR needs to be involved, sometimes it was fine to deal with it myself depending on the situation.

I worked in multicultural teams and what one perceives to be a joke can be an insult to the next. Careful explaining and setting of boundaries of what’s allowed and where the no man’s land begins becomes very important here. Sexual harassment, invoking grievance policies and offering a trip to the nearest dark alley are all part of this area which I have been lucky enough to diffuse before anything too serious happened.

Something related which tended to be between hilarious and so far out there that it stretched my years of experience to the extreme are what I call the “Rammstein” jokers. (After the band – insult and make fun of everybody, no taboos but expect to get some feedback). How do you react if someone sends an email round to the team saying something along the lines of “Peter is OK but he smells a bit this morning, probably borrowed his wife’s perfume again. I worry more about John who got out his thing under the table again, talks to it a bit in a Gollum voice and then looks at ‘hoff pictures.” (Names and wording changed but that email happened...) In these cases it’s either a “Thank you for working for us, don’t bother logging off. Let me escort you out of the building.” Or seeing how the rest of the team handles it, have a quiet word with the author and then take it from there.

I hope you enjoyed the musings of my last few years as a Test Manager. It was an interesting experience and I like to manage teams. There’s always something new, exciting and sometimes unexpected to learn and I hope I gave something in return. 

Thanks for reading.

Trials and Tribulations of a Test Manager (Part III)

You may want to read Trials and Tribulations of a Test Manager (Part II) if you haven't done so already.

The Test Manager as a company approach

A Test Manager (or Development Manager or any other type of Manager with line management responsibilities and a certain degree of freedom and responsibility) usually has roles that reflect the whole company. This allegory works best for people who lead a team or department.

She would be the CEO, expected to prepare a vision for her team and provide guidance; the CTO to provide the technical vision and advise on which technology path is suitable to follow and which isn’t; the Finance section for keeping track of budgets; HR for hiring and firing people and providing guidance about policies in the company and so on.

So in very many ways a Manager is a company acting in a Micro-cosmos in their own little world. Of course the good ones make sure it fits with the Macro-cosmos of the outside world.

Not every Manager can be good at everything so what are you going to do about it? Delegate or get train yourself in the weak areas? This is very much a personal and context question which I can’t really answer here, it’s only there to remind us that the day to day tasks not necessarily encompass everything a Test Manager is responsible for and that some time and thought may need to go in these areas as we tend to forget about the things that we’re not so comfortable with.

One role that I haven’t mentioned above is that of a trainer. If I want to train, coach and mentor I should know a thing or two about the area in question. So everyday learning is a must in my opinion. This does not mean that I’m reading a testing book or internet articles every day although I try – often live interferes. Some days I learn a lot just by talking to colleagues, how they approach a particular problem and how their experiences play a part in that. Sometimes I learn how to do something, sometimes how not to. But it’s all useful, one way or another.

One thing that should be pretty clear is that you can’t manage what you don’t know. If you rely on reports about how the team is doing a lot is lost in translation. If the Test Manager and the Test team are located in the same building there shouldn’t be any excuse for the Test Manager NOT to sit with the team. That private office may look fancier and more comfortable but you could just as well sitting in another country. All the day to day problems, friendly banter and everything that makes up that team will be lost to the manager. In short, co-location with the team is a must, otherwise the Manager will not properly understand the problems that the team is facing. If the Manager doesn’t know where the rocks on the road to success are he can’t remove them.

It works the other way round as well. The team sees the problems and challenges and work that the Test Manager does. Overhearing discussions I had with dev managers, sys admins, etc has helped my team understand what’s expected from their manager so they could work toward helping towards these goals. When sitting with the team any small problems can be nipped in the bud before they become serious problems. Morale issues can be spotted early before they become serious problems. If there are talks that need to be had without the team that’s what meetings rooms are for. Letting people overhear all discussions also fosters an atmosphere of openness. It's saying “see I have nothing to hide” and we're all heading in the same direction.

Read on in the final chapter of Trials and Tribulations of a Test Manager (Part IV) coming soon.

Trials and Tribulations of a Test Manager (Part II)

You may want to read Trials and Tribulations of a Test Manager (Part I) if you haven't done so already.


The Shield, the Sword and the Horn of Met

In my experience one of the most important functions of any Team Leader is that they can shield their team and make sure all the rubbish and rotten tomatoes coming flying don’t hit them. The importance of that can’t be overemphasized from my point of view. If the Team Leader is seen to put his money where his mouth is in protecting the team from external distractions they will rally when called upon.

As an ex-Manager of mine once said “Get them to work for you, not for the company. Sooner or later the business will do something that will disappoint them. But if they work for you they will do their best because they don’t want to let you down, even if they’re unhappy with the company.”

I’ve been in both camps in my working live and can say it’s a lot easier to work at a place where this Shield is in place. It breeds mutual respect and is in very many ways the return to the tribal society.

If any threats to the team are swiftly intercepted and struck down it also sends a message to people outside the team– don’t mess with these guys. They’re a professional bunch and we don’t tolerate substandard behavior. Saying “no” for matters concerning the team sets boundaries for the behavior that the manager sees as acceptable. Precedence is created.

Something else I learned from an ex-Manager is that the team manager is not there to do the hands on work although it doesn’t hurt if they can jump in when necessary. The main goal for the team manager is to remove the rocks on the way and make sure that there is nothing impeding or slowing them down. Only if everyone in the team can work unobstructed should the team manager look at their own work tasks.

I can’t count how many times I got absolutely invaluable information about problems in the team or company in the pub. A week or two after joining I went out with the team for a drink and learned more there in two hours than in the weeks before. Things that people genuinely cared about or that upset them for one reason or other came to light in a more relaxed atmosphere than the workplace. Having some distance between the manager and the team is fine. When it comes to the crunch the manager sticks their head out and take a decision. But being seen as part of the team is a must in my book. If people can’t see the real me behind the manager facade, how are they going to trust that I stand up for their interests?

Leading by example is not only old news it was ancient when dinosaurs roamed the earth. What it does for the team is manifold. It sets the boundaries of what is acceptable and what isn’t. If the Test Manager comes late and leaves early that will soon be copied. Is a two line bug report acceptable? Depends on the company, maybe a bit more information would be helpful. So logging bug reports as you’d like to see them done is a good way to lead by example. These reports can become the standard that everyone should be working towards. Same with many other small things, emails, written and verbal reporting, etc. Setting precedencies and explaining what the reasoning behind it is and why it’s important will help form a professional team that works as the Test Manager expects.

I’m not promoting the lone hero approach, far from it. In order to get a team into shape you need people to help you. Someone who has seen the light and believes your approach is the right thing to do. The video Leadership Lessons from the dancing guy makes it clearer than I could do. It's been around for quite a while and is worth a look.

If you can get some momentum going with the help of a believer from within the group it will go a long way to building a successful team.

Read on in Trials and Tribulations of a Test Manager (Part III).

Trials and Tribulations of a Test Manager (Part I)

It’s been a while since I last wrote here but I was busy moving country and jobs again. I left Gibraltar behind and am now back in Germany in my home town but that’s a different story..

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.

Read on in Trials and Tribulations of a Test Manager (Part II).