Category Archives: Uncategorized

Leadership strategies to address Failureship

When leading a failureship on the journey from a risk averse to a risk managed culture, there are two entangled parts of the culture that need to be addressed… “Uncertainty avoidance” and “Power distance index”. How these are addressed will determine whether the leader achieves the transparency they need in order to identify and address the real issues in the organisation.

Any leader new to an organisation wants to find the “dead bodies” as soon as possible so that they can be rightly identified as the consequence of the previous regime. They know that after a certain period of time, they will be held accountable for them. I was complaining to the business manager of the trading desk about a system I managed. The business manager stopped me and said “After three months, there is no legacy portfolio”. An organisation that has been taught NOT to officially show the leader the real problems to ensure plausible deniability for the leader (possibly by communicating only solutions) will thwart such attempts by doing exactly as they are asked to do. They adopt either the child ego state “You asked for coloured widgets, not the black and white ones”, or the parent ego state “You are asking the wrong problem, ask for the coloured widgets”. For the best interest of plausible deniability, often out of loyalty to the previous (current) regime, the organisation will make sure that the leader does not receive the information they need. The game of cat and mouse between new leaders trying to unearth actionable information and an organisation’s attempts to thwart that discovery is the subject of many classic dramas and comedies including:

  • Brubaker with Robert Redford – The ultimate “Go to the Gemba” as the new warden goes into the prison as an inmate to understand what really goes on. The warden literally digs up the dead bodies in this classic movie.
  • Yes Minister / Prime Minister – A British politician attempts to modernize the British Civil Service but runs afoul of Sir Humphrey and the establishment.
  • Erin Brochovich – A legal assistant uncovers a conspiracy because no one initially suspects what she is digging into.
  • Please add any others to the comment below.

The point being made is that this is well established problem in organisations. Leaders are thwarted because they rely on those working with them directly who are trying to protect them from the truth (Child ego state). Those working directly for the leaders ensure that the leader never encounters someone who can tell them an alternative reality to the one they are presented with. “Going to the Gemba” is not enough. The leader has to make those at the Gemba feel safe coming directly to them. They need to protect them from their management who might feel undermined that their version of reality has been undermined. To illustrate why “Going to the Gemba” is not enough, a leader in New York might decide to visit a team in London. By the time they get to London, the management of the team in London have carefully rehearsed what everyone will say to the new leader and ensured that troublesome elements are “out of the office” for the day. A comedian once joked that “The king thinks the world smells of paint because one hundred feet ahead of him a decorator is slapping paint on the wall”, in other words the King is saved from the reality of the places that he visits so that he does not have to acknowledge that reality.

“Creating a more real reality”

There are a number of things that a new leader needs to do to collapse the power distance index and address uncertainty avoidance.

  1. Acknowledge that there is no single reality. A single reality only exists when that reality has been carefully curated by the organisation to hide the “dead bodies” and give you plausible deniability. If you are presented with a single coherent version of reality, you are not looking at reality. You need to start digging and protecting those who provide the truth.
  2. Meet people at the Gemba in unplanned spontaneous ways. Get past orchestrated trips to the Gemba that smell of paint, and avoid “Meet the troops sessions” and “Leadership breakfasts” with carefully screened attendees. Try the following:
    • Chat to people in the coffee area next to your office ( Mark Gillett at Skype )
    • Interview EVERYONE one on one before they join ( Al-Noor Ramji at DrKW )
    • Surgery hour every evening in the bar opposite the office (JP Rangaswami at DrKW )
    • Randomly choose a desk and chat to the people you meet ( BoA Group CIO ).
  3. Create a structure that provides transparency. Most risk averse organisations will evolve to a state where the “Parent” is unable to construct an actionable reality from the information provided by the “Child” organisation. As a result, a new leader who wants transparency will need to introduce a system to provide that transparency. Now it is possible that the responsibilities are so inter-twined that the leader will need to re-organize. The re-organization is not necessarily to improve delivery but rather to provide transparency. Once the leader has transparency, they may need to re-organize again to improve delivery.
  4. Focus on the delivery of value. Focus on how investments satisfy needs for customers and the resulting value for the organisation. Even though some investments may be internally focused on cost reduction and risk reduction, there should be a balance which includes increasing return by focusing on customers.
  5. Go to the Gemba. Once the new leader has transparency into the organization, they can go to the Gemba. Not formal pre-arranged visits that are chaperoned by a minder to ensure no information leaks, but rather impromptu visits. Walking over to the team or picking up the phone (teams/zoom) and speaking directly to the people involved, potentially with no middle management present to act as “translator”. I like Jabe Bloom’s suggestion that executive dashboards should not support decisions but rather act as “An invitation to the Gemba”.
  6. Bring a team. Successful transformation leaders bring a team of people who understand how they want things done. They act as ambassadors pointing out what is expected, especially when agents of the “risk averse” culture state that something cannot be done, or is “impossible”. “Impossible” means “Impossible for me” or “I can’t do that so I’ll oppose it”. Al-Noor Ramji took a team from Swiss Bank to DrKW, and then from DrKW to Qwest. It was not his “leadership team” but rather a “team of leaders” at all levels of the organisation.

New leaders should be aware that the failureship culture will fight back. Next we will look at the Failureship culture’s counter measures.


The Failureship Dynamic

One of the most profound discoveries during the study and practice of failureship has been that Eric Berne’s transaction analysis is ideally suited to understand the failureship dynamic. Whereas previously I thought the “leadership” of an organisation determined whether a leadership (risk managed) or failureship (risk averse) culture emerged, our study of failureship has revealed that it is the interaction between the leader and the organisation that determines the culture. Understanding that transaction analysis describes these interactions gives us a clue as to how to address a failureship culture. It also helps us understand why leaders who lead a successful leadership culture in one organisation, often fail to succeed with a failureship culture in another organisation.

Photo by Allef Vinicius on Unsplash

In transaction analysis, there are three ego states, “adult”, “parent” and “child”. Transaction analysis helps us understand two stable sets of dynamics. (Note that this is similar to David Marquet’s leader-leader and leader-follower model in “Turn the ship around”)

Adult – Adult dynamic

The leadership dynamic is “adult – adult” where the leader and the organisation both manage the risks associated with their responsibilities and ensure that the other party has the information needed to manage the risks that they are responsible for. In an “adult-adult” relationship, the responsibilities are dynamic, often transferring between the parties or held by both in the best interests of the organisation. Whereas ownership or control of people, processes and resources are MECE (Mutually Exclusive Covers Everything), ownership of risk is NOT mutually exclusive and many parties can be held accountable for the same risk.

Parent – Child dynamic

The failureship dynamic is “parent – child” where each individual seeks to minimise the risk that they are responsible for, whilst at the same time maximise mutually exclusive (MECE) ownership and control of individuals, processes and resources. The parent takes the responsibility of the child, even when they should not, especially when the child is a teenager. The child will seek to pass the responsibility for managing the risk to the parent, even when it is inappropriate.

A parent will withhold information from a child, thinking it is in their best interest not to know about certain dangers. A child, especially a teenager, will seek to hide information from the parent in order to hide failure or gain greater freedoms. A child will hide information to avoid embarrassment. The parent will ignore that the child is hiding information to avoid having to act and to ensure that they have plausible deniability about knowing what is going on. In fact, it is possible for the child to provide information informally or unofficially to the parent so that the parent can protect themselves from the consequences AND refuse to provide the same information officially so that the child protects the parent from having to act to fulfill their responsibilities.

Rather than a controlling relationship, the parent-child dynamic is a collaboration by both parties to ensure that they do not have to fulfill their responsibilities to the wider organisation.

Stable and Unstable Relationships

Both parent-child and adult-adult relationships are stable low energy states that are easy to maintain in the long term. Adult-child and Adult-parent are unstable and require a great deal of energy to maintain by the person in the adult role. The lowest energy route to stability from Adult-child or Adult-parent is for the adult to adopt the parent or child ego state respectively.

The child-child dynamic can persist but results in failure that is visible from outside the relationship. The parent-parent dynamic results in conflict as each attempts to gain supremacy, a conflict that once again attracts the attention from outside the relationship.

A stable adult-adult dynamic (risk managed culture) can be disrupted if one of the participants goes into the child or parent ego state, thus forcing an unprepared adult into the counter role.

A stable parent-child dynamic (risk averse culture) can be disrupted if one of the participants moves into the adult ego state and remains there until the other party moves into the adult state. This requires a huge amount of energy on the part of the adult, and requires active removal of the scaffolds that the parent-child (risk-averse) culture has erected. The quickest and easiest way for the adult to remove the scaffolds is to collapse the power distance index, something that is easy for someone at the top of the power hierarchy but career threatening for someone at the bottom of the power hierarchy. One of the practices of collapsing the power distance hierarchy is “Go to the gemba” which is a core practice in many management philosophies.

Another practice is to directly address toxic belief systems within the organisation that act as scaffold to the parent-child (risk averse culture) dynamic. For example, one such toxic belief promoted by consultancies is “Never go to management with a problem, always go with a solution”. There are two particularly nasty elements to this belief. The first is that you should delay reporting a problem to management until you have a solution, one that is filtered by your capabilities and preference. The delay can reduce the options available to the manager. The second is that you focus the management on the solution and make it easier to restate success as introducing the solution rather than fixing the problem. Once again, a busy executive in parent ego state cannot then blame you if the problem is not solved. This belief restates “We need to solve this problem” to “Do you want us to implement this solution to solve this problem?”. The unwary leader can easily step into a risk averse relationship. Consultancies love this approach because they get the credit for successfully implement several solutions without solving the problem (The Golden Goose).

One way for a leader to disrupt a stable parent-child, risk averse failureship culture is to collapse the power distance index. More in the next post.

Part 2 – Leadership strategies to address failureship

Part 3 – Failureship counter measures


Kanban sucks!

Nigel Thurlow wrote a linkedIn post stating that the Kanban used in Agile Software Development is not the same as the Kanban used in manufacturing. Nigel is the most knowledgeable person I know on Kanban in manufacturing, based on his many years as a practitioner in Toyota. Nigel explains that his knowledge of the Kanban used in software is based on training software.

Nigel is correct. This is my “Yes, and…”

Kanban in Manufacturing

As Nigel states, the purpose of Kanban in manufacturing is to ensure that supply meets the demand of customers. In front of each work station is a pile of input goods (which may only be one item). When the pile is reduced to a certain level (e.g. only two items left), a card (Kanban) is revealed that is passed up stream to the work station that provides the input goods. The Kanban card is the signal that pulls the work from the up stream work station. The size of the pile of work in front of a work station is based on the balance between how long it takes the input work station to replenish the items and how long the pile will be completely depleted.

At Agile2009, Todd Little pointed that if only a single product with no variation is being produced for the customer, then Kanban is not needed and lean will suffice. The up stream work stream operator simply monitors the queue between it and the down stream workstation to determine when to replenish the queue. Kanban is used when there is more than one product variant.

In manufacturing, the design and manufacturing process are distinct. The physical good is designed in one process, and then manufactured in a separate process. This means that when a customer requests an item, the manufacturing process is completely known in advance. Furthermore, each customer request results in exactly the same manufacturing process, exactly the same steps, and the process can be optimised over time to match demand and supply, ensuring work appears “Just in time”.

In a manufacturing Kanban system, the work station stages are “Build” and “Deploy”. “Design” and “Test” are done as a separate process before the customer makes the request. This means that when a customer makes a request, it is possible to predict how long it will take to deliver. If a customer wants an item before it can be delivered, then it is known that this will overload the system and the customer must wait, or an item is expedited with a known negative impact on the effectiveness of the system.

Kanban in Software

Kanban in software was inspired by Kanban in manufacturing as a mechanism to limit work in progress as a way to match demand and supply.

In software development, the design and manufacturing process are NOT distinct. When a customer requests software, it must be both designed and implemented. The software is ONLY built once, though it is tweaked and modified to remove defects and add new variation over time. In software, the work station stages are “Design”, “Build”, “Test”, and “Deploy”. The “Design” and “Test” introduce huge variability in the process that does not exist in a manufacturing Kanban system. The work to be done is not known in advance. This means that it is not possible to know in advance when a customer request can be satisfied. This means that there is a real danger than customer demand floods the software development process leading to huge levels of work in progress that takes a long time to deliver.

Kanban in Software addresses this problem by limiting work in progress. It does this at a system level and/or a workstation level. To match supply and demand, software Kanban uses queues to identify where two workstations or systems are operating at mis-matched rates. A queue between two system/worstation grows when the up stream is faster than the down stream, and a queue shrinks when the up stream is slower than the down stream.

Software kanban can be implemented using explicit work in progress limits which specify the maximum number of work items in each work station and in each queue between work stations. Alternatively, a Kanban system can be operated using a work in progress limiting policy which also limits the amount of work in the system. ( e.g. Each person can only work on one item. Only one item is allowed in each queue ). These limits lead “idle” work stations that are blocked to help the other works stations that are blocking them.

Rather than specifying the date when software will be delivered to a customer, Kanban focuses on ensuring the order in which software will be delivered. Limiting work in progress ensure that the software is delivered in the fastest time, and reduces (but does not eliminate) the uncertainty around when it will be delivered.

Kanban Sucks (in Software)

In a manufacturing Kanban system, the kanban card moves from a down stream work station to an up stream work station to act a “Pull” / request.

In a software Kanban system, completing a work item or taking an item from a queue creates a “hole”, a gap of unused capacity at the work station, or a space in a queue. This “hole” or gap can then be filled.

Karl Scotland and Eric Willike coined the phrase “Kanban sucks!” which is a very profound and deep understanding of the differences between manufacturing kanban that “pulls” and software kanban that “sucks”.

Go to the Gemba

When you are master in one domain, it is very seductive to assume you are a master in another domain if they use similar language. Studying training software helps you understand how software companies sell their product. If you truly want to understand how kanban in software works, then you need to “go to the gemba” and see how practitioners actually do the work.


Real Options and the Cynefin Estuarine Framework

David Snowden recently gave a Complexity Lounge talk about the new Estuarine Framework. The Estuarine Framework is starting to incorporate real options, even if its creators are unaware of the fact. If we strip away the fluff and Stevian language, the meat of the framework is the presentation of options on a consultant’s two by two grid with a Y-Axis of “energy” and an X-Axis of “time”. We are told that “C” level leaders are more likely to engage with options that have low energy and time, and high energy and time options are “Counter-factuals” as they won’t happen. Below is a screen shot of the Estuary Map presented.

Copyright Cynefin Con Ltd

Any Real Options practitioner (there are no experts) would immediately realize that a third dimension is needed on the Map to represent level of uncertainty / volatility. We know that most people, and especially leaders, have a strong aversion to uncertainty. Without this uncertainty dimension, people may get lost in the swamp unsure why low energy, low time options are being ignored, and high energy, high time options are preferred.

Time in this model refers to one of the variants of lead time. It does not refer to timing which is one of the sweet spots of real options. Lead time is an operational metric, however from decision making perspective a risk metric such as duration (a.k.a. weighted lead time) is more useful.

An analysis of “energy” by a real option practitioner would reveal that its a “metaphor’, “euphemism” or “double entendre” for “cost” or “input”. What is needed in terms of input to make the change happen? The “metrics hierarchy” is a great way for practitioners to make sense of “cost” whether it is financial, social, environmental, energy of some form (e.g. Oil, Gas, Nervous) or even power exerted over a period of time. Each organization will have its own hierarchy that reflects its vision, values and culture. In academic terms, we would refer to the hierarchy as a context free “Typology of Costs”.

Decision making frameworks rarely involve just cost and time. Typically investments are compared using risk adjusted return on capital. Risk, Return and Capital (Cost) each have their own hierarchy to support sense making up and down, and across the organization. In context free academic terms, these would be a “Typology of Risk”, a “Typology of Return”, and a “Typology of Cost”. It is worth noting that lead time as expressed in the Estuarine Map is one example within the “Typology of Risk”, another significant one being uncertainty.

What is currently missing from the Estuarine Map is “Return”. Currently the map focuses on Energy (Cost) and time (Risk) when comparing options, however it does not incorporate “Return” or the value delivered by the change option. This is possibly because bad “C” Level leaders focus on “energy” ( cost ) which is something they can control rather than “Return” which is something that their customers normally control. We know from Clayton Christianson’s work that poor product designers give their customer’s what they want and ask for, and good product designers avoid the innovator’s dilemma and give their customer’s what they need, ultimately stealing them away from the poor product designers. As good product designers, we choose to include “Return”.

Once we have added “Return” to the Estuarine Map Framework, we can muse over which uncertainty or risk dominates. Is it the uncertainty of “energy” (Cost), “time” (Risk) or Return. In an academic context free world, there is a single answer. In the real (options) world, it depends on context.

Hopefully Estuarine Mapping will continue to develop into a useful decision making framework. As it does so, the value of real options will become better understood.


Sir Mark Rowley – A case study in Failureship

Sir Mark Rowley, Metropolitan Police Commissioner gave a masterclass in Failureship on Newsnight. This is a link to the interview that Sir Mark Rowley shared himself on LinkedIn.

Click on the photo to go to Sir Mark Rowley’s LinkedIn Post about his Newsnight Interview

Sir Mark Rowley’s response to a whistleblower calling out horrific behaviour is:

I’m currently building and launching a massive new team, an Anti-Corruption and Abuse Command

No commitment to the results, only a commitment to action. Classic failureship response to focus on a solution rather than a deeper understanding of the problem. We all know that a team will be set up and will waste millions of tax payers money with the end result of “None of our fellow officers are a problem.” or perhaps “We found a few token rotten apples, mainly the ones that management already knew about”. You could lift the script from the movie “LA Confidential”.

However, the really telling statements relate to the culture of transparency. In a failure culture, the leadership do not want transparency. They actively discourage it. Repeatedly, the police officers are taught that “Snitches get Stitches”. In a work environment where collaboration and cooperation are vital for personally safety and security, getting a reputation as a snitch result in someone failing to watch your back at the exact moment you need them to.

On transparency, Sir Mark Rowley said:

As a Senior Officer, you have to be realistic that it’s not going to be shared with you.

I’ve never had anyone bringing that stuff to me.

Sir Mark Rowley should have said:

I am horrified that this was going on and I did not know about it. Clearly good police officers knew about it but did not feel compelled or feel safe to share it with me. I need to make it easier for good police officers to discuss difficult issues like this with senior police officers so that we can act to root out this corruption.

Some suggestions for Sir Mark Rowley which don’t cost much at all:

  • The excuse that a senior officer is unaware of bad behaviour should be seen as a failure of leadership. They need to mentoring and coaching to help them learn how to make sure they do know when there is a problem rather than suppress the transparency.
  • Fundamentally you need to reduce the power distance index. New recruits should feel as comfortable speaking to senior police officers as they do speaking to each other. If a new recruit needs to speak to the Metropolitan Police Commissioner, it should be clear what they need to do to speak to them with minutes or hours. Each police officer should be assigned two senior mentors in two different forces. Senior officers will need to build deep build relationships with all police officers. Its should be the responsibility of the Senior Officer to build relationships as its almost impossible for the Junior officers to reach out.
  • For new recruits, the relationship starts at Police Officer Training. A senior officers could be assigned to spend an entire week with new recruits from all over the country so that they have time to get to know them.
  • Get out of the police head quarters. It is a major barrier to communication. Senior police officers should operate out of police stations, avoiding the use of offices unless absolutely necessary. They should get their own coffee and mingle with the junior police officers. If a senior police officer randomly sits in normal desks for a few days, people stop noticing that they are there. They will then be able to observe the real culture, and understand the real risks.
  • In the event that something unpleasant, … or something good, is bought to your attention, go the gemba. Go to the place of work and investigate yourself. Given that this behaviour bought down your predecessors, you should realise how important it for you to be present rather than simply sending in the Anti-Corruption and Abuse Command.

The interviewer asks:

Dave Eden, the whistleblower, said that you have been silent on these issues in the past. Do you dispute that?

Sir Mark Rowley responded:

I’ve never met Dave Eden and he’s got no knowledge about my career.

Sir Mark Rowley could not have made it clearer how much he disapproved of Dave Eden, and at the same time reinforcing the “Snitches get stitches” culture where the wrong doer are fine as long as they are not caught. There is no attempt to point to evidence that Sir Mark Rowley has indeed been outspoken about these issue. Pure failureship… attack and dismiss the messenger.

Instead, Sir Mark Rowley could have said:

Dave Eden is a hero. I am keen to meet him as soon as possible (hint: Go to the Gemba) so that I can better understand why the system has failed. We need more heroes like Dave. I want to better understand the changes we need to make it easier for people like Dave to come forward. To do that I need Dave to help me on this journey.

And I think Dave Eden is right. I have not been loud enough on these issues. If Dave is not aware of my position on these issues, then many others are also not aware of my position. I need to communicate better.

On behalf of the London Metropolitan Police I would like to thank Dave Eden for having the courage to push this issue into the public arena when our internal mechanisms have obviously failed.

Sir Mark Rowley demonstrates several of the Failureship Anti-Patterns in this interview. Hopefully he will reflect and address the failureship culture he is now responsible for. If not, as a resident of London I hold my breath waiting for the next incident when an officer in the Met Police fails us yet again.


Failureship and “Show, don’t tell”

Thirty years ago I moved to London from the North of England. To fill my empty dance card I took night classes in short short story writing. Thirty years later the one thing we were taught that is still seared into my memory is “Show, don’t tell”. The example the teacher gave was, rather than “He was an obsessive about hygiene”, instead use “He brushed his teeth so often that he caused his gums to bleed”. It turns out “Show, don’t tell” is an effective strategy for leading change. The failureship adopt the opposite strategy… they simply tell.

Photo by Clark Tibbs on Unsplash

Over a decade ago I went for a job interview with the architect team at a major US investment bank. They explained to me that they managed one of the most complex systems in the bank. They did it to show that they were not an ivory tower group simply telling all the development teams what to do.

The failureship approach is to tell people what to do. They often tell people to do things that they cannot do, or even want to do. This is so common that popular books on culture change have a term for it, they do not “Walk the talk”. Its a struggle to identify an outstanding example of failureship of this kind. Not because it is rare, quite the opposite, it is such a common occurrence that it difficult to pick an example that truly stands out. A government advisor visiting Barnard Castle to test his eye sight, or a Prime Minister partying whilst his country follows his rules show its reaches to the top of society. Every time a Scrum Master skips the retrospective is an example of a leader failing to “Walk the talk”.

The most inspiring leader I’ve experienced when it comes to “Show, don’t tell” is Tom Sugden at UBS. Tom is the CTO setting the technology direction for his organisation, but rather than simply telling his fellow CxO what to do, he also runs an entire department. This gives Tom the opportunity to implement the technologies that he proposes as the future of the organisation. Furthermore, he shows how it can be done at scale. This gives Tom huge credibility and influence when it comes to providing direction to other parts of the organisation. Tom makes sure that his department is at the forefront of adoption and change. The fact that Tom’s department implements the things he promotes gives them much more credibility than simply telling other department heads to adopt them.

“Show, don’t tell” is about living the values and ideas that you promote. Its about doing the hard work and avoiding the easy path that undermines your credibility. When faced with the easy option that undermines your vision, be more Tom.


Western Ukraine – The 21st Century Dunkirk

Have you ever imagined what it would be like to be one of the small boat captains who made such a difference at Dunkirk? To do a small thing that was part of something vastly bigger than yourself? To do something that makes a difference?

On Thursday morning I Skype chatted my colleague in Kyiv, Ukraine to discuss a mundane task we are working on. “Are you free”. His reply “No, running West with my family, Russia attacked” was my first knowledge that Putin was deploying Blitzkrieg tactics against the people of democratic European nation of Ukraine. By now tens of thousands of Ukrainians are stranded at the Western Border adjacent to Poland, Slovakia, Hungary, Romania and Moldovia. Unlike Dunkirk, this 21st Version is not soldiers fleeing West from an aggressive force, it is families, men, women and children, with modern jobs of doctors, nurses, teachers and IT professionals. The spirit of Dunkirk calls us to them.

I have Skype chatted with two colleagues, both IT professionals in Western Ukraine. They are refugees, and they continue to work, even as they plan the next steps for their families and their colleagues. They are you. Imagine giving yourself two hours to pack your life into your car knowing you might never see your home again and then running ten hours to the west in your car. This is not them, this is you.

They believe they cannot come to Europe because they do not have Visas. The ever amazing Amanda Burgauer solved that for me. Thankfully Ireland is showing leadership and has removed the requirement for a visa. Once they are processed in Ireland, they are in the Schengan area and can travel anywhere in Europe, or anywhere in the UK under the Common Travel Area agreement. We need to get these families from the beaches of Dunkirk in Ukraine to Europe. Perhaps the airlines in UK who cannot fly to Russia, Belarus and Ukraine could use those planes instead to shuttle people to Ireland from the airports near Ukraine’s western borders? update – Relocation options for Ukrainians. https://bit.ly/3ss0UcU

Very quickly Ireland will be overwhelmed with refugees. And that is where we come in with our little boats at Dunkirk. Last night my partner turned to me and said “Your colleagues should come here. We have a spare room they can use.” Do you have a spare room? Do you have an empty holiday let? Reach out to friends, family and colleagues via Facebook, Twitter, and LinkedIn and let them know #IHaveASpareRoom. Don’t rely on the governments as they will be overwhelmed. Reach out to friends, and friends of friends as it is much safer than dealing with strangers. These fellow Europeans of ours do not need our help long term, they are people who are coming here with their own jobs that they can continue remotely. They just need somewhere to stay now that Putin has stolen their home. They will soon be back on their feet in a new home.

If Putin takes control of Ukraine, he will no doubt take control of its banking system, depriving Ukraine’s citizens access to their bank accounts and financial assets just at the time that they need them the most. Hopefully the European retail banks can respond quickly to this crisis and provide the Ukraine’s citizens with a way to transfer their accounts out of Putin’s control.


Trust, the Achilles heel of Failureship, and Intregrity

In the early days of Agile, many in the Agile leadership community embraced “Trust First” meaning if you trust me, I’ll deliver. Some of them hunted for ways to “build trust fast”, looking for a magic formula like the one in David Maister’s “Trusted Advisor”.

It turns out that trust is something that is earned over time as we interact with others. Not only is it earned over time, there is one phrase which is guaranteed to destroy trust, and that is “Trust me”. Furthermore, trust is contextual. Would you trust your sixteen year old niece or your mechanic to perform heart surgery? Would you trust your sixteen year old niece or your surgeon to fix your beloved classic car? Would you trust your surgeon or mechanic to babysit for your young kids?

Engin_Akyurt on Pixabay

Introducing a new approach or technology is a high risk venture for any leader, especially something like Agile or Cloud. Now imagine that you are one of those leaders who knows next to nothing about the new thing because you have never worked with it in the two decades it took for it to come to dominate your industry, we will call this group “The Majority”, then you really want someone you trust to lead the flagship first project. Leaders in failure cultures are used to encountering people who tell a good story, and then fail to deliver… They trusted those chaps from Negligenture (its not an Accidenture if the people driving are not experienced), they trusted those chaps from Kinsey’s Daughter. All of the big name consultancies said that Safe was the safe option… so why would these people they never heard of be any different, especially as they are not offering you personal guarantees like a better job if something goes wrong, nor a skiing holiday to recuperate from a retrospective (whatever that is), or free training material written by people who they guarantee do not understand the material. So the persons chosen to lead the introduction of new technologies and approaches are always people that the leaders trust. People they have worked with many times before, normally on initiatives that failed, but people they know and trust. Given that they cannot tell who is competent and who is not competent, without listening to their own subordinates who have been advocating for the new approach for years, they might as well pick the people they have worked with before.

Trust is the cat nip of the incompetent.

Rather than focus on trust, focus on integrity.

  • Does the person or organisation do what they said they were going to do.
  • Do they make it easy for you to identify that they have failed to deliver what they promised, and even make it easy for you to understand that they WILL fail to deliver.
  • Do they silently correct the spelling of Intregrity in the title of this post that is so annoying? Or do they openly discuss their mistakes in the retrospective so that others can learn from them?

Someone on the internet defines integrity as “the quality of being honest and having strong moral principles.”. “A person of complete integrity” <– If we are being honest, I replaced “gentleman” with “person” because it felt a bit sexist and class systemy (not a real word), the idea that women, or men who were not gentlemen are excluded from the definition of integrity seemed outdated.

Rather than simply trust a person, or an organisation, give them small goals and see if they deliver.

  • If they claim to have a lot of experienced developer or agile coaches – Interview some of the potential candidates. Get your existing experts to interview them and if they are not experienced, then clearly the person or organisation is not acting with integrity. Reject them if they lack integrity.
  • If they claim to be agile developers, ask them to deploy a “Hello World” application through the entire build chain (including setting up the build chain) into a production environment in hours or days.
  • If they claim to be cloud developers, ask them to deploy the application to the cloud in that first release.
  • Create a very small story that delivers business value to a small group of users and get them to deploy into production.
  • Get them to limit work in progress to one, possibly two epics at a time.
  • Hold them accountable to the things they say they can do, and listen when they say they cannot deliver.
  • NEVER let them take on a large amount of work in progress that takes more than a few weeks to deliver value before it can be verified.

When someone promises something and fails to deliver without giving you enough warning so that you can exercise alternate options, they are acting without integrity.

At one organisation undergoing a transformation a number of the key leadership role were taken by people with no experience of the technology and approaches being adopted. Those individuals were the same people who had key role in the previous attempt at a transformation THAT HAD FAILED. They were given key roles because the executives trusted them even though they proven their incompetence in previous transformation.

So the message to executives in failure cultures is simple. STOP TRUSTING PEOPLE. Instead set small goals and see if they deliver against those goals. Test to see if the people and organisations deliver what they sell, test to see if they act with INTEGRITY!


Learning to learn in a risk managed culture

Whereas learning in a failure culture is dominated by training courses, personal study and certification, learning in a risk managed culture occurs as people do the work and solve new problems, problems that they be the first in the world to encounter. I worked in a failure culture where people were given “points” when they completed training courses on Coursera or read a book on O’Reilly. The “point” score was recorded in a system that monitored Coursera and O’Reilly activity and was used in the end of year performance appraisal. It was a an example of failure culture mentality, “Measure it because it is easy to do so, not because it is valuable or the right thing to do.” However the real problem is that you are rewarding the laggards, the people who have failed to stay up to date in their chosen profession.

Photo by Maxi Corrado on Unsplash

By the time a subject makes it “big” with several books on the subject, you are looking at the idea being between five and ten years old. By the time a subject has a single book on the subject, the idea is about three to five years old. It takes one to two years for someone to write a book on a subject, particularly a new subject. Before someone writes a book on a subject it is normally implemented in a few different organisations. Prior to appearing in a book, a subject is normally discussed or described in blog posts, in meetups, in conference sessions, in e:mail groups, and in twitter threads, all of which are available on-line at some level either as blogs, YouTube or Vimeo videos.

Cloud as a case study.

I remember back in 1997 when a strange phenomena occurred on the derivatives trading floor at Chase Manhattan. All of a sudden stack of five PCs would appear at the end of a desk with a single monitor and keyboard, and a switch that could be used to inspect each PC using the monitor and keyboard. Shortly after the cloak room was cleared of coats and sweat gym kit and replaced by stacks of PCs without monitors and keyboards. By 2005 the credit derivatives trading desk at BNP Paridas had hundreds of IBM high reliability PCs in its data centre. In 2010 UBS had twenty thousand cores that we could switch between using for UAT or Production depending on the priority. In 2014 Skype leased twenty thousand machines from Amazon Web Services for just a few days. Since then, Kubernates, Servlerless, Microservices have flourished around the world. And in 2022 failure cultures around the world are rewarding developers for learning the basics about the cloud on Coursera or O’Reilly. Rewarded for being twenty years behind the leading edge, and a full decade behind the early majority. Of course anyone who learnt about the cloud along the way doesn’t get that recognition.

Managing the risk associated with learning.

When I coach coaches about learning I use Sharon Bowman’s “Training from the Back of the Room” to structure a conversation about learning. “Tell me as many different ways you can think of to learn?” is the Connection question. Write down as many ways you can think of… The answers normally include “Blogs, Books, Articles, Videos, Doing It (though rarely in the agile world these days), Training Courses etc…

For the Concept I introduce them to a modified version of David A. Kolb’s “Circle of Learning”.

  • Observation – The learning is separate to the action. e.g. Reading books, articles, blogs. Watching videos or watching other people doing things.
  • Reflection – Discussion of ideas and observations. e.g. Retrospectives and discussion groups.
  • Experience – Doing things, interacting with reality.
  • Modelling – Creating models of how things should work.

For the concrete I ask two questions. The first question is “What types of learning are the least risky for individuals who do not want to show they do not know the material?”. The answer is “Observation” and “Modelling”. These are types of learning that an individual can engage in such that other people do not know they do not understand the material. The second question is “Which types of learning are least risky for the organisation?” The answer is “Experience” and “Reflection” as they learn by doing something, met by reality each step, or are challenged by others who have different experiences. People who learn by doing start with “Hello World” and build up their knowledge incrementally making sure each step works. People who learn by reading books and articles, and modelling can suffer from Dunning Kruger and build grand architecture that SHOULD work.

Learning in a failure culture will be dominated by “observation” and “modelling”. Learning in a risk managed culture will have a preference for “experience” and “reflection” but will also learn from other organisations through observation, and identify gaps in knowledge, and design experiments using modelling. Risk managed cultures are more likely to come up with innovate approaches to solve real world problems whereas failure cultures are more likely to simply follow the herd.

Impact of Learning Style on Culture

Learning by doing is not about playing with canned examples but rather applying new knowledge in the context of work. Complex skills are learned by beginners through a process of legitimate peripheral participation, or situated learning which could be described as the “Padawan Model”. Teams in a risk managed culture adopt new technologies gradually solving real business problems using small safe to fail experiments. They do not learn by adopting a new technology in a big bang approach. The majority of the learning takes place as part of the work, with the product owner putting one or two stories using the new technology into the sprint, possibly as time boxed spikes.

Expecting the team to do the learning by reading books and acquiring certifications from on-line courses naturally leads to that work being seen as secondary, which should be done outside of office hours in employees’ personal time. This creates an “interesting” cultural bias. The people who will have the least amount of time outside of work are those that have other responsibilities such as parents, especially single parents, carers looking after a sick friend or relative, people who support others in the community such as councilors, youth workers or charity volunteers. The people who do have the time are likely be people who do not have those types of responsibilities. The people who do have the time will have an advantage and will be able lead discussions regarding new technologies marking them out for promotions. This style of learning results in an organisation where the natural leaders with empathy for others are disadvantaged, a culture where leaders are less empathetic and less diverse in their thinking.

How failureship blocks learning

The MacLean Triune brain model sees the brain in three parts, paraphrasing, these are “The reptilian brain” responsible for fight or flight get me out of trouble mode, the “Everyday brain” responsible for every day life, and “The holo-deck” where the brain imagines new thing in familiar and new scenarios. We can only access the “holo-deck” if we feel safe and unstressed, stress drives us toward the non-learning “reptilian brain”. Learning requires us to be able to access the “holo-deck” so that we can think through how a new approach might impact the way we work and how we need to modify that work. Extreme pressure, especially time pressure creates stress which makes it hard to acquire new skills. The failureship demand teams adopt new technologies and approaches, AND they demand that team meet ambitious deadlines… is it any surprise that the first bump in the road sees teams scurrying back to familiar, old ways of working in the reptilian brain. I liken this to a child learning how to ride a bike. They put all their weight on the foremost pedal but at the same time they put their weight on the back pedal, the result of which is the bike doesn’t move.

Leaders in risk managed cultures give the teams space to learn and apply new technologies and approaches as part of their work. They see the learning as a valid form of work rather than a luxury for those with excess spare time.


Recruitment in a risk managed culture

Organisations attempting to transform to a more innovative and diverse risk managed culture often struggle with recruitment. Failure culture almost exclusively hire people to fill a role whereas risk managed cultures hire good people.

Photo by Ryan Quintal on Unsplash

Job adverts in failure cultures will advertise for “Senior Web Developer with 5 years experience with React”, “Project manager with 10 years experience in Investment Banking or a big 5 consultancy”, or “Business Analyst with 2 years experience of equity derivatives”. These job adverts all contain strong biases that make it less likely that individuals from diverse backgrounds will apply or even have the appropriate skills. Failure cultures tend to have roles that focus on the delivery of things whereas risk managed Cultures have new roles and new skills that enable the delivery of customer and business value.

Traditional roles in a failure culture are off putting to people that are used to working in a risk managed culture focused on customer and business value.

“Senior Web Developer” indicates that you are entering into a silo’ed world where there are front end developers, back end developers and devOps engineers. Delivering anything of value is ALWAYS going to involve working with others and you will never get the chance to deliver a small slice of end to end value. A more enticing role might be “Full Stack Developers with a desire to continually learn and master new technologies and practices”. If you spend any time with top developers you will know that they don’t know a single language but know several and are constantly learning and mastering new ones, often by working on pet open source projects.

“Project manager with 10 years experience in Investment Banking or a big 5 consultancy” indicates you are going to be working in an environment where someone else is going to be telling you what to do, and you are going to be expected to micro-manage people with little or no experience. All of that collaboration and facilitation you have enjoyed in previous roles will be replaced by coercion, control, and micro-management, and aggressiveness or passive aggressiveness replacing focus and harmony.

“Business Analyst with 2 years experience of equity derivatives” is the ultimate “old boys” club role. The only way to get the role is to already have the role. It is unlikely that the role is about the excellent analysis, learning and discovery skills of business analysis and more about knowing the “insider language” of equity derivatives. Knowing what delta is rather than being able to look it up in a financial dictionary. These roles often go to former business people who worked as brokers, traders, and often friends of some senior person that they will be working for. Rarely does the analysis part of the role matter, as faulty subject matter expertise based on how things were done is more important than customer needs and how things should be done. Nothing says “only insiders need apply” more effectively.

The specificity of the roles themselves are a problem. I worked on two of the eleven customer journeys at Lloyds. An impressive and bold initiative guided by Jon Webster to shift from a failure culture to risk managed culture. Key product discussions would include many roles each representing a point of view with the aim to create an excellent customer experience. It was typical for product discussions to include a product owner, business analyst, service designer, UX researcher, UX Designer, UI Designer, system thinker, model office (mini call centre), business process experts, risk (a lawyer) and an agile coach. There was no filter at the door and anyone who felt like it would join the conversation. The executive responsible for the journey changed, replaced by a long standing employee of Lloyds. Shortly after joining, the new executive shared a story of how different things were. Lloyds had an annual employee survey and our journey had scored the lowest in the company in two questions. The first question was “I know what my job is.”. Worried that no one knew their job, the executive asked the apprentice what he thought. The answer shocked him “YES! Isn’t it brilliant. We can work on whatever is most valuable rather than be restricted by our role”. The executive said that was the moment they realised everything was very different, but different in a good way. The second question was “We are doing enough for our customers.” When the executive shared the result with the journey, he realised that a team of people dissatisfied with the customer experience is exactly what you want for the people improving that experience.

In a traditional failure culture the roles reflect the internal silo based attitude of self interest. Silo’ed developer, tester, project manager, business analyst. Customer and Business Value focus introduces a whole new landscape of roles requiring a focus on continual development of T-Shaped individuals, T-Shaped individuals with an expertise in one thing like web development but have broad capability in others like testing, UX research, UX design. When people from diverse backgrounds joined risk managed cultures they were often drawn to capabilities that do not exist in the traditional failure culture organisations. They develop expertise in User Experience Research, User Experience Design, User Interface Design, Television Editing, Data Science, System Thinking (Call centre design), Service Design, Product Management, Product Ownership, Facitilitation, Sense Making. These new roles that represent diversity either do not exist at all in failure cultures or are small and marginalised.

Of course, one of the worst mistakes that failure cultures make is to assume that people in risk managed cultures have the same values as they do. They assume that these new people will be happy to be given a traditional job title. They assume that scrum masters will be happy to be called “project managers” in the HR system, or that product owners, UX professionals, and system thinkers will be happy to be called “business analysts” in the HR system. A classic case of cultural imperialism that make it easier for the dominant power to classify people according to their values.

Hiring in a risk managed culture

Many moons ago I applied for a job at ThoughtWorks. I was a business analyst and ThoughtWorks was a software engineering consultancy. I was talking about wild ideas like Agile Business Analysis, Agile Business Coach and Agile Project Management. I did not fit in a neat box that ThoughtWorks was familiar with, and the normal recruitment process did not apply as I could not code. As a result I had interviews with about nine people. It was a long drawn out process, mainly because I was enjoying gardening leave, and eventually I joined ThoughtWorks. A while later I interviewed a candidate who was well beyond my comfort zone… someone with a PhD in psychology with an interest in user interaction and a background in Accenture. I had none of the experience they described but I was dazzled and I wanted them in ThoughtWorks so that I could work with them. They also had a LOT of interviews. They joined ThoughtWorks and did very well indeed. I got to work with them and LEARNED A LOT. The lessons I learnt at ThoughtWorks about hiring are:

  • Do not only hire people who fit in one of your boxes.
  • When you find someone who is out of your box, get them to meet lots of your good people.
  • Finally and most importantly, HIRE GOOD PEOPLE, do not just fill a role.

Failure cultures who lament that they cannot hire diversely struggle to do so BECAUSE THEY DO NOT WANT TO. They just say that they want to because they know they are meant to say that.

Diverse hiring

Here is an experiment for any large (greater than 1000 employees) organisation to try:

  1. DO NOT HIRE FOR ROLES. This will automatically filter out any diverse candidates or people with different skills to the ones you are already overrun with.
  2. Set aside a few percentage of your headcount as diversity hires (e.g 3% of 1000 people is 30 people). These are people from backgrounds that are different to your current employees. It may be race, gender, sexuality, etc. or different skills.
  3. HIRE GOOD PEOPLE. Forget hiring for traditional skills and hire good people instead.
  4. Provide each diversity hire with a senior mentor. Make sure the senior mentor is competent and cares about the organisation and their mentee. Do not pick mentors who will minimise their effort but rather pick ones that will invest time to maximise the mentees future.
  5. Sack any senior manager who is not mentoring junior people effectively <— I decided against this one because I did not want to be responsible for a golden age of work and profitability.
  6. Let the diverse hire find the place where they think they can add the most value.
  7. DO NOT let a manager with no experience of a person’s skill set and the value they can deliver make decisions for that person.
  8. When one of the diversity hires finds a role they want to do, support them in finding their place, and free up the space in the diversity hires headcount. i.e. You have a new slot so go to step 3.
  9. Stop giving internships to privileged individuals such as people who went to private school or whose daddy is a friend of a member of the board of directors. Give ALL internships to people from diverse or under privileged backgrounds.
  10. Graduate schemes…. see internships.
  11. Ensure all interns and graduates get a mentor until they are hired and settled into a role… even if they decide to work for another company!
  12. Understand that if the diversity hires fail, IT IS YOUR FAULT, NOT THEIRS! Anyone who engages in behaviour that is rascist, sexist, islamaphobic, anti-semitic, transphobic, homophobic, bullying or any form of ass-hole-ry should be immediately removed from the situation whilst an investigation takes place and then sacked if found guilty. Under no circumstances should such individuals ever be promoted.

The problem with diversity hiring in terms of new people and new skills is that organisations with failure cultures continue to hire people who fit into their existing roles. To break this cycle, HIRE GOOD PEOPLE instead.