The mindset of outcome-driven teams

Need a cheat sheet? Read our 50 tips for outcome-driven teams

You can’t flick a switch to transform your team culture overnight. In this post, I’ll look at what makes outcome-driven teams great and how you can change your environment to help folks focus on goals rather than tasks.

They minimize the cost of being wrong

"What if we're wrong?" is a central question for outcome-driven teams. It's not about saying that you're bad at your job — it's about accepting that some things will always be out of your control. You can spend weeks drafting a detailed strategy with the brightest minds available, only to see that plan becoming obsolete in a matter of days.

Your market is always on the move and the best you can do is formulate hypotheses about what your customers need right now. All of that while knowing that the answer might not hold true a couple of months later. So, rather than trying to be right, we should strive to be less wrong over time. This second approach helps us get comfortable with uncertainty and move faster:

• We'll get better at thinking in terms of probabilities.
• We'll embrace experiments to fill gaps in knowledge.
• We'll reduce the turnaround time for decisions.
• We'll see divergent opinions as something interesting to explore.

Minimizing the cost of being wrong is a required mindset for continuous improvement as it will push you to work in shorter cycles to make sure that you're on track and that your current plan still makes sense to pursue.

They focus on problems, not solutions

"Bring me solutions, not problems" is a dangerous statement. It creates a culture where people push discussions away from root causes and instead debate implementation details. It's the manager that starts with "why don't you do ...?" before even asking about the underlying issue. It's the PM that brings you a mockup they made and says "hey check this out" (I'm definitely guilty of this one). It's the hour-long meeting where a team fights about who's got the right approach without realizing they're talking about the wrong issue.

Focus on the issues, first, and only dive into the solution space when there's consensus about what you're trying to achieve. "What's the business problem?" Then and only then, "what are your options?"

(More on that topic in HBR!)

They empower their teams

For Continuous Planning to be effective, you need to move away from centralized decision making. Leadership defines what the North Star is, but they should trust their team to know how to get there. You don't hire great people to tell them how to do their job. You hire them so they can show you how to get where you want to be.

Here are a few characteristics of empowered teams:

• Leadership shapes the North Star, but the team picks the right approach.
• The team is balanced with the right folks to get the job done autonomously.
• They are key contributors to the definition of success.
• They know what to focus on and are accountable for their results.
• They work on what the customer needs, not what their manager wants.
• They can call out bad goals, and push for changes on the roadmap.

I highly recommend Marty Cagan's post on empowered product teams to go further on that topic.

They make it OK to be KO

Get rid of the hero culture. It should be as easy as possible for people to say when things are getting off track. Outcome-driven teams understand that it's not going to be a flawless journey. It's about confirming rapidly what's working, and identifying the initiatives that are in trouble.

If folks are afraid of reporting bad news, they'll avoid seeking help until it's already too late. So let your teams come forward with their problems early. They're not failing. They're being transparent, and that transparency will in turn help everyone identify when teams aren't aligned and make better decisions. The easier it is for people to communicate on everything — good and bad — the less you'll have to deal with critical issues.

They put execution above strategy

"Execution beats strategy" is about reducing the cost of planning. Teams that take months to ship end up spending days debating the tiniest feature changes. They're scared of getting anything wrong because the next release will be in another 3-months time. This puts huge pressure on the team to always make the perfect call.

A team that can release improvements every week will be able to move faster. They can also run small experiments and iterate to find the best approach. They're not trying to be right, they're trying to be less wrong over time.

There's a good reason why it costs significant sums of money to ask consultants to predict the future. The further you look ahead, the less accurate your picture will be. It's damn hard to know what technology, customers, competition and industries will look like in the next 12-18 months.

A different approach is to accept that you won't know everything and compensate by increasing your capacity to learn from real-life events.