Managing up
The most important thing no one will teach you
I’ve been working in delivery type roles for the best part of a decade now so I’ve attended my fair share of training courses, conferences and seminars extolling the virtues of agile software development.
Over the same period I’ve had a few different job titles Project Manager, Agile Project Manager, Scrum Master and Product Owner¹. Regardless of my title I’ve always felt that my job boiled down to more or less the same three things:
- Getting clear objectives from the business
- Articulating the objectives in a useful way to the delivery team
- Making sure the delivery team has the time and resource to meet the objectives
One and three on this list are both aspects of the same thing, namely, good management of people who out rank you in the organisation. Unless you’re the CEO of your own company² then one or more people higher up the food chain will be setting your objectives and deciding how much time and resource your team gets to achieve them. Now to be clear, when I say managing up I don’t literally mean telling these people what they should be doing³, I mean managing their expectations and managing their interactions with the delivery team.
I can’t speak for anybody else, but this has been the reality of my professional existence for the past decade. Despite this, I’ve never heard it discussed or explained at any of the training, conferences or seminars that I’ve been to⁴. I don’t know what the reasons for this are, because it seems to me that doing it well is the single biggest service you can provide for your team. In fact it’s the key to unlocking a virtuous circle of delivery:
The Virtuous Circle of Managing Up
- Managing senior people well will earn their trust
- Earning the trust of senior people will make it easier to effectively manage the workload of your team
- Effectively managing the workload of your team will allow them to deliver more
- The more your team delivers, the more senior people will trust you
- The more senior people trust you, the more independent decision making power you and your team will have
- Wielded responsibly, more independent decision making power will let your team deliver more
- The more your team delivers, the more senior people will trust you….
…and so on.
Now to be fair, this begs the question ‘how do you manage senior people well?’⁵, to which I say, read on.
Managing Senior People Well
Listen and Repeat
Your most senior stakeholder should be the person that sets the overall business strategy that you and your team are working towards. The headline for this will probably be something fairly big and abstract like ‘provide the best customer experience in our industry’ or ‘make our internal business processes more efficient’. Regardless of what it is, you need to show that you understand what it is and why it’s important to the business. The best way to do this is to explain how any big new piece of work you propose ties in to the wider business strategy.
Provide Structure
This applies in a couple of ways.
One, senior people are generally busy people, so your time with them will usually be limited. Therefore you should always think carefully in advance about what it is you want to discuss, and how you want to present it. The what should be the same in most situations, if there is an important decision you need them to make that should always be the main agenda item, as it might be the only thing you get to discuss. Anything over an above that should be arranged in priority order, that way you are getting the most value out of their time. Controlling the agenda this way might feel presumptuous at first, but it means that the most important decisions will get made in a timely way, which will ultimately improve the teams ability to deliver.
Two, you need to provide structure by managing the interactions of senior people with the delivery team. There are any number of reasons why a senior person in your organisation might want to be a bit more hands on with a delivery team, some of them will be legitimate, but what you cannot allow them to do is levy tasks on developers directly, or make changes to scope without consulting you, the person responsible for delivery. This is a bit more difficult than number one, and needs to be handled tactfully. The best thing to do in my experience is to set up a regular tactical meeting with senior people who need it, and invite a senior developer. This allows the senior the oversight they need, and the presence of the senior developer allows things to be discussed in a little more depth, while allowing the majority of the team to get on with their work.
Be Neutral not Passive
Again, there are a couple of scenarios where this applies.
One, if there is disagreement about priorities among senior people that is blocking your teams progress then you need to resolve it. The best thing you can do is to state clearly to the relevant parties what you understand the substance of the disagreement to be, and provide an as unbiased as possible cost/benefit analysis of both sides of it, and make it clear that a decision is required for work to progress. We’re all human, so you will probably have a personal preference for one option or other, but in the long run it’s best not to pick sides⁶.
Two, catastrophes happen, priorities change, a black swan lands in your front garden and turns the world upside down. The whole point of working in an agile manner is that it’s supposed to allow us to respond to unforeseen circumstances. However, senior people may well ask you to change tack at a moment you think is inopportune. In a sense this is fair enough, as they out rank you and therefore have larger concerns than you do, and they may even be right. However, if you’re not convinced by their reasoning then the best thing to do is to clearly layout the consequences of an immediate change of course on the rest of the teams work. Do this as dispassionately as possible, and then ask them if they still want to go ahead. If they do, then fine, because they now know the price that is being paid, but most of the time this will lead to a sensible compromise that you can both be happy with.
In both of these cases you’re being neutral, because you’re not advocating a particular course of action. However, you are not being passive, because the action you take is resolving an impasse that has the potential to inhibit the teams progress.
Under Promise/Over deliver
In my experience, technical people are terrible at estimating their own work⁷. Never, ever, share a techies most optimistic estimate on its own with senior stakeholders⁸, because it will almost certainly be wrong, and give them a false confidence about delivery time scales.
It is obviously reasonable for seniors to ask for this sort of information, so you should be willing to provide them with it in an appropriately contextualised format. A bit of old school project management does not hurt here, estimates should be given as a range from pessimistic to optimistic, and any uncertainty in them called out explicitly. This may not be very agile, but it is sensible.
The same thing is true of scope. Naturally enough, people want as much as they can, as quickly as they can get it. You need to persuade senior stakeholders that the best way to do this is to get an MVP into the hands of users and iterate from there, which is true, very agile, and indeed sensible. The best way of doing this is to demonstrate it, the first phase of any agile project is a mini waterfall anyway, so if referring to it in more waterfall friendly language makes them more comfortable then just do that, it doesn’t cost you anything. Other means of persuasion will very much depend on the specifics of you relationship with the senior people in question, but I’m afraid this kind of is ‘a hill you need to die on’ situation, so use whatever sensible means you have to hand.
Footnotes:
¹Yes the first two are basically the same, but y’know, fashion.
² In which case, well done you. Though you probably don’t want to waste your time reading the rest of this, but feel free to share it on twitter or whatever and talk about how great it is.
³ I have tried this. It does not end well.
⁴Maybe I’ve been going to the wrong ones or have just not paying attention, so if anyone reading this has suggestions for further learning on this topic I’m happy to hear them.
⁵ And also ‘how do you effectively manage a teams workload?’ and ‘how do you wield independent decision making power responsibly?’. But the former gets talked about A LOT at the aforementioned training, conferences and seminars, and the latter is too difficult so we’ll save that for another day.
⁶ I have tried this. It does not end well.
⁷ I’m sorry, but you are.
⁸ I have tried this. It does not end well.
