The Negotiator
Despite what a younger me might have thought, planning is a key part in actually getting anything done. You need to have some idea about how you want things to shake out, or it's pretty unlikely that you'll achieve what you want to achieve.
Of course, no plan survives contact with the enemy, but that doesn't diminish the value in putting one together. Just don't get too attached to it.
Speaking of which, one of the many ways in which a plan can fall apart is when the people and teams you are relying on to do the work find themselves under pressure to do things other than the stuff you want them to do.
Which is where the bargaining begins.
You Working?
In my experience, the list of things that people want to get done is almost always bigger than the list of things that it is possible to actually deliver.
That means that there are always hard decisions to make about what will get focus and attention now vs what might get focus and attention later. I say might, because the next time planning conversations are had, the situation is likely to have changed, and everything will need to be re-evaluated through that new context.
When you only need to make these decisions in the context of a single team who is working towards a single goal, it's not too bad. At that point it's mostly about sequencing things in the right order, and even if you get it wrong, the ramifications generally aren't catastrophic.
That situation is pretty rare though.
Instead, it is far more common to have many teams, many goals and a complex web of relationships and dependencies between both, especially if you're working within even a medium sized business.
The bigger the business, the worse it gets, especially if you find yourself in a platform team, the titular centre of the spider's web.
All is not lost though.
Sort Of
The first rule in getting people and teams to do the things you want them to do is to understand the priority of everything that they could be doing, and to ensure that everyone else understands as well.
With a shared understanding of the priority of things in place, everyone can make informed decisions about what should be done with the limited capacity that is available.
One way to do this is to create a simple rubric that everyone agrees to use when thinking about priority and making decisions. Something like:
- Contributes to primary business goal
- Contributes to internal department goal
- Everything else
That sort of approach can get pretty muddy pretty quickly though, so a better way is to establish an actual priority classification system. Such a classification system needs to be supported by clear rules on how things should be classified, along with examples from known work that people can use to orient themselves. It also needs to be refreshed regularly, ideally every quarter or half, to ensure that it remains valid in the face of changing business circumstances.
A concrete way to do this is to establish a P level (like P0, P1, P2, etc), provide the necessary meta information along with each level and to document it all on a Confluence page (or equivalent) that you frequently refer to.
For example, something like:
- P0 = anything related to ongoing operational incidents
- P1 = anything related to reducing toil, example: project A
- P3 = anything related to program X, example: project B
- P4 = anything related to internal initiative Y, example: project C
- etc
As is usually the case with these things, even a well thought through classification system isn't perfect.
Try as you might, different people can have different interpretations of what thing contributes to what other thing and there are often complex independencies between pieces of work, which can lead to inconsistent classification or even inconsistent interpretation of the assigned classification.
But it's still better than having nothing, because at least you can reason about the prioritisation decisions that are being made in a structured way.
Bringing it all back to the point; what you want is a consistent way to compare things, so that you can ensure that the right choices are being made when it comes to using the limited capacity of teams and people.
The assumption here is that having such a system helps you to achieve your own goals, because what you want to get done is higher priority than other things.
That may not always be true though, or you may not realise that the things you want are actually lower priority. In that case, with a clear understanding of the priority of the other options you have more than enough ammunition to engage with the stakeholders and reset expectations.
Easy In Comparison
The second rule in getting people and teams to do what you want them to do is learn how to compromise.
Assuming that you have passed through the prioritisation step and the piece of work that you need done hasn't made the cut, the next step is to figure out what there is room for.
Can you reduce the scope of the work, trimming it down to only the bare necessities? If that's not enough, can you reduce the scope of the other pieces of work that were selected for execution? A combination of those two things might be enough to get what you want.
Don't be stupid though. You need to make sure you are compromising on a dimension that actually makes sense. Don't push for a crappier, less easily maintained or supported solution just to make the thing happen.
That's a classic example of a short-term win in exchange for long-term pain.
I mean, you can definitely go down that path if you absolutely must, but it should always be accompanied by a well understood and accepted plan to undo the mess that you're creating, and supported by a real deadline for why it absolutely must be delivered by a certain date.
Other than scope reduction, you can also compromise by fragmenting the work required. That is to say, if you have other teams that are depending on some piece of work and they specifically need to do engineering work to integrate with your solution, you can break the work up into two parts and deliver them on separate timelines.
For example, you might agree to deliver the contracts and guidance for how to use them before actually delivering the working solution end-to-end.
The benefit of this is that the initial piece of work is generally smaller and easier to make room for and it allows the dependent teams to get started with what they need to do to make use of the final solution.
The danger is of course that the longer the time between initial development and actual integration, the more risk there is that you will run into one of those classic integration problems (shifting contracts, lost context, etc).
Still, it's a way to compromise all the same.
An Unsurprising Result
We've just finished up a round of quarterly planning at Atlassian, so I've done a lot of negotiating recently.
The teams I work with always have many things that they want to do or that other people want them to do and it's never an easy decision about who ends up not getting what they want or need.
It can be a frustrating situation to deal with, because as a TPM you don't have any real power to make decisions about what gets done. That's the responsibility of the engineering managers, so you need to focus on influencing things in the right direction.
The upside is that you've generally got way more context than most people, so you're in a great position to create the best outcomes for the business.
Or the best outcomes for the things you care about at least.
Ideally both.
Member discussion