Applying Outcome-Oriented Thinking as an Engineer

You’re in an ideation meeting with your tech lead and peers brainstorming how to improve the bits of functionality your team owns. Everyone is throwing around great ideas. The engineering energy is palpable. You hear things like:

• We need to break apart our monolith and move to microservices.

• Our web app has some code that really needs refactoring.

• We should focus on migrating to serverless architecture.

If you’re an engineer like me, these sound like exciting, challenging, and rewarding projects to take on. It might take a while, but imagine how much more maintainable and performant the code will be. It’ll totally be worth it.

As engineers, these challenges excite us because our brains are hard-wired to solve problems. This isn’t a bad thing. In fact, it’s a really important skill to have. Engineers employ critical thinking to systematically decompose and solve problems. Think about that last outage your team had. If Jeff hadn’t deciphered that one hard-to-find cryptic log message, you’d still be troubleshooting right now. We hone this skill every time we write code in order to move stories across the Kanban board. The engineer’s brain is always weighing trade-offs in search of the perfect solution: should you use that handy design pattern or does it overcomplicate things?

This ability to formulate solutions can be a double-edged sword though. The ideas from your team’s session all have something in common: they’re explicit solutions. Solution-oriented thinking is vital in specific situations but can fall into the trap of misleading priorities; it’s just not favorable for higher-level activities like ideation, project planning, or technology roadmapping. When those solutions from ideation meetings turn into actual projects, they often get cut before completion because executives cannot clearly see the inherent business value. As you climb the engineering career ladder, framing work in terms of the outcomes you and your team want to achieve becomes absolutely critical. Not only does this pattern of thinking allow you to speak the same language as product owners and senior engineering leaders, but it also helps ensure you’re making the right technical decisions.

Teleport back to that ideation meeting, and try saying: “Interesting approach, but what outcomes are we trying to achieve?” Begin to orient your work around outcomes over solutions. Challenge yourself, leaders, and peers to put projects in terms of their business value rather than simply saying, “We need to do this big, important thing.” Bear with me. I’m not advocating for assimilation into the Empire, quite the opposite. By demonstrating the business value, we ensure that our work is as important to the company as it is to us.

After you take a step back, define the intended outcome. Let’s go through an example. Take the idea of breaking up a monolithic application in favor of microservices. Most engineers and product managers would likely agree with you. Monoliths are not generally scalable when development teams reach a certain size, but why does your team’s monolith need to change? It sounds rhetorical, but it’s an extremely intentional question. What concrete outcomes are you trying to achieve by breaking up the monolith? Are you trying to improve deployment frequency? Is your legacy code laden with technical liabilities that cause frequent customer support tickets? Do you need to scale to meet a growing customer base? Asking these types of questions reframes the proposed solution into more tangible outcomes.

Imagine that your company would like to complete feature work more quickly. Deployment bottlenecks are occurring when engineers take the necessary time to test their changes before co-created production deployments. All teams have to wave the green flag before a release can ship. The tangible outcome becomes improved time to value for shipping product features. While you’re defining this intended outcome, you must also make it measurable and data-driven. For example, improve deployment frequency by 15% across the engineering organization or decrease cycle time by 10%. These outcomes can be very difficult to measure. You must first form a baseline by gathering data and determining your current metrics. Then, critically assess where bottlenecks are occurring in the deployment process. Is your code stuck waiting on pull request approvals for days at a time? Is testing and validation a long and arduous process? Based on this analysis, you can start to form a data-driven opinion on where to target your efforts.

The final crucial step is defining and presenting options to achieve the identified outcome. Yes, now we can get back to talking about solutions! This is where our engineering brains thrive. Think about all the possible ways to hit your target, and don’t be afraid to offer non-technical approaches. Product managers and engineering leaders truly appreciate having options involving people and processes too. It’s all about trade-offs. To be most effective as an engineer, present solution options and clearly articulate the trade-offs between them—and don’t forget to frame those options as measurements toward the concrete outcome.

Let’s head back to our example. Assume the target outcome is to improve deployment frequency. Based on where bottlenecks occur in your deployment process, options might include:

The first three solutions tout varying ranges of long-term viability, while the fourth is likely faster to enact. Be open to all options and work with your leaders to understand what solution best aligns with your organization’s capacity and overall business strategy.

All in all, defining outcomes with a variety of solutions and their trade-offs should be best practice in software engineering. Of course it’s good for your team to ensure meaningful progress toward company goals, but it also supports you professionally. You’re more likely to:

• Get buy-in and green lights on your pitched ideas.

• Have a voice in shaping your work by defining solution options to reach your outcomes.

• Be recognized or promoted for high-impact work that moves the company in the right direction as supported by concrete data-driven measurements.

• Gain satisfaction in knowing that your work will be used and will be meaningful.

What’s your desired outcome?