Top Managers Are Abandoning RACI for Impact Delegation
Managing one team is hard. Managing managers takes a lot of work. If you need help to delegate to your engineering managers, or to coordinate Product Manager, Tech Lead, or HR, the Impact Delegation framework is the solution for you.
What is RACI?
RACI is a framework that allows a team to clarify roles and responsibilities. The method is simple. Start by listing every role in the team (columns) and each possible task (rows), then gather the stakeholders and co-construct the matrix with each role by assigning one of the 4 responsibilities (Responsible, Accountable, Consulted, Informed). I want to highlight the difference between Responsible (does the job) and Accountable (the one you go to if something goes wrong, in charge of the outcome).
As an example, for hiring a software engineer the RACI matrix would look like this.
It’s pretty simple to understand. Yet it can become complex as you add more steps like technical interview or cultural fit etc…
RACI negates Ownership
I managed up to 40 people for 3 years without using a single RACI framework. One day, a freshly hired Product Manager asked me to build a RACI together to clarify our roles. We co-constructed the matrix, we listed 70 tasks from product discovery to production release! We added 8 types of roles (Eng Dir, Eng Manager, Tech lead, Director of Product, Product Manager, Designer, PMM, Head of Compliance).
It took us 2 days to fill the matrix, and we were still not aligned. We got lost in details and endless discussions. That’s when I noticed a pattern, the PM was Consulted on every task.
Our RACI didn’t solve any problem but it created multiples.
- “Not my job”: It’s easy for individuals to refer to the RACI and tell you “That’s not my fault, I am not accountable for this in the RACI”. In a team, everyone should aim for shared ownership, we are in it together. It’s not always your job, but a RACI shouldn’t stop you from going the extra mile.
- Micro Management: Some managers use RACI to keep the team with a strict list of tasks and remove autonomy and initiative. You put people in boxes and they can’t go out of it.
- Control Freak: Some managers build RACI so they can be consulted for every decision, they want to keep control.
- Overload of information: To avoid upsetting people, you put Informed everywhere. This forces people to do more reporting, more meetings and async communication. It creates an overload of information. Some people even use it to justify their bad decision, they drown you in long Slack messages so you won’t read them and then tell you “I did inform you”.
- Ignore the RACI: Some dev just didn’t care about it at all. It was reducing their autonomy, didn’t like it and ignored it.
One last warning, it doesn’t scale. There will always be gaps in your matrix. You can not reasonably list all the tasks. As the company grow new roles will be introduced to the organisation. Maintaining the matrix will become a full-time job.
If you need to build a RACI with your team, you probably have a structural issue that you should fix first. RACI doesn’t help with delegation. Everyone should know what they are responsible and accountable for and should work in the same direction.
Impact Based Framework
I prefer another type of role-based framework based on Impact. Let's say you are a Director and you work with multiple managers. You want to empower them and give them enough autonomy to do their job, yet you want to keep a part of control. You also want to be replaceable, if you are sick or focused on another project you want your manager to step in.
Let’s take our previous example, of hiring a software engineer. You built the following RACI.
What if instead, you just had this one rule:
With Impact delegation, you define a threshold. Under this threshold, you delegate entirely the decision and every step of it.
A couple of benefits:
- Clear ownership: The final decision maker is known. He is responsible and accountable for the outcome (in this case hiring someone).
- Goal-oriented not process-focused: the goal is to make a hire, the Owner is accountable for the result and owns the process. He can delegate part of the process to anyone.
- Easy progression: If someone knows how to hire a junior engineer, he can quickly ramp up to hire a senior engineer, as he has already done every step.
- Less ambiguity, less process. There is no gap, if a hire requires a VISA process, no need to add that to the RACI, the owner is in charge of that. If a candidate is referred and you want to skip the Initial Interview the owner of the process can. If a candidate asks for a specific laptop for their onboarding, consider it done.
Within the boundaries you set up, the owner can do everything and adapt to every situation. This framework is simple and flexible, let’s see a couple more examples
Some Examples
Release a feature in Prod 🚀 If the release impacts less than 50% of users you delegate to the engineering manager, if not the owner is the engineering director.
Add a task in the roadmap 🗺️ If the task is shorter than 1 sprint you delegate it to the engineering manager, if not the owner is the engineering director.
Buy software 💵 If the price per year is less than 20k€ then you delegate to the engineering manager.
Organise a team-building ⛳️ If the price per person is less than 200€ then you delegate to the engineering manager.
You can always imagine slightly more complex but I recommend keeping simple rules.
It’s your turn, now you start delegating efficiently.
