This might be the toughest thing to grok for highly motivated or driven folks. Beyond a certain scale of challenge, we can’t take it on alone. There’s lots of historical narrative to the contrary with nice linear paths to victory and point decisions made by one key person. Not surprising because it’s very hard for each of us to be aware of what others were doing alongside us at any point in time or track how their interactions contributed or didn’t (which is also true of our own). It’s well known that the act of recollection can actually create new (and false) memories that replace the closest thing we have to a truthful representation.

A capable individual contributor with a history of success must move from managing themselves to finding a way to create an orchestrated performance with others. This is likely at odds with their current skillset requiring empathy, influencing, careful use of language and emotion etc.

Control

There isn’t any. Actually, that’s not true, you can change yourself and shape your actions but those of others? Nope. They are their own person with a set of individual needs and purposes. Attempting to compel, manipulate or otherwise constrain others won’t yield a good outcome. Some folks know nothing else but these tools and will not change, steer clear of them.

So, no control of others and as it turns out, it’s the same for much else. The doing of big things creates complexity of interaction that one cannot adequately predict and plan for. There are some tools for coping with this reality such as risk management, limting downside and sunk cost etc. Few spend much time here, many organisations largely eschew such things in favour of faux certainty.

We must let go.

It’s all grey

Hindsight is a precise science and allows for all our biases to come out and play. In the moment of doing, choices are made with less than perfect information, outcomes are uncertain, the behaviour of things outside our awareness cannot be accounted for.

There are very few things we can know to be correct and many decisions represent tradeoffs amongst a whole bunch of variables we can generally only approximate (and often crudely) at best. Particularly for techies used to the world of code where binary rules and it’s either right or wrong, this is a hard thing to accept. More broadly, the education system conditions us to believe there is always one true answer available and we’re failing if we don’t get it. It’s important to realise that our performance is being measured in a highly structured environment with contained, well understood problems. The mindset we acquire in such a place has little applicability for big challenges that are inherently unconstrained.

Time To Impact

In a society where instant gratification is increasingly prevalent we’re losing the ability to manage for long periods without positive feedback. Given ”Success is 99 percent failure.” (Soichiro Honda, founder of Honda Motor Company) it’s important to accept that good things can be a long time coming.

The bigger the challenge, the longer that time coming will be and the greater the distance between any action we might have taken and the outcome.

Comfort

The process of pursuing a vision is a journey of self-discovery. Many folks shy away from holding up the mirror and taking the opportunities for better. They’d rather hide away and create a bubble of safety or comfort, avoiding what scares them. Some indulge in a form of misdirection, taking on seemingly scary things which, in fact, are attempts to hide from what genuinely frightens them. If you cannot admit to weakness, you are stuck. If you are unwilling to address it, you aren’t much better off.

One principle I apply often is to look for a single good thing in the bad. If we’re dealing in challenging things, there will be problems but they represent chances for progress. Mistakes are inevitable, recognising them for what they are in turn opening us up to improvement is necessary growth.

This is not about being endlessly tough and failing to look after oneself, there are going to be moments of vulnerability. The journey to something big requires we take breathers and diversions equally if it’s all gravy, it can’t be a genuine challenge can it?

The vast majority of features we ship won’t earn and must be pulled as soon as possible⁴. Their development represents a sunk cost that grows with time due to necessary maintenance (which starts as soon as it’s written because developer minds, other code and systems must account for its presence).

And because time is the ultimate judge², a feature that is highly utilised initially might become a back-water converting to a sunk-cost hence economic burden. Again, it must be pulled quickly.

It’s possible the 80% of features are consumed by “power customers” (the 20%) but this is long-tail economics. Increased complexity of development and maintenance for a small population of customers. Likely not the whole of the long-tail. A small subset. Edge cases.

Unless there is an exponential return³ on such features (and if there is, you might want to consider a separate product or offering for them), they constitute a loss on the bottom-line and delay other work which may be more valuable. The software industry (including organisations producing software for internal consumption) claims to be following a test and learn strategy via CI/CD, Agile, Lean etc to account for such dynamics but we must ask some questions:

1. Do you measure feature utilisation?
2. Do you have a pricing strategy that accounts for utilisation and cost to build and maintain?
3. Do you retire features?
4. Do you aggressively re-work a feature (or merely mildly tweak so hold to an artificially narrow and sub-optimal solution path)?

If the answer to any of those questions is no, it is highly likely you are a feature factory indulging in poor (business) practice. Your actions are out of line with the market, long-term success is unlikely and employees are probably burning themselves out chasing ghosts.

Of course, you might claim your org is special, not subject to an 80/20 feature rule but consider that it is reasonably likely 80/20 also applies to the population of orgs. So, are you really an exception, part of the 20% or in fact part of the 80% and deceiving yourself?

Footnotes

1. The Pareto Distribution
2. The Lindy Effect
3. Fat-Tail economics
4. You might claim that the cost of leaving an un-used feature in place is low but consider they are a distraction, unwelcome clutter resulting in an unappealing customer experience. Alternatives from competitors with cleaner, more coherent design will likely be preferred. Also note that clutter can prevent your customers from reaching features harming utilisation and loyalty.

[ Re-produced with additional edits and references from a thread I wrote ]

Why is it that the most innovative things seem to come from startups? There are of course exceptions such as Google-X, Amazon, Apple and Alibaba (all those A’s!). Nevertheless, if the executive chatter is given credence, there are lots of organisations out there trying to figure this out. Let’s look at the chasm again:

When an organisation comes into being in one way or another, not necessarily technically, it’s doing something different (hopefully) and figuring out how to make it a reality. It’s in a highly malleable state by necessity, it can’t afford constraints getting in the way whilst it determines the means to carry out its mission. It’s at the left of the curve.

But there comes a point where the means are established and now optimisation (efficiency) takes over. The organisation switches to honing what it has, adding more process etc and consequently more tightly binds itself to looking after the specific product (or service or …) that delivers on its mission. The organisation has shifted to the right of the curve above.

In effect, over time the typical organisation gets better (in theory, that’s a topic for another time) at looking after one product and worse at birthing new ones. It has no need for the latter in its pursuit of optimisation. Now we see the true nature of our organisational challenge: the rules and constraints we built for our current product stop us delivering genuine innovation, we are compelled to evolution only. That evolution is a killer:

1. You assuredly want to get markedly better at what you’re doing. And yet, no matter how many of those new practices and tools you adopt, it hasn’t delivered anything substantial in terms of customer benefit, has it?
2. For those genuinely seeking to create radical new products, you’re fighting against your own nature. The need to take risk on activity with no immediate revenue potential is systematically eliminated by corporate antibodies.

To sum up: An organisation must break its own rules if it is to innovate. Bob explains this in more detail. In the process he builds upon Goldratt’s technology questions, a device I’ll return to later.

Understanding Our Predicament

What might we do to meet the challenge we face? The first thing to realise is we almost certainly cannot determine all the ways in which our organisation is blocking our attempts at innovation up front. We need a Grand Experiment to find out:

Attempt to secure some resource for performing an Innovation Project. The chances are doing this will surface a long list of roadblocks to overcome. These are the corporate antibodies at work, compelling optimisation not innovation. There will likely be issues in recruitment, budgeting, accounting, roadmap, performance measurement and much else.

What qualifies as an Innovation Project? If you’re looking to move left on the chasm curve (a shifter) it’ll be adopting one of those new practices you’ve been keen to try or an exciting technology. For the builders, it’ll be an idea for a radical new product line or the kernel of an invention that will create new markets, shift economic dynamics etc.

Beware The Prevailing Corporate Mindset

A keystone problem we face in making the move toward innovation is the prevailing corporate mindset. It is likely to cast any new practice or application of technology in the existing optimisation light.

This is an immediate concern for shifters as it will prevent you from fully exploiting a move to the left of the curve and corrupt your forming of the Innovation Project in the Grand Experiment. For builders who will need new practices and technologies to support their delivery of an invention, this represents a significant hurdle.

You’ll need to get an unimpeded view of the practice or technology and how it should be. That is quite the challenge as many of the consultants you might reach out to and the organisations you might compare against are all stuck in the same rut as you.

Hard as it is, you’ll need to look in places you don’t normally look. I’d suggest touring some startups and gathering their views on who to listen to, their influencers, what they do, how they do it and why.

This is also an organisational experiment. You might well discover roadblocks in doing this.

The Grand Experiment

This experiment is an awful lot of work right? It’ll take ages, won’t it? Yes, if we actually did it all but we don’t need to. We can use a combination of informal talk (“what if we wanted to do x?”) with relevant colleagues and thought experiments (“okay so we want to try lean, what would that look like?”) to identify a lot of the roadblocks right up front.

Okay, we’ve “run” an the experiment, now we can take action, right? Almost. I promise, it’s coming but there’s a few more lessons to take away:

1. Any time someone tries something not in keeping with the current organisational rules, hence innovative, they will potentially encounter roadblocks.
2. As you proceed with delivering your innovative act, additional roadblocks will come up.

You must fashion and maintain means to detect encounters with roadblocks and capture the results for treatment at an appropriate moment.

Taking Action

It’s time to return to Goldratt’s questions and in particular the first four. They can be applied to any “technology”. Translated that’s not just technology but also practices, processes, capabilities and such:

1. What is the power of the “technology”?
2. What limitation does this “technology” diminish?
3. What rules helped accommodate the limitation?
4. What are the rules that should be used now?

In the previous section, we’ve set about identifying roadblocks in the form of rules and absent infrastructure for innovating. We can use the questions above to determine what “technology” might be used to deal with each of them. Where it provides an explicit treatment, we will see the roadblock feature in answers to questions 1 or 2. Where the roadblock exists as a compensatory or counter behaviour, we’ll likely see it feature in an answer to question 3.

What “technology” might we consider? Go fish! No, seriously, there’s a whole ocean out there to explore. It’ll be a constant endeavour because, as I mentioned in the previous section, you’ll always be discovering new roadblocks. However, if you were looking for starting points, Bob’s article (see above) contains a list to which I’d add Beyond Budgeting, Sprints (no, not those two week things), Scenario Planning, Idealised Design and also Clayton Christensen’s work:

The Innovator's Solution: Creating and Sustaining Successful Growth

After that, there are undoubtedly lots of bits of technology you might make use of particularly in the vein of “on demand services” like AWS, Azure and Google Cloud but also various of the SaaS products, the list is infinite.

One last piece of advice:

It’s very easy to go after new software products or systems infrastructure and feel innovative but, like it or not, the real roadblocks are in the organisation and these should be given serious consideration first whenever they manifest.

And an aside:

For the builders: The innovation you’re considering constructing is a “technology” in Goldratt’s parlance hence you can apply all six questions and use that to shape it for your target customers.

That is a conundrum I find myself pondering a lot. If it’s openly available, ultimately everyone else can adopt it too. The most one can hope for is to be doing it sufficiently before others so as to gain some kind of a substantive advantage.

The likelihood of advantage or gain drops the later in the adoption cycle you are. We need look no further than the classic text, “Crossing The Chasm”.

If you’re in the majority, you’ve already lost much chance of substantive gain. The bulk of it has been taken off the table, and there’s just fighting over the scraps with a large crowd. It’s the folks on the left who make gains, banking benefit as the curve rises steeply. Here’s the thing though: those early folks will have suffered much pain and cost in exploring and attempting application. Many of them will have fallen by the wayside.

The economics are a combination of Cost of Delay and Black Swan:

• Most in the early part of the cycle place the wrong bet and potentially incur painful losses.
• A few in the early cycle get the bet right and reap reward.
• The rest suffer lost opportunity proportional to the amount of time ticked by but also incur costs exploiting a vanishing advantage.

Of particular interest here is the last group. They are the majority, their competitors are typically in the same boat with very little chance of making hay. The claim each would make is that they must keep up with their competitors and yet none of them can reap any real advantage, it’s all gone.

Actually, it’s not all gone:

• Black Swan economics are such that it’s possible for one of these late comers to do something highly original but given their propensity for avoiding risk (hence late adoption) it’s unlikely they’d be sufficiently entrepreneurial to catch then exploit such an opportunity.
• Alternatively, it becomes a potential marginal gain (cost efficiency or minor uplift), and is it worth having given the cost of adoption, huge upheaval in roadmaps, re-skilling etc? I think the evidence says no or at least executives don’t buy it because they resist incurring these costs preferring sugar in the form of shipping more product. However let’s assume in isolation, the gain is worth having. How might it stand against other options for gain? Would it really be the “lowest hanging fruit”?

If one really wants advantage from new technology, one must be in early taking the attendant risk which apparently flies in the face of what a lot of industry prefers to do. The majority are repeatedly jumping on used-to-be-new technology with expectation of gains more in keeping with the left of the curve, getting disillusioned and disappointed, seeing little return and then doing it all again. Why?

I’d advocate a more pragmatic approach, getting more selective in your technology adoption practice. Put together some solid customer propositions backed by some real-world data with figures biased to a level of pessimism in regard to expected gains. If, in that light you still wanted to do it, fair enough.

Okay, let’s step it up a level now: If you really wanted the big gains, rather than being an adopter of new technology (even one at the left of the curve), wouldn’t you rather be the builder of that earth-shattering technology?

To do that means focusing on innovation. Not the evolutionary, slightly sharper knife type stuff no, something more in keeping with this:

Tesla Powerwall

Or this:

AlphaGo Zero: Learning from scratch | DeepMind

Delivering such a thing takes a long-term mindset, a level of risk and cost but with the potential for huge upside in keeping with Black Swan economics.

Few companies seem to have appetite for this but I can’t see how the claims of big benefit from the more common technology adoption practice stand up. How reliable could you ever be in getting to the left of the adoption curve? And are you honestly prepared to take the risks?

Remember that the big technology inventions come out of a series of slightly, sometimes wildly, wandering steps. It’s very easy to see the final product and be intimidated to the point of not trying it for ourselves but little exploratory steps (dare I say sprints?) are all it takes.

Okay, so you like the economic potential but you don’t want to take a Hail Mary bet. What do you do? Deliver features but ring fence an amount of your resource for experiments. Choose experiments to fit with the resource that you have available but could deliver a significant learning or new piece of knowledge. Don’t get myopically focused on delivering little bits of technology as that’s not got nearly the leverage of gaining in knowledge, understanding problems and solution options. Bezos says it best:

“It is our job, if we want to be innovative and pioneering, to make mistakes and as the company has gotten big — we have $100 billion-plus in annual sales, 250,000-plus people — the size of your mistakes needs to grow along with that,”

Protection vs Coercion

Let’s get this one out right up front: The original concept was designed to protect workers, to help them avoid mistakes and the associated trauma (personal honour is at stake and thus relates to happiness).

In software development we appear to be adopting a much more coercive construct which is known to be harmful to workers. The decision to adopt the term “forcing function” with its obvious connotations is interesting in that respect. Regardless, there seems to be an underlying assumption of setting a constraint to which teams will comply which in turn will yield certain results. This is at best naive, the application of a constraint in a complex (human) system is by no means guarantee of a specific result. In the context of typical reward systems, that’s setting folks up to “fail” and be “punished”.

Prevention vs Detection

An element of poka-yoke is prevention of an error or reliable detection at point of injection.

Software development groups (and their containing orgs) are largely focused on unreliable error detection that is remote from the point of injection via eg testing or frequent releasing.

We all know (don’t we?) that releasing doesn’t guarantee to reveal bugs. They can lie latent for a long time before they are found and one would suspect some are never found at all. This applies to both the product and its release machinery. By virtue of the fact we find bugs in production, it should be evident that testing is unreliable also.

If one were to postmortem at point of detection one could give the suggestion of prevention some credence but how many teams actually do this at eg the point of discovering a bug via a test? They might do it for a production incident but that’s hardly universal practice.

The fact is, many teams simply fix the bug or address the symptom and move on. They do not discuss preventative measures or seek to move the point of detection back upstream (which has economic benefits), taking only curative action which means they will make the same mistake again at some point.

Behaviour Change via Targets

Poka-yoke is associated with behaviour change.

I’ve observed software development groups and wider organisations define targets or goals, labelling them forcing functions, expecting a specific positive outcome in regards to behaviour change.

Targets and goals can be met in many ways and frequently we see cases where this results in the adoption of negative behaviours counter to the original intent. For example, shipping often or quickly has time and again caused development teams to cut corners, casting out quality related activity and operational essentials in regard to monitoring or failure handling.

Deming has much to say on this:

Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

and…

if management sets quantitative targets and makes people’s job depend on meeting them, “they will likely meet the targets — even if they have to destroy the enterprise to do it.

also…

I achieved my goal but not my aim. That happens a lot, we honestly translate aims to goals. And then we do stupid things in the name of the goal…We forget the aim sometimes and put the goal in its place.

Separately, the presence of a large number of goals and targets is evidenced to yield poor performance: Folks find it impossible to make an appropriate trade-off. If you’re entertaining the idea of having many mutually supporting “forcing functions” as an attempt to produce a behaviour then, beware.

Prevention and Behaviour Change in Software Development

It’s important to understand that the overlap between manufacturing and creating software products is fuzzy. We can most certainly learn from it but direct application of technique is less straightforward, care is required. What might we do then?

Back to Deming:

The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance.

So, we must change the system. Many orgs aren’t setup for genuine behaviour change thus cannot achieve prevention. They simply tune what they have, applying patchwork “optimisations” in hope of improvement (which they don’t typically measure), if they do anything at all. How many times, after a problem do we hear demands for more testing as opposed to something akin to “why didn’t our testing catch this? Are we doing the right things?”

We must start routinely questioning what we’ve done at the point of failure (in the spirit of Andon) and focus more on prevention, less on (remote) detection. Five why’s and postmortems can be used for this purpose but we must take care to place emphasis on challenging the status quo.

Facilitating this means blame culture and unquestionable rules as embodied in point responsibility and accountability must be eliminated in favour of something more diffuse.

Our efforts must shift to effecting double loop learning (see Argyris), digging past symptoms to work back to root cause(s). Note that there are challenges in root cause. Double loop learning means fundamentally changing how we think about problems and questioning currently preferred solutions, definitions of acceptable behaviours, our expectations and mindset.

None of this can force (nor should it) improvement but it’s better than unrealistically high expectations for a poor translation of a TPS concept into software development, surely?

I often hear folks say that building up tech debt is in the interests of the business. Techies IMO say this to avoid the difficult conversations that would otherwise follow. I can understand that, execs don’t like foul-tasting medicine.

Just consider that those execs are much like all the mortgage hangers-on and me-too’ers of the financial crisis. Some of them got bailed out (a mortal sin IMO), many of them sank without trace. They quite simply are not in a position to judge the risks involved. It’s up to us to make efforts in helping them get to grips with it.

A key blocker to our efforts is the most poisonous aspect IMO of the tech-debt concept. It tends to be a corridor conversation. At most it appears in priority discussions but by virtue of it’s apparent unimportance, it’s the first thing to be pushed off. It’s invisible death and we all contribute to keeping it that way. The elephant in the room (multiple metaphors, I know).

The fact of the matter is that tech-debt reduces your sustainable rate of change. Ironic in these agile-obsessed times don’t you think? It’s painting you into a corner in what is apparently a competitive world.

Of course, many of the competitors are just as messed up so you often avoid being knifed in that corner but is that really a chance you want to take? Tell me that isn’t a threat for the board to concern itself with?

We allow tech-debt to be invisible because we don’t track its consequences. Here are some things to consider measuring:

(1) Rate of releases per business component.

(2) Number of rollbacks.

(3) Size of team involved per release.

(4) Defect rates.

(5) Testing costs / time.

(6) Operational issue rates.

(7) MTTR.

(8) Incident cost — not just earnings lost but labour invested too.

You’d need many of those for reasons beyond tech-debt management so it’s hardly a specific or special effort.

Which brings me to: tech-debt isn’t special, it’s a bottleneck / risk like any other and should be measured / tracked / eliminated just as with others. It’s simply good business practice via ToC and there’s the real rub.

An awful lot of businesses don’t practice ToC, they’re barely aware of its existence often-times even when they might claim to be practicing lean. They leave big money on the table as a consequence. Is that good for business?

Of course not but, until the day that changes, I expect to see many more tech-debt laden organisations indulging in huge transformations which are in many cases the equivalent of chemotherapy prior to indulging in another long period of health-damaging, life shortening endeavour.

There is a better way, I’m just not sure anyone’s interested.

• A creator of solutions
• An innovator
• A solver of problems

But I am also a student of all the aspects that support this effort:

• Research and knowledge curation
• Method, practice and theory
• Environment
• Dealing in uncertainty
• The curation of teams
• Delivery, operations and decommissioning
• Systems thinking

All these elements are inter-related. One cannot divorce the supporting aspects from the act of engineering itself, they form the collective system necessary to the effort. They must be cared for as a whole, changes in one act on the others.

One must deal in all these things or none of them. You are either wholly involved or a remote influencer with limited input. The structure of manager and workers makes no sense in this system. Similarly the roles of product, dev, ops and test. It is a false division of the cohesive action required to engineer.

Such separation creates a pernicious circumstance that gives rise to the idea that one can be naive of various aspects of the system. This leads to ill-informed decisions with consequential impact on the quality of outcome.

An engineering team shares in all these things. Whilst an individual may have limited capability in some of these aspects, they must seek to understand all of them sufficiently to work effectively. Without this the group cannot act synergistically, there will be friction and waste created by lack of insight.

This realisation can create discomfort. We tend to identify with our roles, it helps us feel part of a tribe and gives us clear boundaries. Letting go of these labels is hard until we understand that we individually are our own unique labels, that our tribe is our whole team, we engineer together.

Related: The Toyota Production Development System

In my eyes it’s equivalent to asking if you are a follower of fashion. I’ll tell you right now, I’m not. My interest in a technology is driven from at least two alternative perspectives:

1. It allows me to achieve the most value for least effort. Value as in to my business which is serving humanity. Sometimes that’s customers.
2. It addresses the constraining bottleneck on achieving an end-goal. As in Theory of Constraints.

Sure, I keep an eye on what’s new on the radar, it may provide the best opportunity to address the perspectives above but it’s unlikely in my view for several reasons:

1. Adopting new technology is costly, complex and consequently high-risk. It may or may not deliver on whatever promise its vendor is making or other folks are asserting. Make no bones about it, the benefits of technology adoption are grossly over-rated perhaps especially in software.
2. The biggest bottlenecks an organisation faces are more often rooted in human belief systems related to how work is best done or how customers benefit, what they need or don’t etc. One can’t meet this challenge with technology.

But hot technology is a chance for innovation, right? Wrong. Everyone else is also looking at this stuff and trying to do things with it. How does one differentiate oneself in a crowd by doing the same things as everyone else? How likely is it that we will come up with something the others don’t? Innovation comes from unique invention, being maverick in thought rather than a member of the herd.

To me the pursuit of hot is one of the things that causes us to put technology first, before our problems. Consider the typical infrastructure overhaul. More often than not executed (think beheading) via an all-encompassing “upgrade” rather than with a more pragmatic approach such as:

1. Determine what things actually deliver significant value.
2. Determine what things might provide the greatest multiplier of value from such an overhaul.
3. Combining 1 and 2 to determine what might be worth the effort and what should be left as is or put to the sword.
4. Assessing the cost and risk of the efforts entailed in updating the items from 3.

Digital transformation also falls under this banner. Folks get so lost in “doing digital” they forget to keep a focus on why they’re doing it, the purpose of the exercise. This leads to a profusion of hugely disruptive (in a bad way) projects that produce little benefit. The internet is just another channel, rich with opportunities to be sure but one doesn’t need to pursue all of those when your chief problem is, for example, losing customers from your stores.

Brief aside: Digital transformation tends to come up in the context of having lost business initiative. It might be worth pondering how that happened before leaping into something else. Chiefly because if that’s occurred once, you may well be vulnerable to further blindsides.

When we focus on hot, it is putting the cart before the horse. We’re starting down the path of abstract creation without a base in reality and along with it pursuit of technology as manipulation rather than service. This has no place in professional engineering nor innovation which is the creative solving of problems not magpie-like acquisition of solutions looking for same.

Remember, what is hot today will be cold and dead tomorrow. There is no innate value in technology, it’s how you use it that determines utility.

On occasion, some even attempted to exploit such tragedy to their own advantage. Perhaps the most notorious of these was an incident (1961 Italian Grand Prix) between Jim Clark and Wolfgang Von Trips in 1961 at Monza, killing the latter along with 15 spectators.

Jackie Stewart is often credited with the initial impetus to improve the situation regarding safety — notably he was ridiculed at the time, sometimes even by fellow drivers.

Bernie Ecclestone brokered a deal (a tough one financially it would seem) with Professor Sid Watkins to turn the concerns over safety into real-world improvements. He undoubtedly succeeded though perhaps would say otherwise were he still alive.

F1 continues in this focus today and it’s work in regard of duty of care goes further still. There are curfews to protect the mechanics and enforced holiday periods.

Contrast this with the workplace more generally. We see an apparent increase in workplace health issues, a notable trend in problems of sleep deprivation, an inability to switch off and the persistent use of open plan offices in spite of the known harm they incur.

A sport, largely un-aided by regulation has got its act together. Meanwhile many companies, in spite of health and safety laws, show very little concern for their employee’s health. How might this have come to pass?

“Optimising one part of a system always leads to sub-optimisation of the system as a whole.” — Dr. Russell Ackoff

“Human error” is one explanation for failure in circumstances where this assumption is active. “If only that person had done the right thing, it would have been fine.” No one pauses to ask themselves how if the current approach is appropriate, a “mistake” could have occurred at all. The right approach would have anticipated and eliminated the opportunity for issues. Additional curative measures should surely be unnecessary?

This is single-loop learning. “Human error” is just one symptom (consider exhortations to work harder or with greater focus or increased care) of a category of behaviours found in organisations that lead to maladaptation followed by under-performance and eventually, extinction.

Metaphorically speaking, It is marching down a single path ignoring all turns in the unwavering belief that the desired destination is just around the corner regardless of signs from the surroundings suggesting otherwise. What about all those paths untaken?

Or to be more pithy, the definition of insanity is doing the same thing over and over again, expecting different results [1].

So to improve we need to be more ready to change approach then? Um, well it’s not that simple because our assessment of the current situation may also be wrong. The landscape is constantly changing by dint of our own efforts or those of others known and unknown (competitors, other teams in an organisation, governments etc) To select a suitable approach requires we grasp our situation sufficiently.

To do this requires double-loop learning in which we start to challenge:

1. Organisational and individual assumptions that drive collective practices.
2. Situational assessments at all levels of scope (including success measures).
3. Plans/strategies we derive.
4. Organisational structures.
5. Decision-making processes.
6. …

We’re talking systems and in fact, systems (teams) within systems (teams/organisations, legal & competitive environments, education system etc). Per Ackoff, we seek to optimise the whole not parts. We must focus wider than local concerns because everything is interdependent [2].

This is uncomfortable living and the majority of organisations prefer to shy away from it, bearing down on the “conflict” caused by individuals who embody such “controversial” thinking.

If you are ready to question though, here’s some material to get started with:

• Double Loop Learning in Organizations — Chris Argyris, the originator of the term double-loop learning, provides thorough coverage theory to examples.
• The Tao of Boyd — OODA (observe, orient, decide, act) is commonly and erroneously represented as a single-loop learning tool. This article in my view gets much closer to its true nature as conceived by Colonel John Boyd.
• Doing Things Right or Doing The Right Things — discusses the relevance of five why’s to double-loop learning.
• A Brief Guide To Interactive Planning & Idealized Design — Ackoff. What planning and effective change look like in a systems and double-loop learning world.

Embrace the chaos and uncertainty, know you’re fallible, learn to spot the signs of conflict between assumption and real-world feedback then adapt.

[1] Did you ever consider how non-adaptive the typical Agile adoption is? Just do your backlogs, planning, sprints, stand-ups and retrospectives properly and all will be golden….right?

[2] If you subscribe to Goldratt’s theory of constraints, interdependence means one bottleneck somewhere is dominant over all others and needs addressing first in the context of the whole. Whilst software development might be a bottleneck, assuming primacy would be a mistake. Note that bottlenecks come in many forms, they aren’t just about flow of work. One can have great flow but still be building products ill-suited to markets for example.