The Power of Predictable Methods

Table stakes - Best practices and predictable repeated failure

Engineering projects often go badly wrong and waste large amounts of money and damage the mental health of those involved. The cause of this is often seen as deployment and quality failure. However the root cause of this is often the decision making frameworks.I don’t expect anyone to just trust me on that, but what I do want to show is that when we introduce some structure and analysis it is pretty simple to fix a lot of problems. We work in an industry that is confused because we are very bad at understanding the compounding cost of complexity we introduce through self imposed pressure to rush and reduce quality.

We do not understand the tremendous cost of breaking things down into multiple encapsulated and chained together parts. An example of how pervasive this is exists in job roles. As we become ever more specialised and people start to lose deep understanding of how it all ties together.

For example, we have delivery people who have never changed and deployed a line of code successfully to production, Product people who do not know the cost of the change they are suggesting and we have engineers who never get to talk to customers and really understand the product vision and timing of what is being built. Yet we have decision meetings that exclude 1 or more parties.

No C level executive wants anybody to push broken, reputation damaging work to their customers; and yet again and again by the time it gets to build (after many many months) the build (which takes weeks) is urgent and things like testing, observability, serviceability, audit, security get put under pressure to be dropped.

This completely undermines tomorrow’s work: it increases the volume required tomorrow by deceiving everybody that today was successful. This strategy is clearly terrible, so why do we repeat it? We constantly rebrand failures as success because they were not total failures, and survival is sufficient.

The cycle continues with an ever amassing pile of low quality rushed crud to wade through. This adds insurmountable pressure for a team that was incapable of delivering even before this pile was created, and the negative feedback loop begins. This isn’t debt, its abdication of responsibility. It is like investing in making the shop facade pretty but then not buying any stock. This is failure and the people running systems like this need to be held to account if they are unable to change it.

Our “best” practices cannot be best. They lack imagination, context, opportunities to exploit the current situation or to find novel means. They lack the unconstrained creativity that can only come from years of playing, and the joy that is to be found in facing and overcoming adversity together as a unique collection of people.

The cost of this constant failure is massive financial overspend and mental health of people.

The Power of Predictable Repeatable Methods - Surprise

When we know that when we do something and then repeatedly observe something else afterwards, we rapidly come to believe that we have a causal relationship from a very early age. Our brains are very good at habituating this expectation, which enables us to start having higher and higher levels of abstraction and prediction. For example, an experienced driver no longer thinks about how the steering wheel connects to the wheels to turn the car.

However, the real power of having the ability to predict is when the prediction fails because we immediately know that we have discovered something new - a new constraint.

We experience this as surprise. It is the basis of magic.

DALL-E3 image of cartoony cats trying to eat but being surprised, the text is all broken in sort of a cute way which adds to the slightly brokenness

Break Things to Learn (early)

This should really be stated as ‘test the extremities early’. This might be a connection or relationship to an external system, it might be the limits within which a thing works. Find the boundaries and test them

Action creates knowledge. Spend creates liability. We need to favour taking decisive, hypothesis-driven action as every time we do so we increase our knowledge and the potential future decisions we can make. This effect is multiplicative and compounding. When we do nothing / delay we not only increase our liability via spend but we lose opportunity and future choices.

Not having choice is the same as having no control - what we do might work, it might not. This is not predictable, efficient and certainly doesn’t sound like expertise or mastery. We have to take things that work in one place and experiment with them in other places in order to find the boundaries of knowledge - the limitations are what push us to find alternative frameworks.

By taking action and making choices against hypotheses and frameworks we put in place we start to build a repeatable predictable set of outcomes, through discovering what works. The predictability - for me - comes from some simple analytical tools which we will cover later.

Not having these frameworks with predictable outcomes and understanding of how these outcomes are valued is what causes cargo-cults and snake oil - examples of this would be anything 1/2 day courses that profess to give people a high degree of competency at a skill scrum master - one course has a 98% pass rate!.

Structural scaffolding as temporary and changing

This choice and structure doesn’t need to be dogmatic - but it does need to have repeatable results. The level of dogmatism required is often related to the level of failure. To get things under control it is often necessary to identify where the problems start and introduce structure. As predictability increases the scaffolding structure should be relaxed as everything is primed for learning. The purpose of the structure is a temporary guiding, a scaffolding to push to a state where it is desirable to remove it. We need predictability, active observations and expectations.

In the next posts we will look at some common structures, the problems that structuring work like this always causes and the refactor to fix them.

.