The engineering manager chronicles: The decisions tree
In my previous post I focused on the importance of creating alignment by providing context, discussed the rules of engagement and the importance of creating a safe space for your team-members to feel like they have autonomy in their daily work.
In this post I would like to focus on another term that connects well with the previous subject — the decisions tree.
Decisions Tree
It’s not the classic algorithm you might think of at first glance, but it is still somewhat of an algorithm providing the thresholds to the circumstances where a team-member should make decisions on their own, when they should inform you, involve you or they should expect you to intervene in the first place.
Leaf decisions
Those are decisions that have little consequences that are easily reversible in case they were the wrong ones.
These are the kind of decisions you can make on your own. I don’t even need to know about them.
Branch decisions
Those are decisions that have more effect and might be somewhat more difficult to reverse, but you should still make on your own. As these sometime come from things that required changing the feature spec, refactoring something or a small change in the data-flow, it might be beneficial to let me and others in the loop as we might learn from it.
Trunk decisions
Those decisions are ones that have more impact, on the company, the product, the architecture and so on.
In these cases you might need to get the OK. Come with some alternatives, required resources and time estimations.
Root decisions
Those are decisions that have a wide impact on the company, the product, the architecture and other aspects that are way outside of the scope of any individual contributor. We should make these decisions together, or it might even come from me to begin with.
Each team-member at different levels (the individual contributor, to the architect, to the team-lead and all the way up the chain of command) may have different circumstances and examples. I’ll try and give a few to emphasize the point.
The engineer —
- How to organize the code, how to split to different functions and similar decisions — examples of leaf decisions. Make the decision, nothing to involve me.
- Some piece of code might need refactoring which will require some extra effort to increase maintainability or observability. — examples of branch decisions. Make the decision, but would love to learn from it, so FYI the rest of the team.
- The feature requires adding a certain Open-Source third party that you checked and can be used freely and adheres to all your company’s policies — example of a trunk decision. Let me know, let’s make sure there’s nothing hidden here that might make this more complicated later.
- A certain API might need changing by adding some more information to it. This may affect other parts of the system (especially internal services using this API). The architect might need to be involved and we should commit on doing that change. — examples of root decisions. The architect needs to be informed, this might have more consequences than anticipated and more resources will be needed later on.
The team-lead -
- Who does what in the team, which issue and so on — leaf decisions that are right in the scope of a team leader.
- Changing priorities within the sprint, changing the CR methodology or the way internal CI/CD pipelines work — branch decisions, that I would just love to know about as an FYI.
- Starting an evaluation process and setting KPIs with one of the team-members that is under-delivering. — a trunk decision that just requires me to know and provide some feedback as it might affect other teams and how things are perceived. Make the decision because it’s your team but make sure to involve whoever needs to be involved (HR for instance).
- Deciding to let someone go or wanting to hire someone new— that’s a root decision that requires my total involvement alongside HR and so on.
The architect —
- How the feature should be designed in a certain service or between services. — a leaf decision made by the architect. That’s her job and responsibility.
- Changing the way continuous integration is executed or how infra-as-code is implemented (as long as it doesn’t change the roadmap we agreed on of course). Though it should involve others and should be done with extra-care — do it with the team-mates (i.e. tech leads and team leads) but this is a branch decision that just requires my FYI as it may require my attention later.
- Deciding to work with a certain tool offered by our cloud provider — a trunk decision that might have impact on cost or otherwise, and so my feedback is needed before committing to this change.
- Deciding to switch a cloud provider altogether. Obviously this entails so many changes and requires so many resources that the decision needs to be taken jointly. — a root decision
Looping back to the rules of engagement from my earlier post, presenting this decisions tree to the team might be a good idea. It helps them understand their autonomy, its limits and when they should make the decision on their own.
Though it may take time to fine-tune it, it is worth it in the long-run.
