TBM 27/52: Mandate Levels
Good news! I'm writing another book for Amplitude as a follow-up to the North Star Playbook. If you have 3-5 minutes to spare, I'd be grateful if you could contribute a short anecdote about a change effort. Thanks! It will help us make the book more accessible.
Autonomy. Empowerment. Agency. I hear, and use, these words often. But what do they mean?
A couple years ago I tried to tackle this problem without getting bogged down in definitions. I came up with nine "levels" of work, ranging from very specific, to very general. I called them Mandate Levels, to capture the idea of a sphere of authority and autonomy.
In this post, I'm going to share some example uses of the model. First, a big caveat. The whole point here is to have better conversations about a thorny, abstract topic. This is not a maturity model and this is not a way to "grade" teams. Don't do that! If anything it grades senior leadership’s ability to let go of the reigns.
#1: We can look at where teams operate. Here, Team 1 tackles bets defined by a target metric. Team 2 tackles bets defined by 1) a segment of customers, and 2) an activity, task, or goal.
#2: We can understand the relationships of different roles, both on and off "the team". In this example, common in non-digital product enterprises, we see rigid mandate boundaries. The developers and designers on the team tackle A - C. The product owner ponders the more open ended problem (D). We find a rigid boundary between the team and "the business" at the D/E divide. And a product manager and general manager own levels E through I.
#3: Compare this to what we might expect to find in a product-led company. No product owner. And the team has more overlapping mandates (and a higher level mandate).
#4: Here is a designer, lead developer, and product manager "trio". On this team, the remaining developers max out at C. This might work. Or those developers might get bored.
#5: Comparing teams with rigid and looser role boundaries.
#6: Comparing past initiatives.
Keep the following things in mind when using this model.
Work is happening at all levels. Always. Work is always fractal and nested. The questions is who is operating where and how.
Just because you “own” a mandate level, doesn’t mean people will not be interested in what you are up to, or what the resulting lower mandate level work will look like.
Teams and individuals can have mandate levels. And work itself can have a mandate level.
Some orgs have more rigid role boundaries. Other orgs have very messy role boundaries. Reflect the messiness!
Sometimes our mandate changes depending on the nature of the effort. Sometimes we start higher, and as we learn more our follow-up work trends lower.
You may need to tweak the language to make sense in your org. Come up with your own labels by laying out a couple dozen efforts and categorizing them.
Not everyone wants to be responsible for earning their company $N million dollars in 6 months. When you're a new product developer, the thought of working at D might be daunting. Or you’ll find people who will leave their company if they can’t operate at Level X or higher. Preference and experience matters.
Finally, it is easy to say "just empower your teams!" Even with best intentions, that might not be easy. Your current architecture and org structure may limit your options. Team members may lack experience working with a higher mandate level. An innocent request for an "annual plan" may snowball into premature convergence and reduced mandate levels for everyone.
Oh, and you can’t fake a mandate level by asking a team to come up with OKRs they don’t have a mandate to control/move. It is one thing to look at your deliverables and say “oh, hmm, what is the OKR here?” or “what is our success metric?” And another thing entirely to start with a mandate to address a goal, objective, or opportunity, and have leeway with The Work.
My advice...name it to tame it. Skip words like empowerment, and get specific.
Short explainer video:
Mandate Levels (New Miro Template) - Watch Video
I was pretty active on the thread/video front this week.
Autonomy is the capacity https://driftboss1.com to make one’s own choices based on internal values or reasoning rather than external control.
from what I understand, John is describing a more granular view on the "scope of work mandate" (the vertical axis of the Org Topologies map).
the OT map also defines horizontally the "scope of skills mandate". we believe this is critical to get the full picture. as people/teams/agents are (dis)allowed to apply certain skills.
both mandates are someone's decision (we call it org design) and we work with organizations to 1) get the awareness of these mandates; 2) purposefully re-define them; 3) develop a multi-year org development direction (i.e. from CAPS-2 to PART-4 on the map).
see https://www.orgtopologies.com/ for more on the map & mapping method.