by Ben Kelly
When I was learning the ropes as a tester, I'd go to my manager when I was blocked. As far as I was concerned, it was their job to do whatever necessary to allow me to focus on mine.
If I didn't need anything from them, I really just wanted them to leave me alone so I could get on with it. Frustratingly, the opposite seemed to happen. Almost daily, conversations would go something along the lines of:
'Hey Ben, how's the testing coming along?'
'Yeah, good'.
<awkward silence>
<manager goes away>
<my inbox pings with a meeting invitation to talk about testing progress>
I reckon I might not have been the only one frustrated by that exchange. Clearly my boss wanted something. I just didn't know what. Probably to check up on me and make sure I was still doing my job. If I'm honest, I didn't really care if it was that or something else. I was focused on the important stuff. I spent most of my time thinking about my project and what I needed to do to help make it successful. For me, that involved getting my hands dirty with the code, writing some unit tests here and there, code reviews, exploratory testing, critiquing requirements, talking to programmers, designers and so on. Stuff that really mattered (also, quite coincidentally, the stuff that was fun). Most of my reporting was verbal either to the programmers themselves or to the project manager at the time. Very little communication to my direct manager. I simply didn't see the point.
I told you, we're an anarcho-syndicalist commune...
Harry Collins coined a term 'interactional expertise'. In layman's terms, it's the ability to understand a particular role or skill or vocation, without necessarily being able to perform it. Talking the talk, but not necessarily walking the walk, as it were. This is not a process you can set out and follow. These are tacit skills that you acquire through interaction.
When you work with a good cross-functional team, there's a lingua franca that develops over time as you learn more about each other's craft. It's not just a common communication interface though. The team builds a common history and trust, learns each other's strengths and weaknesses and what each other values. The strength of those relationships allow you to influence the team. You know when to call on each other for help. Perhaps as importantly, you can argue for change or call the team out and be heard when there's an issue. This sort of influence is leadership without being in a leadership position.
I established a strong rapport with my programming and UX teammates and the PM -- the people on my project. They were peers. They were like me. Working to achieve the same goal. My manager however, was a different story. Part of 'the establishment'. To me, my manager was part of the hierarchy that companies seemed to need to prevent the inmates from running the asylum. Of all the relationships I had at work, the one with my manager was the one I spent the least time on.
Upstairs and Downstairs
It wasn't until I myself became a manager, when the shoe was firmly on the other foot that I realised my folly. Being a newly minted manager was terrifying. I'd gone from individual contributor dealing with tech problems on a single project to manager dealing with multiple projects, different people at different levels, wanting different (often conflicting) things. I was working in a system that wasn't so much designed as it was organically grown. Different bits served different people and I needed to figure out where I fit and how to operate.
Far from being 'part of the establishment', I realised my manager was in the same boat, only now was I beginning to grasp the sheer amount of stuff he had been dealing with. This was a completely different skill set to the one I was used to and one I'd completely failed to comprehend as an individual contributor. The stuff he was asking me and the frequency with which he'd asked -- the stuff I was now asking my people about, wasn't to check up on me and make sure I was working. It was so he could make informed decisions about the stuff he was trying to get done and to my embarrassment, I realised I'd totally dropped the ball in helping that to happen.
As a manager, it can be incredibly time consuming to go to your directs to pull information from them. I've found that if instead they push information to me on a regular basis, then that can help to amplify my effectiveness. If I can see at a high level what is going on with my people, I can understand where to focus the team's efforts, look at trade-offs, have important conversations that I might not be so well equipped for if I didn't have that information.
Effectiveness as a tester comes back to your ability to not just think critically and conduct experiments, but as importantly to report what you're doing in a way that's meaningful to your audience. Fundamentals of testing -- Know who your audience is and what is important to them. If you can do that for the project you're working on, that's a solid start. You can take it a step further.
- Look at how what you're working on fits into the bigger picture. That includes understanding and managing the expectations of your manager.
- What do they expect from you and vice versa?
- What do you need from them and vice versa.
- What conversations do you have with them?
- What information do you supply them?
- What format?
- How often?
This is part of managing up.
It's an easy enough concept to grasp. More difficult to put into practice. It involves you being able to see the world from their perspective, to understand what their concerns are and what information you have (or can get) that addresses them.
Oh Captain, My Captain - Changing your perspective
That might mean quite a big shift in how you think. As an individual contributor I was thinking about tactical execution of a project. In order to land a given project successfully, I need to take certain actions. Review specs, exercise the system under test, talk to people. There was some strategy involved, but confined to the realms of working out what action to take in service of the project.
My manager's thinking was predominantly strategic, counting on me and other senior people in the tech department to handle the tactics. He was less interested in the evolution of the page object model framework I was building, but more interested in the couple of potential showstoppers we found that week and how it might significantly delay the project. There were other projects waiting to kick off (or indeed, progressing without our input).
- Was that more of a risk than keeping testers on the current project?
- Did my manager need to raise one or both of these things to his peers or the CTO or both?
- Was this a one-off crunch period or a regular occurrence?
- Did we need to hire more people?
- Suspend a project?
- Reexamine how we were putting projects together?
- A combination of the above?
These are questions that my day to day work had a bearing on, but I had no real visibility into because I didn't spend much time talking to my manager. It wasn't my job to think about this stuff. Of course, if I had thought about this stuff, or at the very least been aware that these were the things my manager was thinking about, then I could have been useful beyond the sphere of the project I was working on. This is part of 'managing up'. Making sure your boss has what they need not only to support you, but to support the wider decisions they're trying to make.
The same goes for when there are things you need from your manager:
- Are there things that you really think are important to focus your time on right now?
- What can you do to explain that in a way that makes it important to your manager as well?
- What's the payoff for spending that time?
- What's the risk if you don't?
- What's the opportunity cost (what are you choosing not to do)?
On paper decisions tend to flow from top to bottom. In reality information and influence flow in many different directions, particularly for software testers. You don't have to be 'the decision maker' to influence decisions.You might not have a test manager. Plenty of shops don't these days, but the the same applies for your team leader, or community of practice lead or whomever your line manager may be. You don't have to be a manager to be a leader. You can influence change through the strength of your relationships including the relationship with your line manager.
So how do you manage up?
- If you're not already doing so, set up a time to speak regularly with your manager.
- Take notice of what information they ask you for.
- Talk with them about how and why that's valuable for them.
- What format is useful. A weekly email? An occasional drive-by verbal report? Something more comprehensive?
- What are the big moving pieces?
- What is the strategy they're working to.
- Where does your piece fit in.
- How are you measured?
- How are they measured? (Are there any conflicts there?)
- Take a look at who they meet with on a regular basis.
- Can you provide them with something pertinent?
Over time you may find you're able to anticipate their needs before they ask. You'll build a reputation as someone who is effective because beyond dotting the i's and crossing the t's on your own work, you have an eye on the bigger picture. Make this a habit and you'll likely find all sorts of opportunities open up.
Further Reading:
- Tacit and Explicit Knowledge - Harry Collins
About Ben Kelly
Ben is a software testing politician working at eBay in London. If his career in testing was a human, it would be eligible to have a driving licence (but not to buy alcohol which, let's face it is probably for the best). Over the past few years he has led both development and testing teams at eBay and currently runs the Software Heuristic Investigation Exploration and Local expertise Division (or S.H.I.E.L.D. if you like). Prior to that he has worked in a number of industries (internet statistics, e-commerce, insurance, e-learning) and a number of countries (Australia, Japan and the UK). Ben is a board member of the International Society for Software Testing (ISST), a regular speaker at conferences worldwide and sporadically blogs at testjutsu.com.
