Creating a culture of results

When major successful organisations in the tech industry are interviewed, we hear about things like operating models, technologies, innovation culture and effort. In other words, the input dimensions that went into creating the success. Large volumes of popular technology consulting advice lives in this 'input' space too, with readers thinking "these guys got a great result, what should we do to emulate them?"

So much context is lost in this process, as technology best-practice starts to become an overly generic set of tools, processes and mantras. By definition, in many ways this obsession over input will create mediocrity.

The critical piece of context lost in modern technology advice is usually that of the outcome. What are we optimising for, what are our success criteria, and how will it all be measured? What will success look and feel like for our organisation, department, or team? This plays out into engineering culture in some really negative ways, which need to be addressed by strong leaders who are on a mission for real results.

The first challenge is in the definition of results, and ensuring that the view is shared by the entire team. Over time, and especially in large teams, "results" can start to become very limited in scope, as each team or person starts to re-define their own criteria for what done means, and what success looks like. For example, do developers own their code right into production? Does engineering pride stem primarily from software that works well and performs well in the hands of the user, or does their accountability and responsibility end abruptly once code review passes?

Accountability requires that there is influence or control too, and some environments strip this from people as departments grow too large and complex. While this may be inevitable, it doesn't mean that the culture of shared results should go with it. A shared vision, and metrics for results, force introspection within every team and person in an organisation. It creates a framework for accountability in thought process, as you can easily ask "does this contribute to the ultimate goal" of every process, idea and project – rather than pitting teams against each other with different scorecards showing how hard they worked.

Moving away from input-focused engineering culture also means we need to stop worshipping metrics that are self-ingratiating. Code coverage is meaningless if actual users can't use your product because of error rate, or you have an average review rating of 1.5 out of 5.

Good metrics speak to business intention, and would be objectively measurable. In tech, there are many output metrics which we can build a culture around. That said, there is also absolutely nothing wrong with growth, retention and reviews being as much of a technology mandate as it is for product and business teams. It is toxic to have one team celebrating their definition of 'success' while another suffers, and this works both ways.

This is not to say effort shouldn’t be recognised, or even rewarded. The goal is to avoid scenarios where effort is spent towards an empty goal. Leaders in technology have to create a culture where there is pursuit of clear, shared results with material impact to the organisation.

Successful engineering teams didn't actually get there because they used only the latest tech with the latest processes and the most expensive coffee beans. These teams optimised for the outcome, for practical delivery of a technology solution that met market needs in the best possible way. Results are the ultimate motivator, but take leadership to define, drive and adapt towards.