The OUTCOME, not just the outputs.

Everything we do has an intended outcome, be it at the macro or micro scale. However, everywhere I've worked, be it in FinTechs or Commercial Markets divisions of major UK banks, I've seen compromises being made when a piece of software comes close to release which prevent delivery of the whole of the outcome. Deadlines loom, bugs are found, things slip and, given that perfection is unattainable, some aspect of the delivery will fall short of goal.

Using OUTCOME as a mnemonic at the start of each slice of effort, be that a phase, sprint, week, day or task, teams look what is to be delivered from that slice and at some aspects of how we can engage with the deliverables. This can help teams drive everything to be closer to being ready when the release date arrives or, alternatively, to have a framework for discussions on compromises.

OUTCOME as a mnemonic? Here's one take on it. I'd be interested in hearing about yours.

Operational readiness?vs operational debt?

Transactional systems have processes which capture, manage, settle and reconcile those transactions between and within businesses. Post capture, everything else is some form of operational activity. Operational readiness (OR) describes the degree to which those operational activities are facilitated by the system whilst operational debt (OD) describes the degree to which these operational activities are manual.

Start-ups are likely to need higher degrees of OD in order to hit their time-to-market (TTM) needs so that they can start generating revenue. Established organisations are likely to focus on the removal of OD in the name of operational efficiency.

There is always a tension between these.?

Consider how what we're proposing to give to the customers, internal or external, with this release is going to move us towards OR or away from OD for this area of the systems' intended capability set.

User considerations

I have a number of friends who consider themselves non-technical. Some even consider going beyond email as a step too far.

When the deliverable is an API app in a B2B context, the users will be at the opposite end of that spectrum since they will be developing their own solutions using those APIs.

Irrespective, making adoption of what we're building as frictionless as possible to our intended user base will make those users product advocates.

Delivering a GUI driven app for the most technophobe user you can consider, mine is an octogenarian former opera singer, will have them singing your praises. If you are building an API, consider writing the documentation that they will reference when building their app and delivering the product which the documentation describes.

Technical debt decisions

Technical debt (TD) comes in many forms and, like OD, is not always bad when thinking about TTM. A working program with has repeated lines of code satisfying different if-then-else conditions may still give the user what delights them. The need to remove those repeated lines will be a TD item, given that the risk of defects and the maintenance overhead will be greater, when enhancing or updating the code. Consequently, re-factoring that code for optimisation should be added to a backlog, which must have time in the budget, but, still, the customer is delighted.

What can we do to minimise the addition of TD to, or remove existing TD from, the backlog with everything we're delivering?

Colleagues, Customers and the C-Suite

All of us have internal as well as external customers. How will what we're delivering work for our colleagues and be received in the C-Suite? Customers who are delighted at being able to transact at the internal cost of increased OD, creating or perpetuating more work in the operations/back office function, may so impact the organisation that it becomes unsustainable, financially or otherwise.

Increased OD may prevent the Chief Operations Office from meeting their targets, creating tensions within the C-Suite and demoralising the operations team.

What can we do to deliver for the whole?

Outputs - yes, they are needed

Stating the obvious, not everything is digital, yet. Some reports, reconciliations and other reviewable artefacts will always be necessary. Many regulators, tax authorities, shareholders and other system users may not have systems capable of consuming and processing our outputs electronically. In these cases, some part of the operations team will have to deliver those outputs in order to satisfy our overall outcome.?

Can we generate some 'helper' outputs to reduce the impact of any OD that already exists or that may be being introduced?

Motivated colleagues - the people we want to work with

All of the above O, U, T, C, and O topics can be used to take a fresh look at how we can deliver both for the customer and for the whole organisation. And why would we not want to look at these since we know that we stand or fall as a whole. Addressing just 1 pain point for each support function team each delivery cycle through small, incremental improvements spread can significantly boost morale and motivation.

Conversely, when technically functional releases cause negative impacts on other parts of the organisation, increasing OD and TD, whilst that can be accepted in the short term, in the long term resentment and frustration will develop, causing people to start voting with their feet. Bad enough when it is colleagues who leave but when customers or investors leave, then we're in trouble.

Excellence in all areas

In times when business is averagely challenging, organisations thrive when there is a constant desire across the whole organisation to improve something sustainably by 1% a day, recognising that perfection can never be reached but trying always to improve on the good that is already there.?

In times when business is extremely challenging as we're seeing in 2023, those same attempts at improvement can be what allows organisations to survive.

Over to you

The right business outcomes, when realised, will bring us success.

What can you do in your team do, as part of your next delivery cycle, on a daily basis to consider how to have an OUTCOME focus that is understood and worked towards by everyone on the team?

What marginal gains can be identified to reduce Operational Debt, improve User Considerations, limit Technical Debt and deliver for the Customers, colleagues and the C-Suite, creating great Outputs and thereby collectively creating Motivated Colleagues as we move closer to Excellence in all areas?

Please share your own stories of how team OUTCOME thinking has brought success for you and your organisation.

#outcomes #goalsetting