Empowered Teams Work. They Really Do.
Empowerment harnesses your organization's creativity by allowing teams to grow from their mistakes.
What does it mean to be an empowered team?
An empowered team owns a well-defined slice of product, whatever that may be in the context of their wider organization, and is ultimately responsible for its success or failure. They have the final say over what they create and how they create it.
Chaos! Mass Bedlam! How could this possibly work? What next, the guillotine?
Hold on, you counter-revolutionaries, hear me out.
Empowered teams aren’t little Ayn Randian islands, proudly isolated from the rest of humanity. There is a thing that an empowered team doesn’t have control over, and it makes all the difference.
And this is their context. A team must work within the confines of what success means within the context in which they work. Most software organizations (though not all) are motivated by the bottom line, so a team in this context has a very real constraint placed upon it: contribute to the money-making or fail.
Scaling Decision-Making
It is a basic truth that systems must change as they scale. What works for a small system doesn’t work the same when scaled up.
For organizations, the thing that must scale as it grows is:
Decision-making.
In a smaller organization, with a clear leader and a few trusted lieutenants, the scale is usually small enough that the core leadership team, if they’re good, can make most of the important decisions.
Scale this up, however, and these leaders quickly run out of time to handle all the details. Unfortunately, at this point, a hundred and fifty years of managerial inertia kicks in. Rather than share the load, many leaders create structures to ensure all important decisions must emanate from their savvy brains.
This is a classic command-and-control structure, where the implementors are there to follow orders, or in the case of a tech org, complete projects. In my last essay, I talked about just one of the many ways this type of organization fails to reach its potential.
Ok then, what’s the alternative? How can executives possibly let go of their direct decision-making power? Won’t those techies go wild, leaching off the bottom line with all their vanity projects? It’s like letting rats breed in your pantry.
Listen, I have nothing but respect for most of the executives I’ve met. They tend to have a grasp of the business domain I can only guess at.
Empowered teams aren’t there to take organizational power away from these folks. The intention, rather, is to distribute the decision-making load more vertically.
The goal is to reduce the cognitive load at all levels: let each level specialize in making the types of decisions for which they are better positioned and skilled to make.
This pushes details down the stack. It lets people at the top focus on big strategic issues, and it gives the implementors a quick turn-around time on tactical changes.
Looks good in theory. But how does it work? For that, let’s take a look at an institution that has wholeheartedly embraced empowerment: the military.
Standard Operating Procedures
I’ve been reading a lot about process lately. For example, process is a huge consideration for the military. Troops can’t cooperate effectively if they don’t have standardized ways of interacting. It makes me think of some of the tech organizations I’ve worked for.
Surprisingly perhaps, they’re really talking about empowerment. An effective military needs its troops to make their own battlefield decisions, but commanders don’t just say; go out and get’em, Rambo.
No, they provide their soldiers with Standard Operating Procedures (SOPs).
For the military, where the stakes are life and death, these procedures are drilled until they are rote so that when groups of soldiers come together to do something, they don’t have to work out the details. If soldiers need to set up artillery to flank an enemy position, you don’t want everyone arguing over the best way to load the shells. You want them working together for the job at hand.
You want them to focus on their mission objectives.
This is a direct corollary to good technical processes, though the context is certainly different. We’re dealing with procedures like: How do devs hand off work to QA? How are escalations handled? How do we select our next bit of work? How do different parts of the org communicate?
The unpowered teams I’ve worked on usually have very poor procedures. How do we handle escalations? Shrug. Someone just takes care of it. This lack of clarity gets in the way of issue resolution. Generally, what process there is, is imposed from the top, and its focus is on meeting the expectations of the roadmap.
To be effective, however, a process must save time, effort, and confusion. It has to remove unnecessary impedance in all levels of the organization, all the way to the top.
And if a process doesn’t do these things, it must be improved. That’s what retrospectives are all about. They are crucial to evaluating all the little things that help or prevent us from doing our job.
But now to the crux: what is that job?
Objectives
In the military, SOPs let teams focus on mission objectives. A mission objective arises from the wider context of the battle at hand. The focus of a mission objective is an outcome; take that hill; suppress enemy fire. Any single outcome, however, is only a small part of the battle.
There must be a Central Command which understands the wider context of the war. Its job is to subdivide the desired outcomes such that all the teams can work together to win the battle. They can’t keep control over every decision of every team because this would detract from their own focus on the overall strategy; they just want to know the outcomes and then change their strategy depending on success or failure.
Do teams fulfill mission objectives without help? Not at all. The more a team understands the overall strategy, the better decisions it will make. A team needs all the intel and help it can get to fulfill its mission objectives. But, an effective team must be able to make instant decisions on the ground which could be the difference between success or failure, life or death.
Tech teams aren’t playing for the same stakes, of course. Our objectives play out over months or even years, rather than hours or minutes.
But the idea is the same. Letting teams fulfill objectives to the best of their abilities unleashes the creativity of each team to find and deal with its own problems. It also allows leadership to focus on what it’s good at; ensuring that the larger strategy of the organization is being fulfilled.
Empowerment is a way to maximize success throughout an organization.
Key Results
In the military, you have a pretty good yardstick for measuring whether you’ve met your mission objectives. Am I still alive? is a good place to start.
But in a tech organization, success or failure is not so visceral. That’s why a system called Objectives and Key Results (OKR) was developed. Do you need OKRs in order to succeed in empowered teams? Not at all. You do you, man.
If you use OKRs, however, it’s important to understand their intention.
I worked for a short time for an organization that was trying to implement an OKR system. I was a dev lead and my manager tasked me with filling out the OKR — both the objective and the key results.
I was confused. What was the purpose of this exercise? The manager shrugged. Just put something down and we’ll figure it out later.
Um, no. That’s not how you do it. Objectives arise from broader technical and product strategies, which make their way down through however many steps from the vision set by the leaders of the organization.
As a person filling out my part of the OKR, I’m responsible for setting the Key Results — how will we know whether we’ve hit the objective? The objective, however, is non-negotiable.
Of course, you may not believe in the objective, and a good leadership chain will take your objections into account. But in the end, like a soldier, your question when told to jump should be, ‘How high’?
Because you need to trust that your leaders are acting in good faith, just as they trust you to do the same. They give you the objective and you are there to say, ‘Here’s what we can do with it’.
It’s almost like we’re adults here, trusting that we’ll both do our jobs.
Discovery: Failing in Order to Learn
For those still not clear on the concept; an objective is not a description of a project. It isn’t a spec or a requirements document.
It’s a desired outcome with no implementation details or deliverables — other than fulfilling that outcome. Things like: Increase membership. Make the system more performant. Enable cooperation between users. Etc.
Many of us in the tech world have never dealt with the idea of being trusted to this extent. It may be weird to not be given a design spec to implement. What the hell am I supposed to do?
The first step is; understand the context of the objective. Amazon has a great format for this, called the six-page narrative. Whatever else you say about Amazon, they get ownership. All people involved in the project are encouraged to read the narrative to understand why they’re doing what they’ve been tasked with.
Then, you start failing.
Or rather, you try things out. You build services, or UX designs, or apps, that you think might do the job and see if they work, and if they don’t work then you try something else. Fail fast. Fail often. Keep your options open.
Do the people who’ve given you your objective have something in mind when they give it to you? Probably; but their plan is just a guess. Don’t look for anyone to figure it out for you. You’re there to surprise them with something that works better than anyone could have dreamed up because your team is responsible for your own success. You do the actual work, the intensely creative work, of fulfilling the objective in the most effective and timely way possible, or you fail.
This investigation is called Discovery.
Let Me Repeat: Empowered Teams Work
You may think that given these responsibilities, empowered teams are bogged down by analysis paralysis. The weight of all this decision-making must be onerous, leading to doing things more slowly, if at all.
After all, if your real decisions are made by someone else, then you can get right to work. Isn’t that easier?
Wrong! For a number of reasons:
1. Well begun is half done, as my father used to say. If your team does the discovery, they’ll have a very good idea about the best way to fulfill the implementation. Everyone should be on the same page, ready to code something that works.
2. Teams have ownership over their product. How can it be any other way? In order to work as a cohesive whole, your team’s code must be your own, to tinker with as you will. This creates an incentive for high-quality code because you’re going to maintain it for as long as your team exists.
Is the code always perfect? Of course not. Developers are fallible beings. But discovery, once a team gets established, is just as much about going back and improving or replacing old code as it is about creating something new. An empowered team cleans up its messes in order to keep its code performant, flexible, and innovative.
3. An empowered organization generally does a better job of handling dependencies between teams. This is a huge time sink in unpowered orgs. If your code has been created to be used by other teams, then part of your objective is always to make your code as usable as possible, with complete documentation and a coherent API that leaves little doubt as to how to use your services.
Other teams do likewise and if they don’t it’s a big deal.
Escalations must be treated very seriously — they are not failings per se, but evidence that you need to improve something, and not tomorrow, right now.
4. It’s just more satisfying to work on an empowered team. Every person on the team can take a swing at being creative. This motivates most people I know. Also, the workload is generally less, as the team is usually much more productive (unless you work at one of the FAANG companies: they have a way of pocketing those productivity gains).
So, I hope that I’ve convinced some of you that empowered teams work. But if you’re a leader, I can still see how you wouldn’t be convinced. How the heck should all these ‘empowered’ teams work together? What is leadership’s role if there’s no roadmap to control?
That will be the subject of my next article.
