The IT Risk Manager

Alfred Nobel created the Nobel Prizes to recognize those individuals who had most benefited man-kind. Alfred Nobel was an entrepreneur who also invented Dynamite which he intended to be used to make mining safer.

The DORA metrics were created with the most positive intent. They provided a mechanism for development teams to demonstrate that they were improving in their ability to deliver software into a production environment. Like dynamite, used with the right intent, they are a powerful and beneficial tool.

The right tool in the right place for the right people

The DORA metrics help a team understand how effective they are at getting finished code into production. Deployment frequency is a measure of the transaction costs associated with getting code into production. If the transaction cost of getting code into production is low, teams can afford to do it more frequently. If it is too high, they have to wait until they have more value to deliver. The lead time for changes indicates the level of automation, in particular the test automation maturity. The change failure rate shows whether changes are successful or need to be fixed. Finally the mean time to recover shows how quickly the team can react to fix a problem in production. All of the DORA metrics are incredibly valuable at the team level, helping a team identify improvements in their process and diagnose whether they have been successfully implemented. For a team that wants to improve, the DORA metrics are the right tool in the right place for the right people.

Most cars today are what we used to call automatics, meaning that the changing of gears is automatic. The opposite of an automatic car was a manual (in the UK) or stick (in the USA). In a manual car, the driver decided when to change gear and manually changed it, pressing down on the clutch pedal, changing gear, and releasing the clutch. Much of learning to drive was learning how to perform this action smoothly and with little thought. To assist drivers, the dashboard of manual cars have two large dials… the speed and the rev counter. These two dials represented the most important information that the driver of a manual car needed to know. The rev counter would show the driver when they need to change gear if they could not hear it or feel it from the state of the car. The rev counter was so important it was given half of the valuable dashboard. In an automatic car, the car automatically changes the gears and as a result the rev counter is no longer consider useful to the driver. There is nothing that the driver can do if the revs are too high, or too low other than take the car to a mechanic and have it “tuned”. The rev counter on an automatic would be confusing and so the designers removed it.

Outside of the team, the DORA metrics are like a rev counter to the driver of an automatic car. Important but not their problem, and nothing that they can do apart from tell the team to go faster.

The wrong metric in the wrong place for the wrong people

Last year a large global consultancy with the ear of many business and technology executive, and little to no knowledge of technology told executives that the DORA metrics were a great way to measure developer productivity. They told the drivers of an automatic car that they should focus on the rev counter. The business and technology executives were delighted, realizing that there was nothing they could do to improve the DORA metrics. This meant that they could not be held accountable for failure to improve the technology investment process, and they could blame the technology teams for failing to deliver. The DORA metrics do not make sense to executives.

DORA works when a single team is delivering value to a customer. When more than one team is involved in delivering value to the customer, the value of the DORA metrics is reduced… just like the rev counter. In most large organisations it is difficult if not impossible for all teams to be able to deliver value to a customer independently. In most organisations, several teams are needed. Some organisations require teams to deliver value independently and that becomes more important than satisfying the most valuable need for the customer. Amazon is famous for creating a technology stack where teams could build valuable software independently but it took years of investment by skilled leaders and skilled developers, something many organisations have not been able to replicate.

The reality is that there are many things that executives can do to improve the technology investment process. The changes are things that the business and technology executives can improve but they tend to make worse. These changes do not show up in the DORA metrics but they do show up in “cross-team” metrics like the “Lead time* from starting an investment until it realises value for the customer”.

The biggest problem with DORA outside of the team is that it focuses on getting software into production, it does not focus on delivering value to customers. This simple difference has huge implications, and results in a metric that is valuable to leaders but toxic to the failureship as they will now have some accountability.

The wrong metric for cross team development 

There are many toxic aspects to the DORA metrics when used in a cross team delivery context: 

1. DORA ignores value delivered to the customer for cross team delivery. DORA can mean that teams focus on getting software into production, even if no value is delivered. This means that the teams get to “tick the box” of delivery even if the software does not work from the customer’s perspective. 

2. “Getting to production” rather than “Getting to value” means that teams adopt “Latent Code Pattern” strategies like feature flags. Whilst feature flags are a fantastic mechanism for prevent the need to synchronise releases over short periods of time, they introduce huge operational risk if used over extended periods of time. Teams find it hard to understand “what production is” if there are more than one or two latent code patterns in use. The Knight Capital disaster gives an indication of the dangers of not having tight control on “what is production?”. 

3. Comparing one team to another means that the same definition of DORA is needed. The same start point, the same end point and the same amount of work. This means that teams are forced to adopt standard processes to enable comparison, even though the process may add unnecessary overhead for some teams. If DORA metrics are used as a single team metric to show improvement only, rather than to compare teams, then each team can have its slightly different variant according to its context. 

4. DORA metrics are often built into “strategic” tool sets making it easier to measure them. Those teams who have not migrated to the “strategic” tool set may be discouraged from adopting it because the DORA metrics will show them in an unfavourable light. 

5. Change failure and the associated risk is understated in a cross team environment. Whilst an unused piece of code sits in production may not generate a failure, the same code may result in a change failure when another team delivers their part of the value puzzle and a failure is detected. Furthermore, the failure is incorrectly attributed to the wrong team. For example, team A delivers ten changes to production which do not result in a failure. Team B delivers code months later that uses six of the team A changes and a failure occurs. Team B delivers more code months later that uses three more of the team A changes and another failure occurs. Team B has two change failures and Team A may now have disbanded. There is another team A change sitting in production unused and untested. 

In a cross team delivery, Lead time for changes, change failure rate and deployment frequency should all use delivery of customer value as the end point, and not deployment of software into a production environment. Unfortunately, this is unlikely to be adopted by most organisations with cross team deliveries as business and technology executives have a huge impact and thus responsiblility for the metric. 

In a cross team environment, using delivery of customer value as the end point results in the following responsibilities for business and technology executives: 

• Ensure customer value is delivered. This is easier than it sounds. If a customer uses a features, and comes back and continues to use the feature, then the feature has delivered value to the internal or external customer. If the customer uses the feature once but never comes back (day one churn), then the customer has a need but the feature does not meet that need for some reason. If the customer never uses the feature, then they cannot find it, or it does not satisfy a need for them. 

• Ensure teams collaborate and communicate. Often team are working in a feature factory or ticket processing hell with no awareness of the value of their work. Business and technology executives should ensure that teams are working collaboratively together to deliver value to customers. 

• Limit work in progress. Business and technology executives should ensure that teams are not being forced to do too much work in any period. For those teams that act as a constraint on the organisation’s ability to deliver, the teams should have a clear priority order for items which is consistent across the organisation and agreed by ALL stakeholders. 

Obviously business and technology executives should also ensure that items delivering value to customers are also delivering the appropriate business value to the organisation… but that does not relate to the discussion of DORA metrics. 

In a cross team delivery environment, the DORA metrics can lead to harmful behaviour if they are used to compare teams. The DORA metrics should only be used within the team to help them improve their processes. Using DORA metrics outside the team can lead to the wrong behaviour. Just like story points, they are an optional tool that teams can use but no one outside the team should use them to judge a team, or compare teams. Anyone suggesting the use of DORA metrics or Story Points outside of the team clearly does not know what they are saying and should be shunned for the safety of the organisation.  

* Experts will realise that I’m referring to Cycle Time rather than Lead Time. Non experts do not know the difference between Lead Time and Cycle Time and do not care. This post is targeted at non experts.

For over a decade, I have been helping organisations, mainly very large ones, transform to adopt a product way of working. Typically this means:

1. Customer centric rather than organisation centric.
2. Outcome focused rather than output.
3. Leadership rather than Failureship.
4. Frequent delivery of small things instead of infrequent delivery of big things.

Many of the changes associated with Product Transformations are the same as those associated with Agile Transformations.

As such, based on the many mistakes I’ve made over the last decade, and the signals I’ve read in the entrails of LinkedIn, here are the anti-patterns we should expect to see as the Product Community of Solutions misleads its customers over the chasm.

• Context free
• Organisation Structure
• Roles versus Accountability
• Big bang!
• Process over risk
• Product Owner Coaches
• Thought Leaders
• Certification
• Wannabes
• Cost reduction

Context Free

2025 will see the mass marketing and adoption of context free solutions by product coaches and consultancies. Standardised product processes will be imposed on teams, and practitioners who suggest context specific approaches will be pushed out of the door.

New roles will pop up across the organisation and on LinkedIn, though most will be satisfied internally. PMO will be transformed into Business Value coaches and OKR magicians. Business Analysts will discover that all along they have been customer persona whisperers, Needs harvesters and big jobbies to be done facilitators. Project Managers will transform into Project Managers, who continue to undermine any effort to effect change because they can!

In giddy excitement, large organisations with product organisations consisting of tens and hundreds and thousands of products will spend a fortune on consulting and training from people who have never worked on a successful product, or worked in a company with more than a few people, or developers with no experience with product because they are known as excellent “executive whisperers”

Product practitioners will watch in horror as context free PowerPoints are built in front of their eyes. One size fits all processes will be forced on them. Practitioners will learn to fear the word “mapping” as it indicates a developer has rebranded a practice as their own, though they barely understand it. They will need to drop existing practices or hide them, providing positive experience reports at the “mapping anonymous” meeting organised by the “mapping community of practice”.

Continued unfulfilled demand will entice unsuspecting graduates to spend their future income on training in an attempt to jump on the product bandwagon causing a massive debt burden to the graduates. The side benefit will be graduates see university fees as the bargain they were compared to the cost of a series of two day training sessions running around the street talking to strangers about “Product”, “Needs” and “Jobbies”.

Organisation Structure

Having learnt from the Agile fiasco, everyone now knows that the real money (high day rate) is advising senior executives on how to engage in an unnecessary reorganisation.

Rather than focus on responsibilities and the skills needed to fulfil them, consultancies, coaches and thought leaders will focus on new departments and new names of all things organisational.

Expect to see teams renamed as squads, then crews and finally complex adaptive flights. Products will be called value streams, value constraints and enabling streams. Every team will be forced to contain an expert in complexity thinking who will use NLP to address the conflicts generated by the complexity of team interactions.

Executives will be abused if they fail to adopt complexity based organisation scaffolds that have been proven to work at scale… At scale meaning four close friends successsful got the idea to work for three days at a conference in Abeline, Texas.

Roles versus Accountability

New roles and job families will spring up across the organisation. Product Owners, Product Managers, Product Directors and Product Executives will be lead by Chief Product Officers who also lead infestations of Customer Whispers, Customer Analysts, Customer Managers, Customer Developers. Customer Testers, and Customer DevOps engineers.

Once people have transferred into one of the new strategic roles, they will continue to work in exactly the same way as they did before, they will not learn anything new or try any new techniques as they are perfect in the new role “just as they are”. This will be validated by their huge pay rise and large guaranteed bonus.

No new role will have any associated accountability. People will be rewarded regardless of whether things get done.

Big Bang!

The new product organisation will be implemented as a big bang. One day the organisation will be successful with millions of customers, the next day it will be a product organisation!

The product organisation will be built from scratch in a WeWorks office. Those in the know will be subject to an NDA (never do anything) agreement that forbids communication with the rest of the organisation.

No consultant, coach or thought leader will consider the implication of culture or the power struggle over who makes decisions between the existing organisation and the new unicorn organisation. Popular names for the NDA project will be “Illuminatus”, “Titanic” and “Thirteen”.

In order to ensure success of the new way of working, executives will insist that trusted individuals lead the new organisation. The trusted individuals are the ones they have used to lead every other transformation effort that failed. These leaders will be supported by the consultants, coaches and thought leaders who failed with the agile transformations. They learned from the agile transformation failures and doubled their day rates, using search and replace to remove “agile” and replace it with “product”, and replace “train” with “customer”. “Mapping” will be replaced by “Mapping”…. Because it sells well with developers who hate the word analysis.

Process over Risk

Members of the product operations teams will be told to simply “Follow the process to guarantee success”.

Every product tesseract will be governed by the Product Trio, consisting of a Product lead, a Technical Lead and a Design Lead. The trio will ensure that all journeys follow the process.

The trio will ignore risk and common sense. The organisation’s articles of association will be rewritten to guarantee all trios have a design lead regardless of whether the biggest risk is the customer or some other risk like testing. In a landmark experience report a designer at CloudStrike will show that a beautifully designed API is more effective than one that has been tested.

Product Owner Coaches

Riots will break out spontaneously across the world when people realise that every single person on the planet, all eight billion of them, has been trained and then coached in the product owner role.

Product owner coaches will finally admit that they have no experience of product and go back to working as PE teachers in public schools where they honed their rucking skills.

Thought Leaders

Once the budgets for creating Product Organisations are known, thought leaders from every possible background will realise that they are experts in product and have transferable knowledge. They will leverage their “fame” and “pulling power” to convince content starved conferences to let them deliver keynotes with the following set of titles:

• The product organisation
• Product Operations and me me me
• Product Operations Organisation
• Product Organisation Operations
• Complexity informed Product
• The people’s front of Product
• Sensemaking IS Product
• Test driven Product
• Refactoring Product
• Product Product Mapping Mapping
• Product Product Product Done Done Done
• THE product retrospective
• THE retrospective for product
• Product of Product
• Product 3.0
• Product Typologies
• Product People’s Front
• Lean Product
• Value Stream Product
• I need a job but I’m irrelevant
• Product Play
• Product Games

The thought leaders will present ideas that are just plain wrong, or present ideas they have stolen from practitioners as if they were based on their own experiences. Of course the presentation will be great, just the content will be rotten.

Expect to see new shiny product frameworks or a product bolt on to a dodgy unreliable framework from your favourite thought leader this year.

Certification

In 2025, a large consultancy will announce “Product Executive” certification. Their extensive customer base will be told to only engage in a product transformation if it is lead by someone holding the PE cert. The PE cert will be experience based, and only be available to the following:

• Customers who have committed $50 million consultancy fee to the large consultancy, for a product transformation. These customers will need to sign an ignorance waiver indicating that they will ignore all advice or knowledge not provided by the large consultancy.
• Partners of the Large consultancies.

The large consultancy will enter into a joint venture with the private equity firm that owns popular “little people” certification firms to create a “Product Executive Wannabe” certification. By the end of 2025 every scrum master, coach and consultant will be a certified “Product Executive Wannabe”. The full wannabe training experience will cost $42,000.

Copy cat certification schemes will appear with names like “Product President”, “Design Executive” and “Product Design Obeya”.

Certification firm’s market capitalisation will surpass those of Alphabet, Invidia and SpaceX combined… but only for forty two hours.

Wannabes

One of the most toxic personas in the transformation space are the wannabes. They are desperate to get the role so that they demonstrate to their Product Guru that they have practiced all the techniques they learned about on their Product Priestling course. They can prove to their Product Guru that they have achieved Thetan level four and are now ready to co-train with a Product Guru.

Wannabes want the job title but have no interest in the organisation or its goals. Wannabes will tear apart everything and risk everything to please their external Product Guru.

Although they look good on their resume, and interview well, if they have ever been part of any of the Agile Cults, then give them a wide birth, especially if they say they are “Pragmatic”. The word “Pragmatic” means something different to them, and you ain’t gonna like their meaning.

Cost Reduction

It does not matter what it says on the transformation tin, inside it contains “reduce cost”. That means sacking people who earn more than average and employ people who earn a lot less than average. At the same time, hire your incompetent friends to lead it but they are part of the Capex budget and have been for the past decade.

When a company with millions of customers hires a product expert who consulted with a start up that had seven customers and lost two, you know they are not really interested in the customer.

The customer focus is really a mechanism to undermine the people who currently run the company and keep their millions of customers happy.

The new CEO will hire VERY expensive consultants who will discover that operational costs are much higher than previously known, mainly due to the expensive consultants.

The share price will drop.

The CEO will be offered share options to rescue the organisation. The CEO will announce a customer focused product transformation.

The transformation will be used to hammer down operational costs by sacking difficult (high cost) individuals.

The share price will soar and the CEOs options will explode in value.

CEO cashes in options and retires.

Organisation experiences serious operational failures.

Organisation hires very expensive consultancy.

Very expensive consultancy recommends another of its partners as replacement CEO

New CEO recommends selling all the organisations valuable assets to another organisations that is undergoing a DevOps Product transformation lead by the Large consultancy.

Summary

In 2025, expect the Product Community to experience the same highs (rich thought leaders) and same lows (depressed partitioners) as the Agile, Lean, DevOps, and Gold prospecting communities before them.

Instead of rushing to get the latest certificate, try to get some experience in real work. You know, it’s actually kind of fun once the transformation circus leaves town.

So Happy New Year! And can someone pass me the pop-corn, it’s gonna be a fun one to watch.

One of the most misunderstood concepts in software developments is value streams for software. This is particularly true in organisations with a Failureship culture where value streams are seen as a solution to show you how to create an organisation chart for your software development teams. In software organisations with a failureship culture, parts of an organisation will be bundled together into a value stream. The value stream will normally be a rebadging of an existing organisation following a rather expensive analysis by a consultancy with no knowledge of software, lean or agile.

What is a Value Stream in Software?

A value stream is a set of processing steps that create something of value. In manufacturing where the term originates, the value stream is static. If you want to create a physical widget or a car or a space rocket, the same processing is needed to create the same thing of value. As a result it makes a huge amount of sense to organise around the value stream, to organise around the processes that create something of value to the customer, so that the delivery of value can be optimised.

There is something very very obvious about value streams… The value is in the output. The customer gets value from consuming the output produced by a value stream. That means the processes and inputs in a value stream can all be changed as long as the output that the customer needs remains unchanged or is improved. For this reason, value stream mapping should start with the output that satisfies the need of the customer and work BACKWARDS to the inputs, something that experts and consultants rarely do. In software, working backwards was summarised by Jenny Martin as “OOPSI” (Outcome -> Output -> Process -> Scenario -> Input).

There is a HUGE!, MASSIVE! GINORMOUS! difference between production of software and the production of physical goods. Everyone knows it and it has a profound impact on the concept of a value stream… but is generally ignored by thought leaders, experts and consultants. The value stream in the production of physical goods is optimised to produce the same physical thing MANY times. The value stream in the production of software only ever produces a thing ONCE! Software development never aims to produce the same thing twice or more. NEVER EVER EVER! Whereas production of physical goods optimizes the value stream to produce the same thing many times, software only ever produces a thing ONCE!

Now let me address the screams of horror from the devOps community. There are repeatable processes within software development that can be treated as value streams, deployment of software to testing and production environments, and the repetitive operations like account provisioning and daily batches. Creating new software investments and Bug fixing are NOT repetitive.

A software value stream is the group of teams that need to collaborate in order to deliver something of value to a customer and as a result generate business value for the organization. The value stream is the teams required to deliver an investment. The value stream is not a group of teams that work on the same product or system, or share the same manager within a silo.

Rather than a “Technology investment”, it should be referred to as an “Investment involving technology”. This is because investments involving technology may also include the following non-technology teams that need to be included in the value stream:

• Legal
• Compliance
• Architectural Governance board
• Customer help desk / Call center
• Support Teams
• Sales
• Marketing
• Training

Creating a value stream in software is a very simple two step process:

1. Create a list of investments involving technology.
2. For each investment, create a value stream by listing ALL of the teams needed to deliver the investment.
   • 2a Add all the obvious teams needed to deliver the investment.
   • 2b Now add all the software teams needed to deliver the investment that are outside of your department.
   • 2c Now add all the software teams needed to deliver the outside of your company.
   • 2d Now add all the support and adoption teams that are needed to deliver the investment.
   • 2e Now add all the governance and compliance teams that manage stage gates and hoops that the teams delivering the investments need to jump through.
   • 2f Now add all the non software related teams that are needed to deliver the investment including Legal, Human Resources, Sales, Marketing…
   • 2g Keep looking out for more teams needed to deliver the investment.

You will end up with a set of investments and associated value streams as shown below (each investment/value stream has its own colour):

There are a number of points that are easy to understand from the diagram:

1. The value stream is dynamic. Potentially each investment can involve a different set of teams.
2. Work should be coordinated and managed focused on the value stream, or in other words the investment.
3. An individual should be assigned the responsibility for coordinating the value stream activities to ensure they are focused on the delivery of the investment.
4. The scrum of scrums and retro of retros should be set up for the investments/value streams.
5. There is no value having a scrum of scrums for the department. A scrum of scrums for the finance department or operations departments would by definition become a status meeting as the teams are not working towards the delivery of the same investments.
6. A department focused retro of retros is valuable to agree cross team improvements, perhaps about standards around like code quality, technical debt or test automation practices.
7. Where the same two teams or even same sets of teams repeatedly appear in the same value streams (e.g. General Ledger2 & Regulatory Reporting, and Payments1 & Discounts above) it may be worth merging the two teams and splitting them into two new teams that can cover the responsibilities of the two original teams. This situation occurs because the original teams are system aligned rather than value stream aligned.

Static Value Streams as Organisational Units

Occasionally investments will always involve the same value stream. In this case it is possible to create a static value stream by using the value stream as the basis for a permanent organisational structure. If this is done, the organisation should be vigilant for changes that result in investments that need teams outside of the value stream organisation department.

Strategic and not so strategic consultancies derive huge fees from their clients for helping them with “Org Design”. As a result, consultancies without understanding of the delivery of software investments like to create organisation based on “value streams”. The consultancies are fortunate because sales driven certification schemes promote this practice in the form of “Agile Release Trains”. An agile release train is an arbitrary group of teams that are currently owned by a single department that are thrown together to coordinate their delivery, even though they are not working on delivering the same investments. The static values stream or “Agile Release Train” approach is demonstrated on the diagram below:

The diagram shows that the static value stream or “Agile Release Train” cuts across the real value stream required by the investments. It focuses the cross team coordination on the wrong teams, the coordination and planning is focused on the teams owned by the same manager rather than the teams that need to work together to deliver an investment. This means that roles are required to coordinate activity between the static value streams or “Agile release trains” and the teams do not directly collaborate in a scrum of scrums.

If you can fit the entire value stream inside an Agile release train, you are likely to be successful in your implementation. If you cannot fit the entire value stream inside the Agile Release Train, you are likely to result in a waterfall style project manager lead nightmare. This is clearly beneficial to consultancies who provide project managers to clients and have trained hundreds of thousands of consultants in practices that most agile practitioners do not consider to be agile. This is why organisations who make extensive use of consultants adopt Safe. All of the consultancies are promoting Safe because they have heavily invested in “Agile” (but actually Safe), and they normally do not have deep experience in Extreme Programming and test first automation (Specification by Example, ATDD, GivenWhenThen). The decision for the client is made easy, “We have decided to adopt Safe because all the consultancies have promoted it, we just need to choose one of trusted partners to lead the implementation”. Although this might appear to be failureship by the consultancies, it is not. When we approached the consultancies and explained we wanted to do something better, they were very helpful and supportive, agreeing not to promote Safe to anyone in our organisation. The failureship is the individuals and companies promoting Safe to the consultancies when they know it only works in certain contexts.

Value streams result in the delivery of value to customers. If your “Value Stream” is based on a system or department and it needs to work with teams outside of your “Value Stream”, then you are part of a failureship anti-pattern.

You might think that escalations were needed to ensure that the constrained resources of an organisation were focused on the highest priority investments. The true purpose of escalations is to validate and confirm the status and importance of senior staff and executives, and re-enforce a high power distance index. Escalations are yet another sign of a risk averse failureship culture. Escalations are a symptom of multiple dysfunctional processes within the organisation. Escalations are not only symptoms, they are also the causes of dysfunction. Escalations disrupt and often prevent process improvement, especially the process improvement that would remove them. This reinforcing feedback loop means that escalations need to be addressed as the corrosive practice that they are before genuine improvement can occur.

Jabe Bloom interprets Elliot Jacques work on the levels of organisations showing that more senior individuals work further into the future. The levels of responsibility of a technology might be described as:

• Development team – The current sprint.
• Product Owner – The next sprint, ensuring stories are ready for the development team.
• Project Manager – Ensuring product owners and development teams are aligned for the current quarter.
• Programme Manager – Ensuring there are enough development teams (capacity) for the commitments made by the organisation in the next quarter.
• Head of department – Ensure that there is sufficient funding in place for the teams that are needed, and that the organisation is funding investments in technology and practices that it needs to improve.

The larger the organisation, the further into the future that the senior executives will be operating. The CEO of a start-up will be focused on funding for the next quarter. The CEO of a multi-national will be building relationships with governments for investments that will take place in decades to come (Oil pipelines, Theme Parks etc).

The head of department’s responsibility is to ensure that the organisation improves ready for the challenges it faces the following year. They should be building the organisation from six months to a year into the future. The problem is that it is difficult for senior executives to demonstrate their “power” when the results are shown in the future. They have a difficult task and getting people to engage in improvement processes is hard. By comparison, an escalation occurs in the present. It presents senior executives with the opportunity to demonstrate their power by “getting things done”. Escalations reinforce the power distance index that support the risk averse failureship culture. Ideally an escalation will allow one executive to prove to all involved that the work they are doing is more important than other executive’s work, and by association the executive is more important than other executives. Escalations are ambrosia for individuals in a risk averse failureship.

Escalations are a symptom of a number of organisation dysfunctions but they also act to perpetuate these dysfunctions, which include but are not limited to:

• Planning – Escalations often occur as the result of poor planning, preparation and communication on the part of individuals responsible for delivering an important outcome. They assume that the high status of their work justifies their lack of planning or notice to dependent teams. Furthermore, when they are given a date that is too late for their liking, they simply escalate. The impact of frequent escalations is that the teams delivering the work are themselves unable to plan which means they need to escalate to meet the demands of the individuals escalating against them. The result is an organisation that is unable to plan and which has a severely damaged ability to deliver value.
• Productivity – In Lean terms, escalations are the ultimate task switching. They are muda, or waste, as the teams switch from one investment to another and then switch back again.
• Stress – Even worse than planning and productivity, escalations have the same stressful impact as a severe production incidents.
  • Individuals involved in an escalation are forced to drop their work, focus on the escalated issue, and then pick up the work they were doing before. This is not as easy as it sounds as most work done in modern organisations require collaboration between team members and teams. Escalations disrupt that collaboration.
  • Individuals involved in an escalation are expected to work “above and beyond” to resolve the situation, working extended hours, weekends, and cancelling planned events and even holidays. This is the perfect situation for people who want to raise their status and are prepared to work long hours.
  • Escalations can damage relationships, especially if the justification for the escalation is not considered fair.
  • A culture that tolerates frequent escalations leads to burn out and ultimately high staff turnover, with the most competent risk managed individuals leaving as they understand a better way is possible.

Escalations are toxic to an organisation. The reason that they happen is because the people who should be eradicating them are also the people who get validation and an ego boost from them.

Step one to eradicating escalations is to understand why they are occurring. It might be best to treat them as high severity events and perform a root cause analysis on each escalation. Knowing that they will be investigated might result in many of them disappearing altogether as the people that normally raise them would not like to be exposed as incompetent.

Once we understand that individuals in a risk averse failureship culture benefit from escalations in terms of status, lets understand what the real causes of escalations are:

1. Unexpected external events – A valid reason for an escalation. Examples include the Cloudstrike event and Russia’s invasion of Ukraine. In these cases, everyone in the organisation would understand the importance of addressing the event and escalation would not be necessary.
2. Anticipated external events – Not a valid reason for an escalation. Often, an organisation’s activity is dependent upon an external agent that they do not control. A decision by a customer, a ruling by a court, a directive from a regulator. In all these situations, the organisation can plan for the contingent event. Tools like Real Options, and Shell’s Scenario Planning made popular by Peter Senge’s “The Fifth Discipline” are ideal for contingent planning. Organisations should build a proper risk register rather than engage in risk management theatre. A few examples of how to handle these events.
   • A customer might be about to sign a contract that has an impact on the work done in the next quarter. If the contract is not signed we go with “Plan A”, and if the contract is signed we go with “Plan B”. We organise the work so that we can minimise the impact if we switch from “Plan A” to “Plan B”.
   • It was not possible to recruit the necessary resources. Planning for the current period should be done based on current resources, not planned resources.
   • Key individuals left the organisation. Leaders should manage key man dependencies using a skills matrix. They can use the skills matrix to consider different scenarios regarding people leaving and ensure they are not exposed to gaps in knowledge and experience.
3. Unexpected internal event – Things happen that we cannot know when or how they will happen. A machine or a network might fail. A hacker might breach the security of the organisation. An incompetent provider (CloudStrike ?) might perform an unintended ransomware attack from inside the firewall. Escalations are not relevant for these types of situations, as they are operational “SEVERITY-1” events that all relevant persons should focus on resolving. Although unexpected, they should be planned for using Real Options, Scenario Planning and a proper risk register, especially if they have not occurred before in the organisation.
4. Planned internal event – Sometimes leadership will spring a change on the organisation like a merger that results in multiple escalations. The escalations are due to poor planning, poor communication and poor executions. If the leadership is not able to share the details, they can at least inform key individuals under an NDA (Non disclosure agreement) to plan and prepare communications.
5. Poor planning – The most common causes of escalations are poor planning, poor preparation and poor communication. Escalations due to poor planning are a symptom of poor leadership, poor management and poor collaboration. They are a symptom that people in the organisation are not competent and that leaders have not ensured that the people in their organisation are experienced to perform their responsibilities.

When an escalation occurs, perform a root cause analysis. If the cause is poor planning, no one involved in raising (teams), promoting (middle managers) or sanctioning (leaders) the escalation should receive a a pay rise, bonus or promotion as they have demonstrated that they are not competent in their current roles and should not be rewarded or considered for further responsibility until they have shown competence at their current level. The leadership should understand that they have failed, and should be coached to understand how to run an organisation using risk management techniques rather than status and ego driven power.

Always remember that the real purpose of escalations is to allow incompetent senior leadership to demonstrate their power.

Karl Weick’s Sensemaking is a powerful frame to understand how organisations work. It can help us better understand Failureship. Paraphrasing, he identifies four stages of understanding:

• Intra – How a person understands something inside their head.
• Inter – How two or more people understand something.
• Generic – How something can be understood generally, making it accessible to others.
• Extra – How something can exist in its own right outside of the relationship with the people (e.g. Maths).

Weick describes sensemaking in organisations as the process of moving things from “Inter” to “Generic” so that others can become part of the organisation and act using the thing.

The key part of sense making is to create “shared meaning”. Shared meaning indicates that the value of something is understood. As value is socially constructed, it means that the value of the thing is understood in the context of an individual’s social organisation. “That’s just Common Sense” means that something previously not encountered aligns with the values of the individual’s social organisations and should obviously be adopted. This understanding of Sensemaking is very aligned with social practice theory ( meaning, practice and material ) which forms part of Marc Burgauer and Chris McDermott’s Maturity Mapping.

Sensemaking is an activity, not a tool.

Luke Hohmann, creator of Innovation Games worked for Karl Weick. Once you understand that, you see Innovation Games in a whole new light. They are not tools to achieve a purpose, they are enabling constraints that structure Sensemaking. Consider one of the simplest games “20-20 Vision”. Compare items one at a time and build a strictly ordered list. The output is an ordered list but the outcome of the Sensemaking is a shared understanding among participants (Inter) of the relative value of the items including why they are valuable, that can be articulated and shared with others (Generic). 20-20 vision constrains the discussion so that it focuses on the value needed to order things rather than deep dive into the detail of the description or implementation of the things.

“Buy a feature” also acts as a Sensemaking enabling constraint, facilitating shared understanding of why users value features, rather than the details of features. Budget Games in San Jose have demonstrated that “Buy a feature” is a Sensemaking practice that scales and enables an entire City to created a shared understanding of the value of each product and service provided by the City to its people.

Sensemaking and Naming Things

Sometimes the act of Sensemaking will identify a new thing. In order to make it quicker and easier to refer to that thing, the community of practice will give the thing a name. The names of things are often chosen out of respect for the ideas that inspired the new thing. Agile is full of such names:

• Scrum – Inspired by the practice in rugby.
• Kanban – Inspired by Kanban systems in manufacturing.
• Feature Injection – Inspired by Dependency Injection.
• Stories – A group of developers sitting around the camp fire listening to the customer tell them a story about how they will use the thing they are creating.
• Epic – A big story that is too big and needs to be broken down.

The name is not important other than a search term. What is important is the shared understanding.

The meaning of the word “Jargon”

Members of the community of practice use the new names they have chosen for the new things to communicate effectively and efficiently. Outsiders are often confused by the language that is only understandable by learning what it means, by engaging in the shared understanding of the terms. Outsiders refer to the language used by the community of practice as Jargon, an indication that they consider the language to have no value… mainly because they do not understand it and it has no meaning to them. Calling something “Jargon” is the equivalent of referring to a foreign language as “noise”. Saying a computer programmer is speaking “noise” or that a person speaking a foreign language is speaking “Jargon” is normally a sign of cultural imperialism or cultural superiority, putting down the language of another group as unimportant and valueless.

Colonialism and Terraforming as an approach to Change

Cultural Colonialism and Terraforming are a popular approach to introducing change into organisations. Executives use consultants to impose new words and tools onto the organisation. They employ experts and high priests and priestesses to impose the use of the new words and tools as a mechanism to drive change. “Teams” are replaced by “Scrums”, “Squads” or “Feature Team”. Departments are renamed as “Tribes”, “Clusters”, “Release Trains”, “Value Streams” or “Chapters” with high priests rewiring the organisation into some new perfect delivery flow. Traditional measures of success are replaced with “Explorer”, “DORA”, and “OKRs” though someone forgot to specify how to use or calculate the new measures, after all does it matter whether the frequent releases refers to “releases of value to the customer” or “releases of software to shelf”. Voices of dissent are crushed. “We have 150 feature flags in production” is hailed as a victory and those that point out its a huge risk to the business are nudged towards the door by the high priests and priestesses.

These organisations with a failureship culture think that change is about adopting new words and tools with the blind faith that the benefits promised by the consultants will follow. Failureship executives are comforted that they have spent so much money with the consultants that the consultants will use their extended networks to get them a bigger job where they can spend even more money on the consultant’s words and tools.

Words are imposed. Tools are imposed. Practices that support the existing ways of working are outlawed. To retain control of the words and make it easier to spot deviants, the vocubulary is reduced. No more rich and diverse contextually appropriate approaches to delivery of value, going forward everyone will only use the words of newSpeak. Although similar sounding, the meanings of words in NewSpeak will change. A story will have a strict definition and format, rather than the deliberately vague definition that allowed each group to find its own way. Epics will not longer be large stories, but will now become a project full of features. Chapters will no longer be parts of a story, but will now be a community of practice, one which is controlled by a manager who will be authorised to stamp out variation and deviant words that they do not understand (Jargon). At the end of the transformation, the organisation will be confused and executives and workers will be further apart with a new language that devides and confuses. Using new language to drive change leads to a lack of shared understanding, it creates non sense,

Sensemaking as an approach to change

An alternatives to cultural colonialism is to engage in Weick’s Sensemaking with an organisation. Engage in a deep and respectful mutual understanding of the current organisation and its practices, understand why the practices are valuable so that that value is captured in any new approach. Discuss the new ideas that the organisation would like to introduce. In order to engage in this process, the people introducing the new ideas need deep experience of using those ideas. They need to be able to make sense of the existing organisation and how the new ideas might adapt. They cannot do this if they have a shallow knowledge of the ideas from reading books, a few training courses and one or two narrow experiences. They also need to engage in the dialogue as equals with the people who are changing their way of working.

This is not an approach that “Experts” consultants can do alone. It requires people who understand the current reality. More important that a detailed knowledge of the new approach, empathy and experience of actually using the new approach, and ideally experience helping others adopt it. What we do not need are certification, expert consultants with no experience and forced transformations via tool implementation.

Wise men once summed it up, we need people who are “doing it and helping others do it.”

Making Sense in the organisation

Any transformation from a risk averse culture to a risk managed culture requires sense making between the different layers and silos in an organisation. Sense making is the process that creates transparency. The different layers and silos in an organisation need to come together and “make sense” to create shared understanding and enable them to provide transparency.

Sensemaking is not something that one group can impose on another, it requires genuine collaboration between all those involved.

Understanding Sensemaking

I found these videos to be useful to understand “Sensemaking” and “The Social Psychology of Organising“. I strongly recommend Karl Wieck’s essay on “The Mann Gulch Disaster” and the book “Managing the Unexpected: Sustained Performance in a Complex World”.

Many of the agile techniques are effective risk management tools that make problems and risks transparent and leave the solution to be determined based on the context. It is common for people to use an agile technique to reveal a problem or risk, and then ignore it when they find it… reveal a serious issue in a retrospective and then simply put an item in the improvement backlog, or turn off a failing test rather than fix the bug that it reveals. It is so common that agile practitioners have a term for it “Agile Kabuki”, an elaborate process where people make extreme gestures but fundamentally they have no impact other than to entertain and give the appearance of action.

In a risk averse failureship culture, the most common and most damaging example of Agile Kabuki is the “Go/No Go” meeting. The “Go/No Go” meeting comes with many different names but if it looks like a duck, and it quacks like a duck…. whether it is called “Design Review Board”, “Architecture Review Board”, “Change Advisory Board”, its a “Duck”

All “Go/No Go” meeting follow the same pattern:

• The stated purpose and justification of the meeting is to protect the production environment.
• Rather than do anything practical and useful, it simply introduces random delay in the development release process. These random delays add to the risk of investments and make it harder for the business investors to plan.
• The “Go/No Go” meetings occur at a regular arbitrary cadence and duration based on the convenience and availability of the decision makers, they are not held on on demand in order to minimise delay.
• Decision makers do not need to have specific knowledge relevant to the system or release being discussed.
• Decisions made in the “Go/No Go” are final, requiring escalation to overturn.

Although the “Go/No Go” has the above stated purpose, the reality is as follows:

• The primary purpose of the “Go/No Go” meeting is to establish the power and importance of the decision makers that attend the meeting. This is multiplied when the decision makers are so important that they can send a delegate to represent them who also has no specific knowledge about the system or the change.
• A “Go/No Go” meeting is “successful” if a decision maker can justify the existence of the meeting, and thus reinforce their importance, by imposing a constraint that forces a delay of the release of an investment.
• “Go/No Go” meetings are vitally important in a risk averse failureship culture as they move the responsibility for a production failure to the process and away from the team making the change. Any failure is blamed on the process rather than the teams responsible for the system. A “Go/No Go” allows a team to focus on passing the “Go/No Go” meeting rather than focusing on the risk of damaging the existing business model. Given the information asymmetry, the team know more than the “Go/No Go” decision makers, it is entirely inappropriate for a distant team with generic knowledge to decide on the safety or otherwise of a release.
• “Go/No Go” meetings are an opportunity for people to increase their importance at the expense of the wider organisations. They are a final opportunity for people to raise issues that should have been mentioned much earlier in the process of developing an investment. An issue raised at the start of a development process is much easier to accommodate and so attracts little attention, whereas the same issue raised just prior to deployment can generate much praise and status for the individual who “saved” the organisation from a disaster. This late reveal is often justified because the individual was far too important and busy to engage at an earlier point. I once worked on an agile flagship project that took eighteen months to deliver the first business value. Nine months into the project, during the User Acceptance Test and just prior to go live, a key user looked at the solution for the first time and declared it would not work and would cause a disaster. They detailed the changes that were needed. Everyone revered them for it.… A home for Dragon Slayers was established.
• “Go/No Go” meetings often occur as a mechanism to demonstrate to industry regulators that the organisation are taking the risk associated with production stability seriously. If an organisation needs an industry regulator to tell them that they need to take their production stability seriously, the share holders of the organisation should change the management, and the customers should change their service provider to one that does take it seriously.
• “Go/No Go” meetings are an appallingly bad approach to managing the risk of preventing a production incident, and even worse approach to minimizing the impact of a production incident.
• Resolving a production incident will often require releasing a fix into production, something that is delayed and made more risky by a “Go/No Go” process.

A Risk Management culture’s alternative to the “Go/No Go” Meeting

In an organisation with a risk managed culture, the focus is on preventing a production incident, and in the event of a production incident returning the organisation and its customers to safety as soon as possible.

Instead of a “Go/No Go” meeting, a risk managed culture would do the following:

• Clearly state the controls and tests to be performed before an application or change can be released to production. Normally these are not a solution but a test that must be passed.
• Automate the controls and tests. Normally building them into the platform. See Jez Humble’s inspiring talk about the US Government from almost a decade ago.
• Automate testing.
• Specify the tests before the code so that the code is built in a way that is testable, and the tests do not break when the code is changed. Moving the creation of tests before the code means that the responsibility creating tested code shifts from the tester to the developer. It means that when the developer changes code and it fails the test, the get immediate feedback and can fix the issue.
• Architect the system so that it consists of smaller independent parts that can be quickly and more easily tested (For example, a micro-services architecture).
• Minimise the number and duration of feature flags and other latent code patterns in production.
• Lock down the build chain and test environments to prevent anyone from tampering with the system and potentially causing a discrepancy between what is tested and what is deployed.
• Use containers to ensure that the test environment is identical to the production environment.
• Use Green/Blue deployments to enable rapid roll back to the previous system in the event of an issue.
• Remove technical debt from parts of a system that is being changed to reduce the possibility of production incident in the event that a fast fix is needed.
• Perform a scenario analysis to identify as many things as might go wrong, and ensure that there is an option to address them.
• Identify fast routes to safety and establish authority to execute them.
• Build automated systems to detect anticipated and unanticipated issues.
• If individuals are given the ability to block the route to production, they should be instantly available to address any blockage, dropping all other work until the business value is unblocked.
• If a “Go/No Go” meeting is required, run a short one regularly, once or twice a day with the option to extended its duration. Releases of business value should not wait for meetings at times convenient to the attendees.
• Prioritise the business value being delivered rather than the status of the “Go/No Go” attendees.

The “Go/No Go” is just one example of Risk Management Theatre or “Agile Kabuki” that occur in organisation with a risk averse failureship culture. Other examples include:

• Risk registers that have a “Probability” or “Chance of it happening” column.
• Risk registers that only contain one type of risk (For example “Delivery risk” but no mention of “business case risk”, or “damage to the existing model risk”.
• PMO groups that obsess about cost but do not measure outcomes (Metrics).
• Outcomes that are not measured even though significant investments are made to improve them.
• Executives that introduce governance that is ignored.
• Retrospectives that generate improvement backlog items that are never executed.
• Automated tests that are switched off when they fail.
• Organisations that ignore complaints about toxic behaviour or whistle blowers.
• People who are promoted for failing.
• Leaders who are allowed to ignore change that is being introduced.

Leaders should understand whether the risk management practices in their organisation are effective or simply risk management theatre.

One of the main strategies to avoid responsibility for delivery, and to avoid risk management of a process is to allow the system to be swamped by work, often shadow work that is not aligned to the goals of the organisation. Incompetent risk averse managers in a failureship culture engage in classic “child” behaviour of blaming stakeholders for forcing them to do more work than the system can cope with (“They made me do it, its not my fault”). In reality, it is exactly the fault of the person who allowed more work to be pushed onto the system than it can cope with in order to gain individual favour with a powerful stakeholder.

Unlimited “Work in Progress” in a Risk Averse Failureship Culture

Although the benefits of limiting “Work in Progress” to a sustainable level are well known, and well documented, less is said of the benefits to an individual in a risk averse failureship culture of IGNORING work in progress limits and deliberately allowing a system to be swamped with work.

Here are some of the benefits to an individual at the expense of the wider organisation of swamping a system with work in progress:

• The individual avoids accountability for delivery, or more accurately the failure to deliver on commitments, as they can always claim to be working on something of higher priority. When asked, each stakeholder will always claim that their items are higher priority than someone else.
• The individual can avoid doing things they do not want to do by claiming to be too busy.
• Being too busy avoids the need to share knowledge and skills leading to “key man dependencies“
• The individual can chose the work that benefits them the most, rather than focus on work that is most valuable to the organisation and aligned with the wider goals of the organisation.
• It makes it impossible to plan deliveries or track real progress of items. The focus is on starting things rather than completing things.
• The status of the individual is raised if others must wait for them in order to deliver a larger piece of work.
• Having too much work creates pressure to provide the individual with more resources and people, thus increasing their status which directly leads to promotions and pay rises.
• Having too much work allows individuals to hoard knowledge and withhold it from new team members creating the myth that it takes an extraordinary length of time to become effective with a system…. leading to more people and higher status.
• Being too busy means you get to say no to work you do not want to do.
• Being too busy means you are protected from your management who do not want to interfere with your work and be held accountable for your failure to deliver. Your risk averse management are afraid of being held accountable for you leaving the company.
• Being busy means autonomy and freedom.

Leaders need to address excessive work in progress if they are going to effectively risk manage in an organisation.

Addressing a swamp of excessive “Work in Progress” AT THE TEAM LEVEL

At the team level, addressing a swamp of work in progress is super easy and should take a MAXIMUM of one hour. It will take much longer than that if the team does not want to do it, often the excuse is they are too busy on important stuff that they are failing to deliver.

1. The team create a Kanban board with a queue in front of each activity.
2. The team put all the work they are currently doing on the Kanban board.
3. Where people are working on more than one item at a time, they pick one item and move the rest of the work items back to the queue in front of that item.
4. Prioritise the top few items in the Kanban board and either block the rest or move them off the kanban board and into the backlog.
5. As capacity becomes available, unblock items or pull high priority items off the backlog.

Blocked items and items in the backlog are “Not started”. Items being worked on in the system are “Work in Progress”. Completed items are “Done”. In a system that is swamped, many items are actually blocked which means they are “Not started”, however it is not possible to see which items are really “Work in Progress” and which are “Not started” (Blocked). As the items are in the system is not possible to prioritise the work easily as it is under the “control” of the system. All we do by reducing the “Work in Progress” is provide genuine transparency over whether the items in the system are actually “Work in Progress” or “Not started” (Blocked or in the backlog).

Addressing a swamp of excessive “Work in Progress” ABOVE the team level

Addressing the swamp of excessive “Work in Progress” above the team level is much more complex as it means aligning the work of all teams involved in delivering something of value to a customer. In large complex organisations, many teams may be required in order to deliver something of value to a customer. The teams will often be involved in delivering parts of investments in several different value streams. In a large complex organisation, it is easy for one or a few teams to end up with a huge amount of demand for the current period of time which leads to swamping a team. Pushy and manipulative stakeholders find it easy to push teams to take on more work than they can cope with “The manager of your sister team said it was not much work” or “I can easily spin up a team to do it for myself”. The result is a team that is swamped…. especially if the organisation has weak senior leadership who cave whenever stakeholders apply a bit of pressure.

Capacity planning is a process for limiting work in progress across an entire organisation so that no team is assigned more work than it has the capacity to finish in a period. The process is deliberately simple by design as we know we are fighting against the dispositionality of the failureship culture which wants to remain in the swamp.

1. List the candidate investments for the next quarter. Ensure that they are end to end investments that deliver value to a customer (internal or external).
2. Identify all teams required to deliver the investment. (Do not forget legal, training, business change, operations etc.). Place an “X” against each team.
3. Get each team to provide a SWAG estimate (Sweet Wild Asses Guess) in team weeks. SWAGs should take a few minutes to determine AT MOST.
4. Calculate the capacity of each team (Number of teams * Number of weeks in period * Capacity Adjustment * [100% – PercentageOfBusinessAsUsual])
5. Calculate demand on each team by summing all the SWAGs from Step 3 that are in scope
6. Compare demand with capacity (Over/Under).
7. Bring all stakeholders together to agree which items will be descoped from the next period.
8. Descope items until the demand is less than or equal to the capacity FOR ALL TEAMS!
9. Publish organisation wide backlog for the next period.
10. When stakeholders want to add items to the backlog, use the capacity plan to identify which items will not be delivered as a result.
11. At the end of the period, review the order in which items are delivered.

Capacity Plan as the “Work in Progress” Andon Cord

Applying “Work in Progress” limits at the organisation level is an exercise in creating organisational alignment. All of the stakeholders agree the best backlog for the organisation and commit to it.

Senior leaders can use the Capacity Plan as an Andon Cord. They can look at it to understand the state of the organisation, especially as it relates to whether it is swamped with “Work in progress”. From the capacity plan, leaders have transparency into the organisation’s product and delivery, and use it as a map to work out where they want to visit in GembaLand.

• Delivery of value – The investments should articulate the business value they will deliver by satisfying the needs of a customer segment. For example “Grow engagement by making it easier and quicker for repeat customers to migrate from one product to another.” Where the business value (engagement), customer segment (repeat customers) or customer need/job to be done (quicker and easier migration) are not clear, the leader can go to the Gemba and ask for clarification. If it is not clear about the value to the customer, the risk is that the investment may not deliver value.
• Parts that do not deliver value – Often the investment describes a part of a solution for a customer. For example “A teabag” instead of a “Cup of tea”. This means that the investment needs to be combined with other investments before it delivers something that satisfies the needs of a customer. (Above, “Upload customer data to database” is a tea bag as it is only part of the solution)
• Missing teams – It is difficult to spot when the owner of an investment has missed a team they need to deliver. The capacity plan does make it easier though as similar investments might need capacity from “The legal team to review contracts”, “The business change team to provide training”, “The architecture team to review designs”. When one set of investments need such teams but a similar set do not, it makes it easier for the leader to spot the missing teams. Another opportunity to visit GembaLand.
• Missing customers – In large organisations, many products and services are delivering value to internal customers. In such cases, if an internal customer is not included in the investment, then it means the product or service is being shipped to shelf and will not be generating value until the customer consumes it.
• Missing SWAG estimates – This normally means that the owner of the investment has not reached out to the owner of the team to explain what the investment is about and what they need from them. This helps leaders identify investment owners who need to improve their communication. The lack of a SWAG estimate may also indicate a huge amount of uncertainty on the part of the team as to how they are going to deliver what is required. (See Yellow team above)
• Not descope items – Often the owner of a number of investments is the same as the owner of the team. If the demand is greater than the capacity, then the investment owner needs to descope items so that the team can deliver in the period. If the investment and team owner does not descope items, there is a risk that they do not take limiting their work in progress seriously and is a strong candidate for taking on too much work and not delivering on their commitments. They are also a hot contender for running a shadow backlog. (See Blue team above)
• Increase capacity – If a team owner has more demand than capacity, they address the shortfall by increasing their capacity. If the demand is 20 team weeks of work, they increase the capacity to 20 or 21 team weeks. As with “not descoping items”, these team owners do not value limiting work in progress and are candidates for not delivering, and/or running a shadow backlog. (See Green team above)
• Not engage in prioritisation – Some investment owners (or stakeholders) do not engage in prioritisation. The consequence is that they will then try to force their investments on the teams. Senior leaders should use this behaviour to identify individuals who are putting their own personal success ahead of the success of the wider organisation. The root cause of this behaviour is sometimes due to an increased sense of importance, however it is more likely due to a performance management or reward system (bonuses) etc. that is not aligned with the goals of the organisation.
• Ignore capacity plan – Some investment owners and stakeholders ignore the capacity plan and demand that their work is done by the teams. The wrong-order-o-meter will identify these at the end of the period. It can also be used during the period, however it is better if senior leaders keep close contact with teams that have constrained capacity so that any interference can be addressed swiftly.
• Ignore order of work – Teams might ignore the order of work due to their own preference, or because they are pressured to do so by an important stakeholder. Once again the wrong-order-o-meter will help leaders spot this behaviour. However generally speaking teams tend to want to do the right thing, so if it is not a rogue stakeholder, the wrong-order-o-meter will show that teams are blocked from working on the higher priority work due to either internal or external constraints.
• Take on new work – If pressured, teams will take on new work during the period. Once again, the wrong-order-o-meter will help but it is better if senior leaders reduce the power distance index so that teams feel comfortable raising issues about stakeholders behaviour.

One of the keys to successfully limiting work in progress is to ensure that the period is a quarter or less. At the end of the quarter, the organisation can reflect on the number of investments (“Wholes”) that are delivered, and the number of parts delivered (“Each team’s contribution to an investment”). It is likely that the capacity adjustment will need to addressed, probably reduced. It will also be clear where teams are working on shadow backlogs as they will have completed work that is not within scope on the capacity plan.

This makes the capacity plan an ideal Andon cord for leaders to identify where they should go to the Gemba and possibly stop the line.

The process of knowledge work is pretty simple.

1. Decide what to build or fix.
2. Assign a person to build or fix it.
3. Provide the person with the support they need to build or fix it.
4. The person(s) builds it or fixes it.
5. Learn, reflect, and go back to step 1.

One of the key risks in knowledge work is the “Key man dependency” or “bus count”. The bus count is the number of people in the team at a bus stop that a bus would need to take out in order for the team to be unable to support the system. A “key man dependency” is where one or a very small number of individuals are vital for the development and support of a system, and if those people are not available, the system is at huge risk of failure, and is unable to be modified with the necessary time frame.

Two of the most likely causes of a “Key man dependency” are:

• An outside context event.
• Bad risk management.

Outside context events

In 2008, The financial crisis forced banks around the world to rapidly eject toxic derivatives businesses into “bad banks”, moth ball associated systems and reduce the development teams that supported them to minimal or zero membership. In 2010, the financial markets started to recover and the banks sought to bring the systems back on-line. The people that knew the systems were all key man dependencies. The situation was caused by events outside the control of the people managing the system, an outside context event.

Similarly, several people may leave an organisation at the same time leaving a key man dependency in their wake. Being unaware that people were unhappy and likely to leave is often a symptom of a failureship with a large power distance index. In a risk managed leadership culture, the leader should be aware of the needs and aspirations of their team, and the team should see the leader as a resource to help them find a new role either inside or outside of the organisation. This gives the leader time to resolve the potential key man dependency.

Bad risk management

In failureship cultures it is common to find systems supported by teams that contain one or more key man dependencies. Individuals hoard knowledge and experience with a system to gain personal advantage at the expense of the organisation. The advantages to the individual include, but are not limited to:

• Job security – Being known as a “key man dependency” means that a person is unlikely to be let go by an organisation.
• Money – Becoming a “key man dependency” means that a person is more valuable to an organisation and the organisation are prepared to pay a higher salary and bonus to the person.
• Status – Being known as the “go to” person to fix problems or get things done can lead to elevated status in the organisation, with senior stakeholders demanding trusted junior staff being present in important meetings simply because they are the only people “who know where the bodies are buried”.
• Promotion – Increased status leads to increased chance of promotion and ultimately more power in the organisation.
• Autonomy – Individuals who are key man dependencies are often given more autonomy as the organisation does not want to frustrate them by micromanaging them.

Without proper risk management, the dispositionality of a failureship organisation is for every individual in the organisation to become a “key man dependency”. Each individual will seek to become the only expert on a part of system, to be the “owner” of some critical component… To be the “go to” person to fix, build or enhance a particular item. An organisation with a risk averse failureship culture will focus entirely on the pursuit of value with no consideration of risk. Everyone in a failureship will be over utilized and have more work than they can do. Every task will be urgent with no time to address risk management through knowledge transfer. If Bob is the expert on component “X”, then all work on component “X” will be done by Bob, even if that means waiting for Bob to come back from holiday to fix it, build it or enhance it. Even better if Bob needs to be interrupted on holiday, thus reinforcing Bob’s status and value.

Without proper risk management, “key man dependencies” will naturally occur in an organisation with a failureship culture. Even worse, failureship cultures intentionally or unintentionally ENCOURAGE AND REWARD individuals who can establish themselves as a “key man dependency”.

Addressing “Key man dependencies” in a Risk Averse Failureship Culture

The dominant strategies for addressing “Key man dependencies” in a risk averse failureship culture are to wait for them to occur and then adopt one or more of the following strategies aimed at making sure that the individual who is a “key man dependency” does not leave the organisation:

• A senior leader explains to the person how important that they are and gives them special attention. (Increase JOB SECURITY and STATUS of the individual)
• A retention bonus is put in place to make sure the individual does not leave. (Increase MONEY). This bonus can then used by the individual to increase their package at a company they would move to thus increasing their disposition to leave the organisation as a move would permanently lock in the value of their unshared knowledge.
• A bonus is paid on the effective transfer of knowledge to other people in the organisation (Increase MONEY). The organisation has now introduced a bonus scheme to encourage people to become “key man dependencies”. Join a team, learn all the knowledge, behave badly so that the other key experts leave, receive bonus.
• The “key man dependency” is promoted. The individual is given more power and influence whilst doing the same job badly. The failureship has sent the strongest possible signal that the path to success is bad behaviour and incompetence.
• The individual is given more freedom and autonomy so that they can cause damage in another part of the organisation.

All of the intervention strategies to address “key man dependencies” in a risk averse failureship culture increase the risk of a key man dependency.

As an amusing aside, the WORST intervention I ever encountered was two decades ago. The original team who built a trading system had left the organisation leaving only two developers who understood how the whole system worked. The manager in charge of the system was one of those two developers and was post technical. Their manager pointed out that there was effectively only one developer left in the team who could make significant changes. The manager asked the developer out to lunch at an exclusive (and expensive) restaurant to explain how important the developer was to the organisation. At the end of the lunch, the manager also explained that there was no money and the developer would have to pay for their own lunch.

I leave you to your own conclusions as to whether risk averse strategies for managing “Key man dependency” will address the problem or encourage others to emerge.

Addressing “Key man dependencies” in a Risk Managed Leadership Culture

There are two concerns, first mitigating the “key man dependency” and second ensuring that “key man dependencies” do not occur in the future.

“Key man dependencies” normally arise because the organisation is risk averse, ignoring risk, and does not understand or value the mitigation of risk. The organisation seeks to push it on to another person or organisation regardless of whether that other organisation is competent to manage the risk. The most obvious example is organisations who engage consultancies with a track record of failure in a capability so that they can blame them when things go wrong.

Establish the priority of Risk

The first mitigation step is to establish the importance of key man dependency risk. The general priority of work for a team should be:

1. Support. Ensure that the system operates as expected, and fix it when it doesn’t.
2. Risk. Ensure that the system continues to operate as expected and can cope with any outage event.
3. New investments.

Support work and New investments result in visible manifestations that stakeholders and manager can see. Risk is invisible. Stand in a street in front of two hotels. One is insured and the other isn’t. Can you tell the difference? Which one would you stay in? The only way to tell the difference is actively look for the attitude towards risk management (Does the bowl of M&Ms in the dressing room have any blue ones in it?).

Managing risk needs to be a primary concern of the organisation, not just support or new investments.

Mitigating a “Key man dependency”

The first thing that needs to be assessed is whether the “Key man dependency” was created by an “Outside context event” or “Bad risk management”.

If a team was very small and grew very fast due to unprecedented demand that the organisation could not control, the cause may be considered an “outside context demand”. If the team is large and/or the situation has been allowed to occur slowly over time, then the cause is likely to be “Bad risk management”.

If the “Key man dependency” is created by an “outside context event”, then the team need to be supported to resolve the situation. It normally means that forces outside the control of the team have forced the situation on them and the team needs be empowered and supported to push back on those forces. Another indicator of “Bad risk management” is an organisation that does not control its “Work in Progress” and takes on more work than it has capacity to deliver, often in “shadow backlogs” outside of the organisation’s normal prioritisation process.

If the “Key man dependency” is created by “Bad risk management”, then a management intervention of some kind may be necessary. It indicates that one or more individuals is not experienced enough in risk management for the responsibilities they have been given.

Simply put, the difference is whether the organisation should be allowed to manage the mitigation on its own with support, or whether the mitigation should be overseen by an external responsible party.

Specific tasks, skills and knowledge

“Key man dependencies” normally refer to the importance of an individual to the organisation. They do not refer to the specific tasks, skills and responsibilities that the person needs to perform. The first step to addressing a “key man dependency” is to identify the specific tasks, skills and knowledge that the person has that no one else in the organisation has. Often perception is different from reality and although the individual is the only person known to stakeholders and senior leaders, there may be many others in the team that are not known.

The skills matrix is a powerful tool for seeing this detail.

As well as seeing the current situation, it can be used to see the impact of people leaving or being unavailable.

It is important to identify all of the skills and tasks done in the team, especially the individuals who are identified as a “Key man dependency”. As well as working on components and tasks on the system, they may have “softer” skills and activities that require someone else to acquire as well. Some of these are skill based, some experience based and some require authorisation. Most will require practice to be competent. For example:

• Engage with stakeholders. (Skill & Practice)
• Represent organisation at steering committees and forums. (Experience, Practice & Preparation)
• Prioritize backlog. (Permission)
• Present at events. (Skill, Practice & Preparation)
• Submit budget. (Know process and people, and Experience)
• Escalate issue with Senior Management. (Experience)

There are often people in the team who can do the technical things, the key man dependency occurs because the individual is seen as the interface to the team. When they are away and another member of the team presents status at a steering committee, they do a bad job because they do not know what is expected. The stakeholders and senior manager lose confidence in the teams ability and assign competence to the missing “key man dependency”. They blame the “stand in” for not being able to do the task rather than blame the “key man dependency” for not training and preparing a “stand in”.

Once the detail of the missing skills have been identified, the team can address the skills liquidity (here and here). If the issue was an “outside context problem”, the team can be left to address the mitigation of the key man dependency. If the issue was “Bad risk management”, then an external agent should mentor and monitor the organisation as the risk is mitigated. At one organisation, management started by setting the quarter end target for someone to train two other people in support. They ignored the target and were subsequently removed from the support rota. They continued to fix issues. Eventually their access to the systems was revoked and they could not fix problems directly, they were only able to answer questions by those on support.

Motivating the risk management of “Key man dependencies”

In the mid 1990s I was shocked to hear that Bill Gates had said “If only one person knows about one part of an application, I sack them because I want to have control on when that issue needs to be addressed”. (Based on my very poor memory and I cannot find a reference). The message was clear, if you become a key man dependency, you will be sacked and other people will be forced to learn about what you do immediately.

Thirty years later I understand the wisdom of the statement. Bill Gates understood the dispositionality of large organisations towards “Key man dependencies” and instigated a policy that whilst appearing to to be incredibly risky actually ensured that “Key man dependencies” did not arise in the first place.

Inspirational as Bill Gate’s approach might be, a more measured approach might be to give the “Key man dependency” three months to mitigate the risk.

A key point to understand about “Key man dependencies” is that their value to the organisation is often related to the specific context of the organisation that they work in. In other words, they are probably paid above their market worth, more than other organisation would pay them for their general levels of skill and experience. Should they move to another organisation at the elevated level, their lack of skills and experience will probably be discovered during their probation period, especially risk management skills if they move to an organisation with a “risk managed” leadership culture.

External Support

The main value of the external support is to help the organisation establish the priority of risk management. They should help the organisation push back on new requests so that the “Key man dependency” risk can be mitigated.

Given the desire to look good to stakeholders at the expense of the wider organisation, the external monitor should ensure that the “Key man dependency” risk is removed before it is removed from the organisation’s risk register. Given the desire to remove the “unnecessary” constraint of the external support, individuals may be “encouraged” to claim to have greater proficiency than they actually have. In this case, the external monitor may require someone to prove their competence in a skill or at a task in the system (Paying down technical debt on their own is a good test).

It is generally good practice for organisations to require ALL employees to have a two week holiday every year. During the holiday the employee should have no contact with colleagues at the organisation or log into any systems. Regulators enforce this on employees of Financial services firms following the Sumitomo Copper Trading scandal where a rogue trader had not had a holiday for a decade and their market manipulation was only discovered when they were taken ill.

Failureship Counter Measures

As soon as a team is asked to create or to change the way they work to pay down “Key man dependency” risk, there will be a backlash from the organisation and some of their powerful stakeholders complaining that value is being delayed. Be ready for uninformed, fearful and powerful individuals intervening to protect their favorite “key man dependency” from being forced to share.

The Andon Cord

There is no Andon Cord. Senior Leaders instead should manage the negative space.

Instead of “Familiar faces in familiar spaces”, they should expect those familiar faces to step back and allow other faces to become familiar. Rather than “Why isn’t Bob at this meeting”, it should be “Why is it only Bob that is present at this meeting? Where are the other team members?”. Look for the negative space rather than always have the same positive space. You may discover that the story is not consistent.

Encourage teams to publish their skills matrix and support them by pushing back on stakeholders if they want to address knowledge transfer concerns. Once again, look for the negative space. Which teams have not published a skills matrix?

Quality only emerges if people care. That was one of the conclusions of Robert M. Persig’s “Zen and the Art of Motor Cycle Maintainance”. In organisations, there are two types of people. Those that care more about the organisation more than their career, and those that care more about their career than the organisation. It is clear that those who care more about their career rise faster in organisations. Between the owners at the top of the organisation and the workers at the Gemba, there is a layer of people commonly referred to as the “frozen middle”. Communication between the people at the top and the people at the gemba is controlled by the frozen middle. Information that is not to the advantage of the frozen middle tends to travel slowly if at all up the organisation, AND even slower down the organisation.

Organisations with a leadership culture establish mechanisms to allow effective communication from the bottom to the top, and across the organisation. The Andon cord in Lean Manufacturing is a mechanism for any individual on the Gemba to signal that the system is failing and needs to be stopped until it is moved back to safety.

Years ago at a wedding, a primary school teacher explained a problem they had with some children. The children were a nightmare in the class room but when the teacher spoke to the parent, the parents protested that their child was an angel at home and refused to believe the teacher. The only way to resolve the inconsistency was for the teacher to sneak the parents into school so that they could secretly observe the child. In a risk averse (parent-child) culture, the child might be perfectly behaved to the parent (Manager) but behave very badly when they are not observed by them. A common behaviour in organisations is for people to use the resources of the organisation to benefit their career at the expense of the organisation. A manager with one or more teams might divert resources to work on a “shadow backlog” in order to gain favour with a powerful stakeholder who should not have access to those resources. The manager controlling the resources in effect can benefit from building a stronger relationship with a powerful stakeholder (behave badly) by the misallocation of resources because the senior leadership has no visibility of the gemba. If a person on the gemba attempted to alert senior leadership of this activity, they are the only people who can see it after all, their career within the organisation would be at risk as they would not only upset their direct management, but also the manager’s powerful stakeholder. Obviously at some point the investment will be revealed to the organisation, however the goal is to hide the investment long enough so that the “sunk cost” is big enough that the next level up in the organisation cannot stop the investment without them appearing incompetent, with an organisation that is “out of control”.

Leaders need to create an “Andon Cord” so that workers at the Gemba can signal that the organisation has moved from safety and needs to stop so that it can move back to safety.

In a failureship, the most risky career move is to ignore the power distance index and either challenge your direct manager, or go above the head of your manager. Reducing the power distance index is only something that is possible from above, it is career limiting to attempt to reduce the power distance index from below. In other words, senior leaders can “Go to the Gemba” but those on the Gemba cannot alert senior leaders that they should “Go to the Gemba”.

Those people working at the Gemba are normally the closest to the customers, and as a result often have the best understanding of the customer. Once again, it is career limiting for someone at the Gemba to by-pass their direct manager if they disagree with them. The manager may want to build something for ideological, egotistical, or political reasons and ignore feedback from customers. For example, a manager in an energy company might build a coal fired power station even though the customers wants green energy, however the manager considers green energy to be “woke” due to their political beliefs.

Those working on the Gemba CANNOT REACH UP SAFELY in a risk averse failureship culture. Leadership need to reach down by collapsing the power distance index and by creating a number of “Andon Cords” so that those working at the Gemba can invite the leadership to go to the Gemba.

Next, what do “Andon Cords” look like in knowledge work?

Image from Swamp Thing 31 by Alan Moore, Rick Weitch and John Totleben.

The best metaphor for a new leader in an organisation with a failureship culture is Doctor Who (New Leader) and his relationship with the Tardis (The organisation). Doctor Who frantically rushes around the Tardis altering controls and pulling levers, none of which has any impact and the Tardis takes Doctor Who wherever it wants him to be. Unless a new leader creates transparency to make sense of the risk averse organisation, it will simply take the leader where it wants them to be and give them the comforting illusion that they are in control. This is particularly risky for super smart new leaders who have only worked in successful risk managed leadership cultures as they will not be familiar with the mind sets and behaviour that subtly create a gilded cage of ignorance for them to operate in.

An organisation with a “Risk Averse” failureship culture will resist a move to a transparent “Risk Managed” leadership culture. There are many strategies that it will deploy to thwart the new leader and move them from an adult ego state to a parent (or child) ego state. Transformation leaders need to be aware of these strategies and be ready to address them when they detect them.

Some of these strategies include:

1. Increase the power distance index by strengthening the chain of command
2. Compliance or “Work to rule”
3. Non compliance / Too busy
4. Misunderstand
5. Denial of service
6. Bike shedding
7. The Cucumber
8. Focus on the wrong thing (cost not return) / Details about what instead of why
9. Delivery of things, not value
10. Trusted advisors

None of these strategies are new. They are well understood and documented. Understanding that collapsing the power distance index as a strategy to address all of these is less well known, probably because management consultancies do not want new leaders to know their Achilles heal.

These are not distinct strategies. There are normally several in operation at any moment in time. The middle management layers are not trying to thwart the leader out of malice or bad intent. Quite the opposite, they are trying to protect (Parent ego state) the new leader (Child ego state) and do so out of genuine love and good intention. Given how well coordinated these actions are, it can appear to a new leader introducing change that there is a conspiracy where none actually exists…. they are simply encountering a risk averse failureship culture.

Increase the power distance index by strengthening the chain of command

In order to reduce confusion for a new leader, an organisation with a failureship culture will help them out by ensure they have a single, easily understood reality to operate with. They will strengthen the chain of command to ensure that “confusing” information is filtered out.

A leader in an organisation with a risk managed leadership culture understands that risk arises out of the confusion and multiple realities that exist. They seek to “make sense” (as described by Karl Weick in Managing the Unexpected and Sensemaking in Organisations) of the organisation by engaging with the multiple realities and the people who have the most detailed, accurate and unfiltered understanding of those realities…. the people at the Gemba.

The new leader needs to counter the (Parent) caring inclination of middle management to treat them as a child and empower and encourage the entire organisation to present risks and alternate realities.

For example, a project may claim success. The project may announce that a new system is in production. This is true. What is not stated in the filtered and carefully created reality is that no customers are using the system.

The new leader will need to create a sense making framework to “make sense” of the organisation so that they understand it well enough to act and see the consequences of those actions.

Alternatively, they can live a very pleasant life in the current culture, safe in the knowledge that no information will make it into the comfortable gilded cage that challenges their SAFe version of reality. Plausible deniability is the key.

Compliance or “Work to rule”

The organisation does exactly as the new leader asks. They do things EXACTLY as the new leader asks. For example, if the new leader asks for a coffee with a spoon of sugar. If the organisation only has table spoons, they will provide a table spoon of sugar in the coffee as that “is the way things are done around here”. They will not attempt to understand what the new leader is trying to achieve but rather simply interpret the request according to their context.

If a new leader asks… “How many people work in my organisation?”. They will be told the number of permanent employees. If they ask for the number of contractors, they will be told the number of contractors but not consultants. If they ask for consultants, they will be told the number of people working for consultancy companies but not software providers. If the asks for the number of people on their budget they will not be told about the people paid for by other departments, or are seconded, or are part of a maintenance contract.

The failureship organisation will answer their question accurately as they interpret it but not necessarily so that the new leader can make sense or act upon the information.

Non compliance / Too busy

EVERYONE in a failureship culture is busy. Everyone has more work than they can do, work that has been agreed and committed to with their manager. Everyone in a failureship culture works long hours and weekends. They justify their value to the organisation by being busy.

When a new leader asks for something, the organisation either fails to deliver it, delivers it badly (in production but no customers) or does not do it at all.

When the new leader asks why it hasn’t been delivered, the organisation responds that it is too busy or that it has had to deliver something else, normally something else the new leader requested.

Being too busy, having more work than they can deliver gives teams and individuals in the organisation the ability to choose what they work on, and as a result ignore doing things they do not want to do.

The new leader will eventually need to get the organisation to commit to things they can deliver. This is only possible if individuals and teams feel comfortable pushing back to their managers when new items will mean they are over capacity. This in turn is only possible if the power distance index is reduced and individuals and teams take back responsibility for their own capacity ( Child to Adult ) and the manager gives up responsibility for managing the capacity of other people ( Parent to Adult ). When all managers know that they should not assign work items to members of the team, instead they will move individuals in and out teams rather than move the work to the teams and break work in progress limits. It is an infinite game of “whack a mole” until they move from parent ego state to adult ego state.

Having too much work and responsibility means that key individuals ( it is never the whole team ) can act as dragon slayers rushing from crisis to crisis. Dragon slayers are so busy that they never have time for effective knowledge transfer so that others can put out fires or slay dragons, or address the root causes of the crises.

Too busy is addressed by limiting the work in progress for each team and individual in the organisation. That is only possible if the new leader clearly and transparently prioritizes work. The new leader will need to ensure no two work items have the same priority.

Non compliance / Mutiny

They can’t sack us all.

Individuals in the failureship might refuse to perform a task (child ego state) if a number of them do not perform it. If only one does not do something, the new leader can focus on them. If a number of them do not perform the requested task, they can feel safe that the new leader cannot address them all individually. If a number of people do not do as asked it becomes a huge sink of time and effort for a new leader, time and effort they may prefer to focus elsewhere on more positive and rewarding activities. The failureship organisation is acting passive aggressive (child ego state)

At some point, the organisation accepts the new responsibility ( child to adult ) or the new leader gives up ( adult to parent ) because they decide it is easier to do the thing themselves or cave in to the demands of the organisation position “That’s not how we do things around here”.

Misunderstand

Guardians of the Galaxy II has a wonderful scene where Yondu and Rocket ask Baby Groot to fetch the control helm for the deadly arrow weapon. Being ever so keen to please, Baby Groot fetches a number of wrong items. The deep feeling of frustration that Yondu feels is the same as any new leader asking a failureship to do something new. Eventually the new leader gives up and adopts the existing practice.

Distributed Denial of service

One of the most common ways that an organisation ensure that a new leader does not change things is to make sure they are too busy to introduce change.

An organisation with a failureship culture ensures that the new leader is buried in important meetings with leaders, peers, customers, stakeholders. The new leader will have a diary that is triple and quadruple booked for every slice of the day so that the new leader does not have time or the cognitive or emotional capacity to make sense of the organisation or plan how to make sense of it. If the new leader does not make sense of the organisation for themselves, they will have to accept the carefully curated reality that they are presented with. A new leader with three or four meetings to choose from will find it easy to pick one of them but harder to realize that they should not be in any of them, and they should be using the time to think, act or find the people they need to make sense of the organisation and create their own reality

An organisation with a failureship culture (Parent-Child) will find it particularly easy to bury a new leader in unnecessary detail as the child asks the parent to make decisions that they should make themselves, forcing the new leader to learn unnecessary detail. Unaccustomed to the new organisation, a leader from a risk managed ( adult-adult ) culture will assume that the questions they are being asked are important, especially when it is explained to them why the individual is not allowed to make the decision in the failureship culture.

Crisis Mode

Nothing distracts and engages a new leader than a crisis. In an attempt to show that they are in control and a safe pair of hands at the helm, they relish the chance to demonstrate that control and they become sucked into the detail of one or more crises.

Crises present the chance for new leaders to show have the right stuff. Crises are easy to generate in an organisation with a failureship culture because it has an entire army of dragon slayers generating dragons both large and small.

Bike shedding

Bike shedding is a great distraction technique. Focus on the unimportant stuff so that there is not enough time to discuss the important stuff. This allows the organisation to work on the important stuff without the leader needing to be involved.

It would appear on initial inspection that bike shedding would be easy to address. They simply change the agenda order for a meeting. However the way the agenda items are sold “Lost customers” and “Project Update” hides the fact the customers are not important but the project update means an extra $50million are needed. The only way the new leader can interpret the agenda is if they make sense of their own reality.

The Cucumber

Jabe Bloom’s Lean Agile Scotland talk on Cucumbers explains that cucumbers become pickled but the vinegar does not become cucumbered.

In order to see the problems in an organisation, a new leader needs to retain an outsiders view until the organisation has changed to adopt their view. This is emotionally very difficult and most leaders will adopt aspects of the failureship culture in the organisation to gain empathy and report with the organisation.

Those new leaders that do not adopt the failureship culture will find themselves surrounded by individuals (pickled) who present them with the reality that they want to see. They will carefully and discreetly filter out people that the new leader should not see.

This is why a leader with a team is likely to be more successful that a lone individual. It is harder to pickle a group of people than it is an individual.

Focus on the wrong thing (cost not return) / Details about what instead of why

All organisations have their own definition of success. Organisations with a failureship culture tend to focus on things that are built or created rather than value those things create. Where value delivered by investments is discussed it is in monetary terms like profit, revenue or cost. The problem with profit, revenue and cost is that they are very difficult to attribute directly to a specific investment and they often do not have an impact for months or years after the investment. This means that success is subjective and determined as much by the relationship between the person delivering the investment and the person holding them to account.

Investments tend to be large and strategic which are difficult to cancel or redirect with a value statement based on cost or possibility risk reduction.

Rather than discuss whether value has been delivered, the discussion will focus on the costs, status and accounting for the investment. Any attempt to address the costs and accounting will result in the new leader being sucked in to the labyrinthine processes designed to prevent any common sense understanding.

In other words, organisation with failureship cultures will drown the new leader in information about the delivery of things, with no information about the value delivered.

Trusted Advisors

Most large organisations engage with many different consultancies and trusted advisors. They can help a new leader gather insights and information about the organisation, present it in a easily consumable format (with very pretty powerpoint slides) so that the new leader can make sense of the organisation.

Trusted advisors are only valuable if they have the competence to make sense of the organisation, and they have no vested interests that distort there view of reality. At one organisation I worked, a large famous consultancy spend several months assessing the organisations ability with agile and presented their findings to the board. They recommended to the board members that one team was selected and then that one team should try Scrum. At the time of the recommendation, the organisation had several THOUSAND teams operating using Scrum. Navigating an organisation for months and failing to find a single team using Scrum demonstrated phenominal skill.

The consultancies normally have a vested interest in maintaining the status quo. They will likely recommend a solution but they are unlikely to want to kill the golden goose by solving the problem so that they are no longer needed.

A new leader looking to shift an organisation from a risk averse failureship culture to a risk managed leadership culture will need to address the culture as well as the processes and the people.

Part 1 – The failureship dynamic

Part 2 – Leadership strategies to address failureship