Outcome Driven

One of the first questions I like to ask delivery teams is:

“How do you determine if you are delivering effectively?”

The focus of the answer tells you a lot about how outcome driven the team is. Most tend to center around the team’s output. These include delivery velocity, feature counts, uptime/MTTR stats, defect counts, customer satisfaction scores, sprints/projects where work was completed as planned, or any other measure that a typical manager might use to assess the team. 

Knowing that sort of information can be useful. The problem is the total inward-looking output focus. None of the measures tell you much about what your customers are trying to accomplish with the solution you are delivering, let alone give you any indication of what impact it is having helping them accomplish it.

Truly successful delivery teams are the ones that know the outcomes their customers desire and feel empowered to help them achieve them. Most importantly, they do this by regularly measuring the impact their work is having to capture what progress is being made toward those target outcomes.

Why Outcomes Matter

Customers only want to pay for solutions that help them achieve some result or set of outcomes they are after. They might not be forthcoming with what those outcomes are. In some cases they might not quite have all aspects of what they are after clearly defined themselves  However, if at some point your customer realizes you aren’t consistently and measurably helping them achieve that outcome value they are after, they will eventually get frustrated and toss you out.

Focusing on the team’s outputs is as sensible as building a Formula 1 car for an off-road race. It might be fast and responsive on a Formula 1 track, but is totally inappropriate for racing on anything but finished tarmac. 

Race car

How to Become outcome-driven

Becoming outcome-driven begins with understanding what the desired outcomes are (the target), why they are desired (which may provide clues to measuring progress toward their attainment), and what is getting in the way of attaining them (blockers and gaps that need to be overcome).

Unfortunately, it is rarely easy to build enough context of the people and the ecosystems they operate in up front. That is why I follow the steps below to build up enough understanding and context to drive toward the desired outcomes.

#1 – Learn about the customer and their current ecosystem

The journey starts by understanding who your delivery customer is and the ecosystem that they plan to use your solution in. Sticking with the race car analogy, think of this as finding out what type of race you are going to be in before jumping straight into delivering a solution.

The purpose of this first step is to get an idea of what is important to your customer, as well as what sorts of conditions you likely will need to consider. Don’t expect this to be either exhaustive, or a one-off activity. It is instead the start of becoming familiar with them. 

There are several benefits with starting this way. For one, it helps you start to understand not just what outcomes the customer is after, but also why. This will help you cut through any erroneous assumptions or solution biases that might result in you delivering wrong or unnecessary solutions. 

Another benefit of building context of the delivery ecosystem is that it can help you and your team adjust broken delivery and governance processes that fail to achieve their intended risk management and awareness goals. This is a very common problem, especially with customers that have to deal with onerous legal and regulatory requirements. I dedicate an entire chapter in my book on this topic.

Finally, learning about the customer and delivery ecosystem helps you build connections with your the community paying for and using your service. This will be increasingly useful to help you refine your understanding of the outcomes your customers are trying to achieve, In some cases, you may even find that the community is larger or different than you first thought it was.

I have used such an approach many times with great success. For instance, when my team was delivering sophisticated decision frameworks and trading systems that were used by most of the equities and options desks at the big trading houses, it was invaluable to understand the dynamics of those ecosystems. Even though our primary users were Front Office traders, we had to also meet the needs of everyone from Compliance and Back Office functions to the exchanges, clearing houses, counterparties, and regulators. Understanding that ecosystem allowed us to build in the right sorts of features, security, reporting and controls to ensure the right set of outcomes were met.

#2 – Identify the pain points

More often than not, the full scope of the target outcome is obscured by various bits of noise, bias, and misdirection scattered throughout the customer’s ecosystem. However, one area that is easy to uncover are the existing pain points that are driving the customer to pay for their elimination. 

Identifying the pain points and understanding their repercussions can help you get a sense of what the desired outcome might look like, as well as what options might be available to move toward it. It might also uncover some ideas of useful ways to measure progress toward attaining the goal.

I was involved in one good example of this recently. A governmental organization knew that citizens and companies were struggling with waste handling. Illegal dumping was becoming a growing problem due to a combination of bad actors and an unnecessarily complex and opaque set of official handling processes.

These pain points made it clear that they needed to find a way to make the processes easier to initiate and track. Not only would this make it more likely people would have their waste handled appropriately, but the authorities could start to understand patterns to catch bad actors as well as better site recycling and disposal facilities.

#3 – Measure the “As-Is”

Once you have the pain points identified, you can start the process of figuring out the best measures to gauge your progress toward the target outcomes. A good way to do this is to take your proposed measures and create a baseline with the current “As-Is” state.

The value of doing this is two-fold. First, it test drives the utility of your measures. They should make the problems you identified really stand out, as well as provide a means to show whether the solutions you are putting in place are making a difference than can be measured in an easy and objective way.

In the waste tracking example, the baseline were the paper forms they were using.  A user had to get the form, and then figure out how to fill out its lengthy and complex fields. They then needed to find a waste hauler who could take the waste, fill out their part of the forms, and then take everything to a waste facility. The waste facility would then finalize the process. 

The measures were pretty easy to determine. There were

  • The amount of expertise required to find and fill out the form
  • The number of incorrectly filled out forms, identifying the problematic fields
  • The percentage of haulers and facilities successfully using the forms
  • The amount of time and effort each party has to spend handling the forms
  • The number of forms that have properly gone through the full process
  • The percentage of waste that is accurately traceable through the process
  • The percentage of legally disposed waste

The optimal desired outcome was to make the process so easy that an elderly person with no previous knowledge could fully navigate the system with ease to dispose of some old junk at their home.

#4 Track your progress

Measuring at the beginning is obviously not enough. You also need to track how much impact your solution has on progressing the customer toward their target outcomes. 

The best way to do this is by instrumenting your solution. Unfortunately, most organizations instrument their solution poorly, if at all. Effective instrumentation should fulfill one of two purposes:

  • Determine what progress along the measures you identified in step #3 has been made toward the target outcomes
  • Improve situational awareness to improve team and organizational decision making

The vast majority of service instrumentation focuses on more operational matters like numbers of users, load, errors, latency, downtime and the like. While these might have their uses improving decision making, they tell you very little directly about your impact progressing the customer toward the target outcome.

Going back to our waste tracking problem, we would want to instrument to track such behavior as:

  • Areas with clusters of abandoned journeys. This might indicate areas where the flows need to be improved
  • Rework. This might indicate complexity or confusion
  • Time spent handling the form, looking for places where excessive time is spent that might indicate a problem
  • Incorrect entries and mistakes, to find places to make the process less error-prone
  • Handling problems, such as journeys that do not go through from disposer through the hauler and the waste facility
  • Entry methods into the process, to see whether your solution is being used and making a positive impact
  • The percentage of accurately traceable waste through the process

There might be more measures, but these would be a good start to track how the solution improves the legal disposal of waste.

#5 Stay engaged with the Customer

Instrumentation provides very useful clues to your solution’s impact. However, nothing beats the value of delivery teams staying engaged with the customer and user community to ensure improvements you make to your solution are having the right impact. 

The reason for this is that customer ecosystems are dynamic. Shifts in conditions mean that a solution that might have worked well at first can quickly become cumbersome or worse. I have seen many companies fail to see shifts from thick computer-based client applications to browsers, from computers to mobile, static to responsive, and national to global

Another very important reason to stay engaged is that target outcomes can and do change. Sometimes this occurs because customers realize what they originally thought was their target outcome was wrong. Other times ecosystem events can invalidate or change target outcomes, or even add to their number. 

Finally, staying engaged allows you and your customer to learn and improve together.

Final Thoughts

To learn more about target outcomes, read my book Lean DevOps. I also recommend exploring the larger world of Outcome Delivery and the Mobius Loop framework.