Category Archives: People Management

14 Levels of Collaboration – Combining 7 Levels of Delegation with Extended RACI

Source: Pixabay

7 Levels of Delegation is interesting but it doesn’t answer an important question:
What about veto?

What do you do at level 2, i.e. when you try to sell a decision but the recipients don’t buy-in?
What do you do at level 3 when you consult people. Can they veto your decision? Same at level 5: when I advise, do I have veto-power?

By the way, this question is not specific to 7 Levels of Delegation. It’s missing in standard RACI, too.
In RACI the C represents “(To be) Consulted”. Does this imply veto power?
Well, that depends on the interpretation that an organization chooses. I have seen various interpretations in the field. Some require the consultation, some allow veto power, some require consultation before proceeding with the process:

# Mandatory? Binding/Veto-power? Beforehand? Stereotype
1 false false n.a. “Support”
2 true false n.a. Advisory
3 true true true Sign-Off
4 true true false Intervention

Remarks on the items in the table:
#1: This is basically an option to get support or advice from others. Some RACI “dialects” use a dedicated collaboration typed called “Support” for other purposes, though, as part of the “Responsible” collaboration role.

#2: Depending on the people involved, this may be extremely fruitful or totally useless, i.e. the outcome is arbitrary.
Imagine a motivated person seeking advice from a respected co-worker to pick her brain. Very fruitful and exciting.
Now imagine someone who is forced to consult someone he or she does not like or respect, maybe for good reasons (when the adviser is objectively not senior enough for the role) or any bad reason out of “pride and prejudice”.

#3: Effectively a bottleneck, i.e. the value added by this collaboration or the risk mitigated by it should be worth the delay. Unfortunately, in many companies the Sign-Off collaboration is pervasive and default, indicating a culture of fear and mistrust.
Nevertheless, there are absolutely valid key decision areas that require a Sign-Off. Imagine a work contract or any other contract for that matter. Once it’s done and signed there’s no cheap and easy turning back. Also, it might be illegal (SOX, anyone?).
Or picture medical decisions that are literally a matter of life and death. In some key decision areas it makes a lot of sense to require explicit sign-offs

#4: This collaboration supports process flow while ensuring intervention power for stakeholders.
Some variations of this use thresholds, e.g. if only up to €20K is at stake then “Intervention” power is OK while more than €20K requires a sign-off.

As a result I propose a combination of “7 Levels of Delegation” with “Extended RACI” that incorporates all those ideas. I’d like to call it “14 Levels of Collaboration“.

L Stereotype Description
1 Own I own the key decision area and I’m not obliged to ask nor inform others about details. I may, however, be required to deliver results according to objectives and key results at defined points in time and will be assessed accordingly.
2 Tell I own the key decision area and I make decisions for others or I instruct them to perform tasks within the key decision area (in a responsible or supportive role). I may explain my motivation, however a discussion about it is neither desired nor assumed.
3 Sell I own the key decision area and I’m obliged to explain decisions to others aiming at their buy-in. However, getting their buy-in is not mandatory in order to proceed.
4 Inform I own the key decision area and I’m obliged to keep others informed.
5 Consult experts I own the key decision area and I’m obliged to consult experts. However, they have no veto power and their advice is non-binding.
6 Consult stakeholders afterward I own the key decision area and I’m obliged to consult others. They have veto power but it is not necessary to wait for their approval to continue with the process.
7 Consult stakeholders beforehand I own the key decision area and I’m obliged to consult others. They have veto power and it is necessary to get their explicit approval (=Sign-Off) before continuing with the process.
8 Agree I share ownership / accountability with co-equal others. Mutual agreement must be reached in order to proceed.
9 Sign-Off I don’t own the key decision area but at some point(s) I make the process stop so I can do my assessment and give my sign-off.


  1. The Hiring Manager role owns the decision who to hire for which role/position. However, the process requires a couple of sign-offs along the way, e.g. from Controlling before job creation, HR workers’ council before contract offer etc.
10 Intervention I don’t own the key decision area and the process needn’t stop and wait for me. However, I have the authority to intervene and enforce changes whenever I encounter a problem.


  1. The fire department does not own your company. However, they have the right to inspect your company’s buildings and enforce measures to ensure safety.
  2. Regulatory entities may enforce a recall of your products.
  3. If your company creates software and releases a new version in many short interval, then Global Marketing won’t be able to do a full assessment of the UI each time for lack of resources. However, they retain the power to intervene when they find out about deviations from the corporate design.
11 Advise I must be asked for my expertise but my advice is non-binding and I cannot veto the accountable person’s decision.
12 (To be) Informed I don’t own the key decision area but I have the right to be informed about decisions.
13 Inquire/Buy-in I don’t own the key decision area but I’d like to be convinced of the wisdom of the decision. If I don’t agree I may say so but I don’t have the authority to veto the decision.
14 Delegated I don’t own the key decision area and I leave the decisions to the owner and, potentially, the people that she instructed to perform tasks.
If I’m only a stakeholder then I don’t even want information about it anymore.
If I’m the “delegator” then I don’t even want to be informed about details anymore. However, I may define objectives and key results that I require in order to utilize and/or assess the delegated work.

Leave your comment, like and share.

Agile in Distributed Team Setups

Conference Call Bingo

“Conference Call Bingo” – Source:

Working in distributed team setups has a bad reputation – for good reasons. I remember many frustrating and useless telcos, so how can this kind of collaboration possibly work out in an agile team setup?
Spoiler alert: if you allow people to do home office you already have a distributed team setup.

After I had blogged about this some weeks ago, I was lucky to give a presentation on this topic at the ProductPeople conference in Cologne in May of 2019. You can find the slides on SlideShare:

How to deal with boring tasks

Source: pixabay,

Over the years I’ve had some conversations with people in my teams about them feeling bored with their tasks.

In my early days as a manager my natural reaction was something along the lines of “that’s why it’s called a job, not the fun-hobby-zone”, sometimes just in my head, sometimes spoken out loud.

Fun fact: this does not help.

First, as a manager you should always be happy when one of the people you are responsible for approaches you. They are the few that speak their minds, while many others don’t and will potentially vote with their feet and quit the company.
Ever heard someone say in a job interview “I left my previous company in order to learn new things/become more experienced/felt stuck and wanted to progress”? Yeah, that’s boredom their former managers ignored.
That’s why I’m always glad when people approach me with any of their problems and I always take them seriously.

Second, empathy.
Let’s be honest, we’ve all been there. Everybody has had to work on things they found boring. It’s a real thing. The subsequent content is based on what I found useful for myself first.

When someone tells me they feel bored I reply in 2 ways:

1 – Intrinsic View – Set yourself a challenge

  1. It’s in your head
    No task is boring per se. “Boring” is just your own interpretation of a task that should best be called “repetitive“.
    Look at it this way: It probably wasn’t boring to you when you did it for the 1st time.
  2. Automate it
    If it’s a repetitive task that you understand well, how could you automate it?
    For instance, if you have to copy data from one place to the other, then how about writing a script?
    Many great inventions were driven by boredom or laziness.
    Check out “jobs-to-be-done” for example. Everything that feels annoying to a large enough number of people is a hidden business opportunity that’s waiting to be picked up.
  3. Vary
    I’ve programmed a ton of pretty common functionalities in my days like login forms, registration forms, deployment scripts etc. How about trying something new while you do it, leveraging your experience?
    Maybe try to validate the data with a different and more elegant approach, avoid conditions and favor stateless functions? Get to 100% code coverage this time, try data driven or mutation testing? Try a different set of libraries or framework? Increase security, e.g. using a Captcha, honey pots, or try to hack yourself with a fuzzy logic attack script?
    #TimTowtdi (There is more than one way to do it)
  4. Abstract it & teach it
    Everyone who is an expert in anything was at a crucial point in their career: “OK, I understand it now. I could move on to the next thing – or I could dive deeper into it, abstract it, teach it to others”. See also the “Feynman Technique“.
    Repetition is a core element of becoming an expert.
  5. Improve it
    If you’re really familiar with a task because you’ve done it a bunch of times, then you could think about how its execution can be improved so everyone benefits from it.
    Your experience is a chance to make a difference.
  6. Delegate it
    Last but not least: repetitive tasks are good candidates for things you can delegate to more Junior staffers. This implies that you have to explain the task to that person, see “Abstract it & teach it”.

2 – Mix it up

Common sense tells us that having the same people do the same things for as long as possible should yield efficient results. We can assume that they have become true experts by now.

In my experience this has proven to be a fallacy in many cases:

  1. If people do the same things over and over again they do not necessarily get to the point of “Vary” and “Improve it”. I’ve seen teams being stuck with tools and practices like ant scripts and Subversion while the world has moved on to Ansible, Docker and git.
    This is partly the reason why people go from bored to fearful about their careers when they feel that they might not be up-to-date with the job market’s demands and then, eventually, quit.
  2. Even worse, work might be so “optimized” that it’s very hard to change anything later on. And there will always be the need for change some time.
    A process designed for maximum efficiency is a common antipode of agility.
  3. Assuming a “steady-state universe” is dangerous because there will always be fluctuation in your teams to some degree, be it attrition, parental leaves, promotions, sabbaticals, retirement – you name it.
    You should have a plan for how to retain knowledge when people leave and how to onboard new people.

That’s why I recommend mixing up teams every once in a while so people get to know other tasks as well – and to ensure back-pressure against a “steady-state universe” attitude.

From a business perspective, if you do it to early then the invest of time for onboarding might not have paid off yet. If you do it too late then people might leave or work might have become “rusty”, see above. Find the sweet spot.

From a people management perspective, some people are bored faster that others. Get to know everyone well enough to know their personality and ambitions so you can identify when it’s time to shake assignments up.


Leave your comment, like and share.