Are you leaving talent on the table with OKR?
Not too much, not too little—high-performance teams require management that is just right.
Welcome to the second article in the series about building outcome-driven organizations and getting results from OKR.
If you haven’t read the first article yet, please go back and read that first.
This post is also available in Portuguese for my friends in Brazil.
Imagine you could learn leadership from the man who coached the founders of Apple (Steve Jobs), Amazon (Jeff Bezos), and Google (Larry Page and Sergey Brin). It turns out you can—at least indirectly.
Bill Campbell, “the Coach of Silicon Valley,” passed away in 2016 but left an amazing story that illustrates the essence of outcome-driven leadership. From the book Trillion Dollar Coach (emphasis mine):
[Bill Campbell] liked to tell a story about when he was [CEO] at Intuit and they started getting into banking products. They hired some product managers with banking experience. One day, Bill was at a meeting with one of those product managers, who presented the engineers with a list of features he wanted them to build.
Bill told the poor product manager, if you ever tell an engineer at Intuit which features you want, I’m going to throw you out on the street.
You tell them what problem the consumer has. You give them context on who the consumer is. Then let them figure out the features. They will provide you with a far better solution than you’ll ever get by telling them what to build.
This does not mean you let engineers run off, unfettered, doing whatever they please. To the contrary, product teams need to partner with [teams like sales, marketing, and finance] from the outset, integrated into a cross-functional group that pushes forward with new ideas that solve problems and hatch opportunities.
Tell people what to achieve, not what to do
At its core, building an outcome-driven organization is about leadership. Team attitudes typically reflect their leadership, so nothing will change unless leaders commit to unlearning and adopting a different way to lead.
I love Bill Campbell's story because it’s a crisp summary of that different way to lead: outcome-driven leadership.
The story is about product teams in a tech-powered company, but its lessons apply to other roles as well. If you replace “features” with “projects” and “what to build” with “what to do,” you’ll see that any leader can learn from this story.
Outcome-driven leaders tell people what to achieve instead of telling them what to do.
The product manager in the story wanted to give teams a list of features to build, but Bill Campbell told him to explain what he wanted to achieve instead:
You tell them what problem the consumer has. You give them context on who the consumer is. Then let them figure out the features.
Campbell also highlighted why that's important:
Teams will provide you with a far better solution than you’ll ever get by telling them what to build.
Throughout history, different groups dealing with uncertainty reached the same conclusion, albeit with different names. Author Stephen Bungay calls it “leading through intent." The modern military calls it “mission command,” while the 19th-century Prussian army referred to it as auftragstaktik, or mission-type tactics, where the emphasis is on the outcome of a mission rather than the specific means of achieving it.
In outcome-driven leadership, we begin by clearly defining the outcome we want to achieve, why it's important, and the constraints and guardrails we have for achieving it.
In real life, there are always constraints on what we can do. For example, you may have to achieve the outcome by the end of the quarter or within a certain budget.
Leaders must work together with teams and stakeholders from different areas to clearly define these constraints and set the necessary guardrails.
Bill Campbell believed the path to success is “forming high-performing teams and giving them the resources and freedom to do great things.” But he made it clear leaders had to set boundaries:
This does not mean you let engineers run off, unfettered, doing whatever they please. To the contrary, product teams need to partner with [teams like sales, marketing, and finance] from the outset […]
Telling people what to achieve is a crucial starting point, but leaders must also strike the right balance in managing teams to achieve those outcomes.
The Goldilocks principle
One of my recurring themes is that people tend to view things in black and white, seeing them as either entirely good or entirely bad. But the solution is not to go to the extremes. The solution is to find the right balance.
This idea is called the Goldilocks principle, named after the story in which a young girl—Goldilocks—tastes three different bowls of porridge and finds she prefers the one that is "just right," neither too hot nor too cold.
Like Goldilocks, high-performance teams require that management interventions be “just right." As Bill Campbell explained, leaders shouldn't tell teams which features to build, but they shouldn't let the teams do whatever they please, either.
But many people believe that adopting OKR or the product model means leaders should be completely hands-off. Providing any direction or guidance would be seen as committing an unforgivable offense: micromanagement.
However, micromanagement isn't the right word. It implies that focusing on details—the micro stuff—is always wrong. But if leaders want to build a culture that values quality and the customer experience, they have to pay attention to details.
This concept is embedded in one of Amazon’s leadership principles, Dive Deep (emphasis mine):
Dive Deep
Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdotes differ. No task is beneath them.
No one was more obsessed with details than Steve Jobs. Tony Fadell, who led the development of the iPod and the iPhone, describes it in his book Build:
Examining the product in great detail and caring deeply about the quality of what your team is producing is not micromanagement. That’s exactly what you should be doing. I remember Steve Jobs bringing out a jeweler’s loupe and looking at individual pixels on a screen to make sure the user interface graphics were properly drawn. He showed the same level of attention to every piece of hardware, every word on the packaging. That’s how we learned the level of detail that was expected at Apple. And that’s what we started to expect of ourselves.
I’m not saying every leader should do what Jobs did, but managing the micro stuff and paying extreme attention to detail isn’t always wrong.
Instead of micromanagement, it's useful to think in terms of overmanagement and undermanagement. In overmanagement, there's too much management intervention or managers intervene in the wrong places. In undermanagement, managers don't intervene enough.
The table below summarizes some of the symptoms of undermanagement and overmanagement.
The Goldilocks of management
Leaders are responsible for creating the conditions in which teams can perform at their best.
That means they need to strive for the Goldilocks of management—finding the right balance of management for each context, not too much, not too little.
Tony Fadell emphasized the importance of finding that balance:
One of the hardest parts of management is letting go. Not doing the work yourself. You have to temper your fear that becoming more hands-off will cause the product to suffer or the project to fail. You have to trust your team—give them breathing room to be creative and opportunities to shine.
But you can’t overdo it—you can’t create so much space that you lose track of what’s going on or are surprised by what the product becomes. You can’t let it slide into mediocrity because you’re worried about seeming overbearing. Even if your hands aren’t on the product, they should still be on the wheel.
Fadell again:
As a manager, you should be focused on making sure the team is producing the best possible product. The outcome is your business. How the team reaches that outcome is the team’s business.
This doesn’t mean the manager always chooses the outcome with no input from the team. It means that the manager is ultimately responsible for the team’s performance and for the achievement of the outcome.
The pitfalls of overmanagement and undermanagement
Another principle of outcome-driven leadership is don’t leave talent on the table. Don’t waste the talent of all the smart, hard-working people in your organization.
When we go to the extremes of overmanagement or undermanagement, we leave talent on the table.
Talking to different teams can make this discussion more concrete. Let’s use an excellent example by Henrik Kniberg, which I adapted.
Imagine asking the same question to three teams: What are you working on and why?
We ask the first team, and they tell us they're implementing the self-service app requirements because stakeholders requested it. They say, “Our goal is to deliver this project by June 15th.”
Leaders treated the team as order takers, telling them which features they wanted. This attitude is typical of know-it-all executives and is precisely what made Bill Campbell want to throw the product manager out on the street.
When leaders treat teams as order takers, they block employees' talent and kill innovation. As Kent Beck points out:
If you treat people like chess pieces, don’t be surprised if they show the initiative and creativity of chess pieces.
Undermanagement also leaves talent on the table
Most people don't realize it, but companies also leave talent on the table when they undermanage teams. Let's talk to the second team to understand why.
The second team says they're working on a Bitcoin app because they think it's a good idea. “We want to launch it by the end of the year,” they say.
The problem here is that the team made a decision without considering their customers’ or business’s needs, and without strong evidence to back it up. The leaders took a completely hands-off approach, ignoring Bill Campbell's warning and letting the team do whatever they pleased.
However, when leaders undermanage, they leave the team’s talent on the table. Teams need guidance, coaching, and support to perform at their best. You don’t get high-performance teams for free—you have to put in the effort.
High-performance athletes and entertainers always have coaches and managers guiding and supporting them. High-performance teams are no different. Let’s talk to the third team to see an example.
The third team says they are testing ideas for the self-service app to reduce the contact rate (the number of times customers contact a company for help within a given period). They explain this is important to improve the customer experience and reduce costs.
This team:
Is focused on making a difference, not simply meeting due dates.
Clearly explained the outcome they wanted to achieve and why it’s important.
Understands customer and business needs.
Understands the core metrics associated with their work.
Understands how their work contributes to the organization's success.
This was possible because leaders guided and coached the team, helping them develop the muscles and mindsets necessary to perform at their best.
Don’t take alignment for granted
Another issue with letting teams go unfettered is that alignment doesn’t happen magically. Without guidance, each team will move in different directions, and their talents will go to waste. Without top-down guidance there’s no alignment.
Amazon’s senior leaders took special care years ago when transitioning to autonomous teams—teams designed to operate with little or no coordination with others. As former executives Colin Bryar and Bill Carr wrote in Working Backwards:
Autonomous teams are built for speed. When they are aligned toward a common destination, they can go a long way in a short time. But when they are poorly aligned, the team can veer far off course just as quickly. So they need to be pointed in the right direction and have the tools to quickly course-correct when warranted.
To ensure alignment, each new autonomous team had to meet with CEO Jeff Bezos and the senior executive leading the team. They discussed the team’s composition, purpose, and the metrics used to measure progress.
It's impossible for each new team to have meetings with the CEO nowadays, given Amazon’s scale. But executives and middle managers can adopt a similar approach for alignment.
Most companies already suffer from lack of alignment. Do you think that letting people do whatever they want will improve the situation?
Finding the right balance of management for each context
Overmanagement and undermanagement are relative concepts. What's "just right" for one situation may be too much or too little for another.
Management isn't one-size-fits-all, and we need to find the right balance for each context. In some cases, teams may need more specific guidance and closer monitoring.
For example, Bill Campbell's Intuit1 makes a product for American income tax returns (TurboTax), so they must comply with regulations, which may include mandatory features.
Not telling the teams about the required features would be a severe case of undermanagement. But giving them a fixed specification for how to build the features could be overmanagement.
Strong leaders aim for the right balance. They help product teams collaborate with legal to understand how to comply with regulations while providing a good customer experience. But if the IRS requires the user's mother's maiden name, they ensure teams collect it.
The product also has a clear due date: everything needs to be ready well before Tax Day (April 15th, when Americans submit their income tax returns). This is a great reminder that all organizations use both the outcomes approach and the due dates approach to manage work. There are always cases where we need to commit to dates due to regulations, contracts, or events like Tax Day.
The difference is that those due dates and mandatory features aren't arbitrary. They're not just something a know-it-all executive believes is important based on very little evidence.
We also can’t leave the leaders’ talent on the table
Companies that adopt a completely bottom-up approach are also leaving their leaders’ talent on the table. When direct reports fail to work together with their managers or request help, they do the same.
There are many bad managers out there, but that doesn’t mean everyone works for Dilbert’s pointy-haired boss. There are many talented, experienced leaders, and we can’t waste their talent.
Teams are closer to the problem and know local, specific details, while leaders understand the big picture and have more seniority. The real power comes from collaboration between them.
As Marty Cagan points out in Empowered, high-performance teams don’t need less management. They need better management. They need managers who can help teams perform at their best.
That means leaders also have to develop the necessary muscles and mindsets so they can properly coach, support, and align the teams.
Middle managers are key
We've been talking a lot about leaders, but everything we've discussed applies to anyone who is a people manager, anyone who oversees a team of employees.
Middle managers are crucial to keep organizations working, as the Google founders learned in 2001.
That year, Larry Page and Sergey Brin decided that 130 engineers would report directly to VP Wayne Rosing. Managers were no longer necessary, as engineers would “self-organize.”
Bill Campbell, who was coaching the founders, wasn’t happy with the idea, so he and Page decided to ask the engineers. One after another, the engineers said they wanted to have a manager. They wanted somebody to learn from and needed someone to help when discussions with colleagues reached an impasse.
Page continued with the plan anyway, but the "self-organizing” idea didn’t go as expected. Some engineers liked not being overmanaged by bad bosses, but many hated the consequences of being severely undermanaged.
As Douglas Edwards, Google employee number 59, wrote in I’m Feeling Lucky (emphasis mine):
It was an engineer’s dream come true or a bit of a nightmare, depending on whom you asked. No clueless pointy-haired boss could get in the way and screw things up, but there were no clear signals from above about what was important and what was urgent and what was both. Groups struggled for resources and fought redundancy. Some engineers wanted more feedback on what they were doing and how well they were doing it, and others wondered about opportunities for advancement.
In the end, it was a short-lived experiment. Google quickly realized the problems caused by undermanagement and reinstated the managers within six weeks2.
We'll be back soon
We'll be back soon with another article in our series on building outcome-driven organizations and getting results from OKR.
In the meantime, I’d love to hear from you. Feel free to leave your comments below or email me.
Special thanks to Itamar Gilad for reviewing drafts of this article, and to Carlos Accioly and Melissa Suzuno for helping me edit and develop it.
If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.
Intuit is not perfect either, as the company has been involved in different legal issues regarding TurboTax.
The different books written by former Googlers disagree on the exact dates and numbers in the story, but they all agree that the experiment didn't last long.