When output creates outcomes
A story of me being wrong
The slogan “outcomes over output” is very popular. By now, I have come across it in many topics: Agility, Scrum, Lean UX, Objectives & Key Results (OKR), Evidence-Based Management (EBM), DevOps, with the occasional exception (Kanban — on Medium and on prokanban.org) and criticism.
This goes hand in hand with the warning against building what users ask for and against assuming that a specific feature will create the expected outcome. However, the more something becomes conventional wisdom, the more important it is to challenge it. What if sometimes committing to a certain output is the best way to achieve the wanted outcome?
For my taste, I do not read enough about those unexpected hits. So why not do this myself?
It was a couple of years ago when I had just switched from being a software developer for customer-facing applications to developing tools for the application developers. I was part of a new team asked to focus on Continuous Integration / Continuous Deployment (CI/CD). In the past, releases had been time-consuming and error-prone, with a lot of manual typing involved. The solution I was building would reduce this to a couple of clicks and then watch. The software to be released via the CI/CD pipelines was the very one I had been using for years. In other words, I knew what I was doing and especially why I was doing it.
Nevertheless, as Everett Roger’s Diffusion of Innovation curve would suggest, the teams supposed to be using and benefitting from the solution showed different levels of enthusiasm. Some were eager to chip in and try out early. One particular team was a hard sell.
In the past, it had already been hard (to put it mildly) to agree on any standards across teams. Now I heard that, before even trying out the first version of the tool that would take the software to production, one developer of the said team wanted a specific feature included. No argument would change his mind. I found this incredibly frustrating. I secretly suspected that this was a way to reject the solution. However, I kept my mouth shut.
As I realized that discussing it further would not get us anywhere, I asked for reassurance that this specific feature would make all the difference, and it was given. The feature could be built within a reasonable time. I don’t remember the exact effort but within less than two weeks. It would not interfere with the experience of the other teams, it could be tested and rolled back in case it did not work.
So off I went to build this. It went ready to be used, I informed the team. “Amazing! Thanks!”, the developer of the team said. The team adopted the solution immediately and kept using it regularly for years.
The developer had been right in being stubborn: He knew exactly what he wanted and what his team needed. And outside the tough arguments, he was a friendly person. What I had thought to be true turned out to be completely wrong. What saved me was that I had not voiced my doubts but kept the possibility open to be proven wrong.
Nevertheless, I kept wondering: How had I not been able to understand this specific need of part of the users, given that I had been a software developer of the same development tool? In hindsight, it dawned on me that this specific software (which was my favorite software as a developer of all time) was very flexible. It could be used in very different ways. It was adaptable to many different styles. I had not taken into account how different developers would use the same software — which maybe was one of the reasons why I liked it so much.
Moral of the story: Be kind to people. Create situations where you can be 100% factually wrong and still win.
Panjabi MC: Jogi
