Output and outcome terms are sometimes used interchangeably, but it is essential to understand their difference. The difference matters in planning, management, or software engineering activities. One of the recent tendencies on the market is that teams are focusing more on outcomes, so there are many questions on what it actually means, to have an outcome mindset. Let’s understand the difference first and then understand how to achieve this mindset and, the most important, why it is beneficial.
What is an output
Output is a result of work. This result is measurable, the original task had clear steps on how to get there and fixed timelines. The outputs are usually closer to the technical side of things, for example
- feature, delivered according to the formal requirements
- deletion of unused source code in application
- process documentation
These things are easy to measure, the measurements are purely technical and are hard to trace to business goals.
Teams that concentrate on outputs, ask fewer questions regarding the business side, which can speed things up in a short-term, as they fully trust external expertise (for example, Product Manager). At the same time, there is a higher chance that the entire team can be working on something that will be useless for business.
Overall concept of output is something very similar to the efficiency definition – the team might be moving fast in some direction, but the direction itself might be wrong.
What is an outcome
Outcome is an actual impact of a completed work. In other words, it could be a business-side consequence of preformed steps. Examples are the following
- due to new amazing design, visible increase in visitors expressing the interests in product
- due to optimized data center layout, significant savings on electricity and higher uptime
As you might notice, the outcome is harder to measure and formalize, but it is not just closer to the business side of things, it is the business. The challenge with measurements is that there is never 100% causation and correlation between performed steps and outcome (as third-party actors can influence the overall impact), but it is usually fine to draw conclusions if there is enough data.
Teams get deeper into the business details and it takes longer to onboard and to start working.
Let’s meet at X 👋
And talk any time
What is outcomes mindset
Outcome mindset brings engineering teams closer to the business. This mindset requires effort both from teams and from management levels.
Teams need to dedicate time and capacity to get deeper into specifics of business, so the contributions will be more on spot.
Management needs to be more open and willing to share details about how non-engineering company members work with software and infrastructure.
One of the most effective approaches is to describe the “Path of a Dollar”. Management describes what customers are, how people become customers, what is the common life cycle of a customer within the company and its products. The customer journey usually includes steps why and when the customer starts paying, how the company earns money.
As a result of such exercise, engineering folks will have a better understanding of what is really needed and what can be optimized to earn more. Moreover, it increases engagement, which is essential for the company to survive in a tough industry climate.
Summary
Outcome mindset for engineering teams is when teams know how a company operates and how money is made. This makes engineering work more efficient by optimizing what really matters.
The tendency to pursue outcomes perfectly fits the overall tendency of the engineering layer getting thinner and closer to the business side of things.
Business wants engineering to be more in sync with needs and goals of business.
Learn and understand what your company does, this will benefit you, your team, and your company.