Deliverables Aren't Outcomes
I discovered something while consulting for the social development sector. They have long internalized the inputs-to-impact sequence while the tech sector still grapples with it.
This is evident when you see tech deliverables such as software releases being referred to as outcomes instead of outputs. The situation is not uncommon. A Head of Engineering claims to lead a set of "outcome-oriented" squads. When asked about the outcomes they have achieved so far, they point to their software releases. Well, a software release is definitely a delivery outcome, but we expect business outcomes from teams that we call outcome-oriented. A delivery outcome is just another name for a deliverable—an output.
Revisiting Activity-Oriented vs. Outcome-Oriented Teams
When we made a distinction between activity-oriented teams and outcome-oriented ones, we said:
People who sponsor development of software usually aren’t too interested in development metrics such as velocity or frequency of deployment to production. They care more about business benefits that the software will deliver such as lower manual effort, better sales conversion, greater customer satisfaction, i.e. business outcomes. Outcome-oriented teams are those that are mandated and equipped to deliver business outcomes, such teams have people with the capability to carry out all necessary activities to realize the outcome. By contrast, activity-oriented teams are neither equipped nor mandated to do so. They can only perform one of several activities required to realize an outcome.
Truly outcome-oriented teams must go beyond delivery. Otherwise, there's limited upside to reorganizing as squads and tribes, as stream-aligned or platform teams, or as durable or persistent teams. That's why our 2017 definition of product-mode teams was a mouthful. Here it is again, with minor revisions:
An ideal product-mode team is an empowered, outcome-oriented, business aligned, long-lived, cross-functional, ideate-build-run team that is able to and expected to solve problems and improve business outcomes, rather than deliver scope on schedule.
Yes, reaching the ideal is a journey but it is important not to use the language of having arrived when you are only getting started. In the social development sector, they seem to have no qualms in referring (correctly) to interventions or deliverables that (might) lead to a social development outcome as activities or outputs, respectively. Perhaps they are under less pressure to "demonstrate agility".
Language Matters
As the illustration shows, it is technically correct to refer to less-than-business-outcomes as outcomes. But in the context of valuing outcomes over outputs, it is not advisable to go by the common English usage of the word. Language influences mindset. Those who use the language of outcomes for anything less than a business outcome run the risk of developing a mindset of being satisfied with those intermediate outcomes. That's how they start calling software delivery teams as outcome-oriented teams. Granted, successful software delivery is no mean feat, but context matters as well.
Reporting anything less than a business outcome as an outcome to business executives will, unfortunately, ensure that tech executives do not get anything more than a token seat at the business strategy table. It will perpetuate the chasm between business and IT, between commercial and digital, between product and engineering, or more generally, between the demand generating organization and the delivery organization. And that, in turn, will perpetuate the performance gap between the Amazons of the world and the classic enterprise.
My line of work is not free from this trap either. Consultants are sometimes tempted to dress up their pitches and reports with the language of pseudo-outcomes. They might refer to the delivery of a transformation playbook or roadmap as an outcome even though it is only an artifact or a deliverable. Savvy buyers get this, of course. There are legitimate transformation outcomes, no doubt, as the illustration suggests, but achieving them takes far more effort than delivering a roadmap or playbook. And even then, they are only a means to improving business outcomes and impact.
We live in times of "fake it till you make it" but this is an example where faking it lowers the odds of making it. To escape this trap, I urge leaders to add the following guidelines to their internal code of communication:
Avoid using the word “outcome” in an unqualified manner to describe your team’s achievements unless you refer to verifiable contributions to business metrics that matter. In all other contexts, qualify it as delivery outcome, transformation outcome, etc.
Avoid using the word “impact” to describe your team’s achievements unless you refer to verifiable contributions to society or to the company’s topline, bottomline, employees, suppliers, or brand.
Going Further
This is only the start. Once misleading language is banished, the vacuum it leaves behind will bring up the question of how to truly lay claim to contributing to outcomes that matter. How do we bridge the gap and create linkages between intermediate outcomes and business outcomes? A new method call "Business Retrospectives" can help. I have developed it based on my consulting experience and it is getting good reviews in private previews. It is usually a significant undertaking in itself and is sometimes frustrated by resistance to change on the business side. I call it business inertia.
Get in touch if you could use my help.