Why Outcomes Over Outputs?

Why should teams create outcome/mission based roadmaps, converge on solutions later, focus on the problem-to-solve, experiment, limit planning inventories, avoid chasing story-point velocity, start together, limit handoffs, and [fifty other things]?

Plain and simple: you’ll get better near, mid, and long-term business/customer/user/societal outcomes and a sense of impact. This is common sense (to some), of course, but I’m amazed by how often the calls for “outcomes over outputs” (and similar) ignore first principles. I fall into this trap often. The discussions are frequently framed in philosophy, “best practices”, maker advocacy, “theory of work”, and org design debates (e.g. “Teal”). This is important stuff, but almost orthogonal to outcomes over outputs. Or the talk is more “well, of course that’s how we should work, and those managers are crazy for thinking otherwise!” True, perhaps, but not all that helpful.

Far less frequently do I hear:

Why is this important? Why should you beat the “Why” drum?

Unless you see the upside, it will be hard to imagine how all this uncomfortable uncertainty (a hallmark of working this way) will be worth it. Taking the impact-focused approach pushes the boundaries of our comfort zones. It challenges the rigidity of the organization chart, individual roles & responsibilities, how you gauge the quality of your work (and assess your skills), how and who you hire, philosophies on planning, accountability, and ownership, and initiative funding approaches. Working this way requires new perspectives on management, and leadership at all levels. It’s not easy. It’s not comfortable. It’s challenging!

Not acknowledging that — or perhaps only looking narrowly at the impact for your particular role — will make advocacy a great deal harder. Front-line makers have a lot of upside to work this way, but to call it 100% intuitive — especially when you dig into the day-to-day — is a bit of a stretch. If you’ve never worked in the trenches and seen working this way pay off then you’d be crazy to think it all works. From this alternate perspective, the negatives far outweigh the positives, and the status quo beats some theoretical future.

Finally, from a first-principles perspective your mental model needs to accommodate situations where working in other ways may be appropriate. You can’t be dogmatic. In highly repeatable, low-complexity environments it may make sense to work in markedly different ways. Take, for example, needing feature parity along one axis, while seeking differentiation in another. You know, you might need to run a feature factory (while explaining the bet and hypothesis, of course). It’s ironic when product developers expect high predictability and outputs from other parts of their org, while simultaneously advocating for [way x] everywhere.

I’ve been speaking to many teams lately as part of my new role at Amplitude (50+ in the last few weeks, ooof). They often come to me looking for a specific framework, canvas, prescription, or example. At least on the surface. But when I dig more deeply, I typically learn that they’re looking for back up. They want me to say “you’re right, that’s the smart way to work!” And then give them a canvas to fill in to prove their point and make it official (bosses like stuff that looks certain and robust). Our conversation invariably shifts to “how can I persuade [some person] to work this way?”

So if someone asks, “are we doing it right?”
My first question is “are you generating better outcomes?”

The reality is that none of this is turn-key and easy. The mistake is seeing it as a series of skills to “pick up” vs. something you need to practice over and over in complex environments. The ability to practice (and improve gradually) far, far outweighs the approaches and skills which tend to be plentiful and not all that difficult to grasp and pick up. But working this way is hard. It requires trust, safety, support, skills, flow of information, sense-making, mapping contextually appropriate approaches, focus, and flow of work.

Another challenge is that it is all a spectrum. Companies of any reasonable size will need to support multiple concurrent operating models, continuous reorganization to meet new challenges with contextually appropriate “ways”, and the “muscle” to continuously improve across many dimensions.

So, one big takeaway of my coaching calls is that the teams need to create safe environments to “build the muscle” and practice. Resist cargo-culting ways, templates, frameworks, and silver bullets. Establish a cadence to inspect and adapt. This may be on a small scale at first — safety/trust may be limited, and structural rigidity may stand in the way — but you have to try over and over. This is a “case” you will need to build by showing, not telling.

It will not be easy, otherwise, all of your competitors would be awesome at it.