Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Outcome vs. Output-Driven Organizations

Goal Setting
Team Processes

22 August, 2021

Sven Coppens
Sven Coppens

Sr Product Development Director at Aprimo

Sven Coppens, Sr Product Development Director at Aprimo, contrasts an outcome- and output-driven approach while explaining how choosing one over another can impact the organization itself.

Problem

There is a prevailing tendency across software development organizations to focus primarily on solutions. In most cases, the CEO or founders who started the organization will already have some solution in mind which will be socialized across the organization. Over time, as new people start to join, the focus will shift more toward the solution, while the original problem will be somewhat overlooked.

In large organizations, the business part of the organization is often quick to come up with solutions, which are then handed over to product managers who need to develop a roadmap for building those solutions. When the R&D team steps in to cement the requirements, the engineers will be left with nothing but to nod their heads. As it turns out, this is neither the right nor the most affordable approach because solutions are imposed on people who should be proposing them. Solutions should be proposed only after thorough research and a profound understanding of the problem. Knowing what is the outcome one wants to achieve is a cornerstone of any solid problem analysis.

Actions taken

Let me illustrate the difference between an outcome- and output-driven approach by showing what happens when the focus is put on outputs instead of outcomes. Let’s say we want to go for a specific persona or market segment and want to have a chat feature in the application. This solution will be pushed to a team in the form of well-defined requirements. Requirements are, in most cases, outputs that are handed off to the engineering team.

On the other hand, there is an outcome: we should build something that should allow a group of people to collaborate. Instead of exploring possible solutions, it is assumed without much deliberation that the chat capability is the solution. The half-baked solution is communicated to the team.

Instead of communicating the outcome, the team will be working to produce certain outputs. If they followed an outcome-based approach, they would start observing and measuring user interaction, trying to understand user needs behind that interaction. Rather than building a chat feature, the team starts to analyze the problem. The team could find out that users don’t want to chat but rather give comments within the application and need integration with Slack, Teams, etc. for the collaboration. As a result, if the team would focus on solving user problems, we would see adoption increases. Those personas would start to interact more extensively using our application. This is the outcome that we wanted to get: increase our user base.

Three methods that, in my opinion, are helpful to shift the focus toward an outcome-driven approach:

  • OKRs: OKRs are a great example of a goal-setting system that helps people stay focused by connecting their work on the ground with the business objectives. Often developers are handed over requirements without understanding why they are building something. OKRs create that understanding by providing more context and laser-sharp focus on objectives.
  • Five Whys: A method that not only shifts the focus on outcomes but encourages people to dig deeper and identify the root causes. While identifying the problem is the first step, it’s often insufficient to provide a solution that will solve the user’s needs. Five Whys is there to help identify a reason that caused a given problem and create a long-term solution.
  • Measuring. Before building something, one should define what success looks like and how it could be measured. By asking those questions, one can also arrive at the essence of the problem.

All of those methods have beneficial side effects too. Asking the questions will stir up a debate that can have a positive impact on the team dynamic. People on the team will be more critical, willing to challenge the imposed solutions, and encouraged to come up with alternatives.

Lessons learned

  • Being focused on outcomes, you will be able to make the right decisions. It also helps set priorities straight as it will make evident what is important and what is not. Moreover, an outcome-driven approach has a positive impact on development teams. When solutions are imposed, engineers feel like robots that should produce software without much thinking. When encouraged to think about problems, they are brought closer to the business, and their opinions become more relevant.
  • Changing teams from output-driven to outcome-driven is not easy. It’s not only a question of routine; you will need to coach the team to change their behavior as well as their way of thinking. Don’t be surprised if the prescriptive approach already took the toll. If an engineer asks for requirements only and prefers not to engage in any other deliberative activity, then it is a sign that you need to change the culture.
  • By focusing on outcomes, the playfield suddenly becomes much broader, and it takes not much more mental effort, which includes an increased responsibility. For many, that shift will be hard, if not impossible to achieve.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Surefire Ways to Boost Team Morale

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, talks about effective ways to boost team morale when stepping in as a new manager in the team.

Motivation
Team Processes
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

One-On-Ones for Engaging Employees: How Good Managers Run Them

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares some of the benefits of having one-on-one meetings and tips on how both parties should run them.

Goal Setting
Leadership
Meetings
Feedback
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.