Outcome Driven Engineering

At Flexatal we are often asked to deliver more than a team - our CTO below describes his increasingly popular "grown up" approach to engineering management.

Outcome-driven engineering is an approach that focuses on the effectiveness of a technical team in terms of its collective impact as opposed to raw productivity.  It involves a shift in emphasis away from common quantitative measures like sprint velocity to assessing the effectiveness of delivery iterations based on customer feedback. Outcome-driven engineering will become an increasingly important aspect of the new normal post-Covid of distributed remote working. While there is value in technical leadership keeping abreast of canonical agile team metrics across their organisations, it is also vital to have a clear understanding of how those teams are impacting on customer delivery satisfaction. 

There is no one single prescribed technique for creating an outcome-oriented engineering mindset in your organisation. A lot will depend on your specific context. For instance you may not have a direct channel to your customer in which case you will need to find a proxy for measuring customer impact. It’s better to see outcome-driven engineering as a toolkit of mechanisms you can review for suitability and introduce according to relevance. Some of the key elements are as follows:

●    Organisation Design: it is important to be deliberate about how you organise your engineering resources. It’s advisable to have specific separation of technical, people management and delivery leadership with programmatic teams as the irreducible units of ownership and delivery that your engineering organisation should be built around. These are durable entities with strong ownership boundaries and responsibility for codebases that have a long-term importance to the organisation. Team configuration is the most important part of engineering organisation design. If you get it right you should not find you are reorganising your teams every six months.

●    Autonomy: programmatic teams need to be given significant latitude to determine how they address customer problems in terms of self-organisation and technology strategy. However, autonomy must exist in harmony with standardisation.

●    Standardisation: where it makes sense to do so, programmatic teams should standardise on key aspects of their development processes. This helps avoid waste and support economies and generate a faster return on investment. A good example is Spotify’s Backstage developer portal. This is a difficult balance to get right and is often a source of friction in scaling organisations.

●    Calibration: another example of standardisation that is a key enabler for providing transparency for staff on individual performance is an Engineering Growth Framework (EGF). Sometimes referred to as a career ladder, an EGF transparently outlines the expected behaviours and competencies at different levels within the engineering organisation thereby providing clarity to all on promotion criteria. An EGF also applies to technical managers and ensures they are well calibrated across the organisation.

●    OKRs: Objectives and Key Results set from the top down are the ultimate tool for providing alignment across different programmatic teams. Done well, they provide clear direction on business goals and incentivize teams to work together and cooperate for the common good.

●    Metrics: productivity and velocity metrics alone are not a measure of customer value so they cannot and should not be used as a proxy for impact. Certain metrics such as those promoted in the influential Accelerate book relating to cycle time, change failure rate and MTTR (mean time to resolution) are useful to track on a per team basis.  Team level health metrics are also helpful to monitor. However, to measure impact, product and engineering leaders need to go further and build higher level synthetic metrics specific to their context.

●    Feedback: a greater focus on customer feedback is needed to ensure you are heading in the right direction in terms of outcome. This typically involves using methods like NPS with customers and ensuring strong customer relationship management is in place.

●    Monitoring and Observability: it’s vital to ensure you remain on track. There are two aspects to this depending on orientation of focus. Monitoring is more about the internal aspect and making sure teams are clear about goals and delivery objectives both short and long term. You can view it as a health check. Observability is more about the external aspect and determining that the customer is receiving value per iteration. This relates to the previous point about soliciting feedback. There is an analogy here with a car journey. In this case, the Objective is for the customer to go from A to B with milestone markers along the way representing Key Results. Monitoring is important to ensure the car is performing as expected during the journey. Observability relates to checking we are on track with milestones.

Ultimately outcome-driven engineering isn't just about implementing a checklist of mechanisms. It requires buying into and cultivating the corresponding mindset. The key aspects of that mindset are:

●    Agility: A focus on outcome is inherently agile. It forces a greater emphasis on test and learn methods versus detailed upfront specification. Teams are encouraged to conduct supporting experiments not all of which will yield positive results. 

●    Curiosity: related to the previous point, the freedom to fail and try again in support of outcome is crucial and that requires a blame-free learning oriented culture.

●    Trust: trust is foundational in outcome-driven engineering. An essential aspect of autonomy is that you have to trust the team to interpret and deliver on their goals as captured in OKRs.

●    EQ: leaders need to have the ability to understand, empathise and connect with their teams. It is necessary but not sufficient to have IQ alone.

Outcome-driven engineering ultimately connects engineering effort directly to business value. It does so by focussing on obtaining direct and specific unvarnished feedback from the customer.  In a sense this emphasis on customer obsession represents a form of radical candour for business.

There are some downsides to adopting an outcome-driven engineering approach. Introducing it within an organisation will typically require the integration of certain mechanistic enablers. For example tech teams may find they need to add a feature flagging capability or introduce A/B testing. It’s also the case that not all businesses have customers that directly fit the bill. For instance B2B organisations will need to find proxy customers. Arguably the biggest impediment, however, is in cultivating the mindset shift that is needed to move to it as a way of working. This requires buy-in from the very top of the organisation.

Flexatal have a lot of experience in supporting organisations moving to outcome-oriented engineering approach. If you'd like some help on this, please either register your project here or email [email protected] to discuss.