Decisions, decisions
A model I've learned to help how to decentralize decisions
A good part of your day will be on reviews, reading documents, supporting decisions and up to some point you will get feedback and feel that you either let something go or are on top of decisions that you shouldn't. You don't want to micro manage or leave things to be.
Decentralizing decisions is a strong way to empower your team and let it grow, specially if you manage managers. What worked for me is to split the decisions according to stakeholders and risk, and the ones I was able to take the heat if something was off I would delegate to the team.
But that is not a good analogy so I kept reading until I learned the tree model from Susan Scott in her excellent book Fierce Conversations which uses a tree as a model to understand how to delegate, communicate and distribute work. I will try to summarize it below adding my take on the impact/blast radius:
Leaf decisions means you should act on it, no need to report. They are easy to revert and mainly local (to a team, to a feature in a product and so on).
Branch level decisions means make the decision, act on it, communicate (daily, weekly, using a format as PPP - progress, problems and plans) as you feel appropriate. These are decisions that can be reversed, will need effort but you will use stakeholders knowledge about impact and inform them instead of approvals and you control their impact.
Trunk level decisions means you should make the decision, preferentially create a couple of scenarios and communicate before executing them. These decisions will use brains from stakeholders, people from outside your team or grand area. These are not easily reversed and can impact beyond what you see.
Root level decisions are to be made jointly, with input of other teams, founders and may impact the whole business. Some of these are made already and you are brought in, not the originator. They are great to learn how your company works and react to changes.
This framework have been helping me a lot to delegate and explain why and what, keeping in mind these three delegating principles:
You are clear on what you are delegating and what is expected
You gave all the conditions to the delegated thing to be done (budget, team, size) and you consulted with everyone if they are enough
You make accountability and checkpoints early and often, so the outcome keeps fresh and there is an end to all tasks/responsibilities/projects/whatever you had to delegate.
Hope that helps. If you liked this post please consider getting my new book, The CTO Field Guide which expands a bit on that and team organizations.