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?

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!

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.

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.

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.

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.

Once we have identified the teams we need to deliver value, the next step is to create the teams. As always, the way we reduce the risk in a system is to increase liquidity by creating options.

We started with an organisation like this:

And we want to move to an organisation like this where the each team has five to nine members:

The teams start by creating a skills matrix for the current situation. For the input team, that might look as follows:

This simple exercise is itself quite revealing. We can see that there are three areas of the input team. Whereas Sue appears to share her knowledge, Attilla and Walt look to be hoarding their knowledge. At this point we invite the Jabe Bloom observation… “We use the data as an invitation to go to the Gemba” rather than to make decisions. In one organisation with a failure culture, the leadership did not believe the results and decided to dig deeper. They discovered that some people were key man dependencies and wanted to hide the fact for job security reasons, either by hiding their knowledge or encouraging others to overstate their knowledge using Dunning Kruger Fu.

Attilla and Walt may have acquired their knowledge when the system was originally built and have acquired their position by “knowing where the bodies are buried. The testing framework is clearly not valued as it reduces the dependency on them, the only knowledge being how to disable tests written in the original build when they fail. Neither Attilla or Walt should be considered for a leadership role even though they are currently regarded highly by their failureship and the business for their ability to resolve crises that they have created.

Sue has apparently shared her knowledge through out the team which can easily be tested by asking Kevin and Paul to perform a refactoring without her assistance. Sue clearly values automated testing which is reinforced by the teams knowledge of the build process. Sue would make an ideal leader even though Sue is not so well known by the failureship and the business because her area of responsibility generates little or no crises.

When forming the new teams Attilla and Walt should not be allowed to do any work on the areas where they are a key man dependency. They should only be allowed to pair with others learning the area, or be instantly available to assist others. In particular they should be prevented from fixing any production issues which gives them credibility with business users. The “Walt” at one organisation was given the quarter end goal to train two other people. “Walt” ignored the goal and continued to fix production issues without showing anyone else what he was doing. Eventually he was locked out of the production system and his access to production issues was revoked. Kevin and Paul might be better candidates to work with Attilla and Walt as they are familiar with the practices involved in sharing knowledge from someone, whereas Tor, Sven, Hamdi and Joy might continue to work in the same manner.

The logic team might look as follows:

Although this might look a bit far fetched, this is exactly the structure for many analytics teams in investment banks where each quant is a specialist in each particular flavour of financial product.

The output team might have a skills matrix with at least three people with a “3” skill level for each component and task.

What this shows is that each team may have a different culture, and that in the case of the input team there is a failure culture and a risk managed culture within the same team. These cultures often clash with the result that the members of the risk averse culture leaving to go to an organisation where they are valued.

Who is in each team?

In the case of this system, poor risk management of key dependency risk means that it will be difficult to form teams of five to nine immediately. There will need to be an intermediary period of time where teams need to be larger to facilitate the transfer of skills. There will be a lot of pairing, and people who are key man dependencies will not be assigned tasks so that they are instantly available to support and coach others in their area of expertise.

Although the product owners and technical leads might have determined the teams needed to work on the backlog, the preferred approach is for the team members to work out which teams they would like to be on. There may be someone that a person wants to work with, or someone they want to avoid. The teams can use the skills matrix to identify gaps in their current capability. Team members can volunteer to fill those gaps by acquiring new skills. Once the longer term teams are established, the team members can work out who needs to be in the temporary larger team to effect skills transfer. This is a collaborative process across the new teams, for example Brie and Nate in the logic team commit to cross train each other on their respective specialist areas. If there is not enough business demand on the backlog to cover the appropriate areas, they might clean up some technical debt and perform some refactoring and writing of tests to get to know it well enough.

Once the team members know enough, they can split into the target teams.

Scaling Up / Scaling Down

When we want to increase capacity by adding a team, we get the team members to identify the new team structure which might mean creating a brand new team or forming a new team from existing team members. The new team members are added to the existing teams until they are up to speed at which point the existing teams split into the new team structure.

When we want to reduce capacity, we simply remove a team and redeploy it to a place where it is more valuable. Once again, the team members can come together using the skills matrix to work out who wants to stay and who wants to go.

The skills matrix normally partially exists in the head of at least one person in a failure culture. Using a physical version allows team members to collaborate in creating teams that deliver in a sustainable way because they have more fun.

We are now in the middle of the season where failure cultures engage in devastating acts of self harm known as “Comp(ensation) day”, “Promotion day”, “Bonus day” or just plain “Disappointment” day. This is the day when all the high performing individuals in an organisation become disappointed and start planning their next career move, the under performers give a half hearted “Grrr” to express disappointment, and the failureship make off with most of the companies profits justified by the heart felt belief that they did make a difference this year by saving the organisation from several crises that they created.

In order to maximise the damage to the organisation, everyone in the organisation finds out on the same day that reality is always less satisfying than the expectations set by their own particular avatar of the failureship. This ensures that all of the disappointed high performers in the organisation leave at the same time of year, destabilising the operations and presenting a crisis for the failureship to wallow in. Thankfully the failureship can rely on other organisations in the same declining over (badly) regulated industries to eject their best performers at the same time. The second advantage is that anyone competent leaves before they can gain agency in the organisation and challenge the failureship. Given their divine status, the failureship can move at any time of the year as their accrued bonuses will be bought out by their new employer eager to welcome them after six months spent in the garden.

A risk managed organisation attempts to reduce the power distance index between the layers of the organisation. The challenge is to encourage people to speak up and be transparent about the real situation on the ground (at the Gemba). Nothing increases the power distance index more than letting someone have power to set someone’s pay rise and bonus, often dangling it as a carrot to work harder to hit a deadline. People want to ensure they get their bonus and prefer to use existing approaches that they know “will work” (for them) rather than try new approaches that might work (for the organisation but not them).

One of the most corrosive aspects of bonuses is the way that they undermine collaboration between colleagues. Success is about focus and limiting work in progress. The leadership need to come together in something like the quarterly capacity planning and agree the priorities for the organisation. This is something I have seen with massive positive impact at Skype, Tesco, Prezi and the Baltic Investment Group, where the leadership of the organisation (business, not technology) agree the focus and priorities for new developments. This was only possible because they were not focused on bonuses based on individual goals. At one large investment bank where we tried to introduce capacity planning, the business were not even prepared to go into the room with each other because focusing on the priorities of the organisation would conflict with them achieving their bonus. They can often still get their bonus if they can prove that the failure was due to technology failing to deliver for them.

“Comp day” is the way that the failureship sends a very strong signal of what they really value. Although pay-rises and bonuses tell individuals whether they are valued, the failureship sends the strongest cultural signal with promotions. The reason is simple, pay-rises and bonus are private and do not affect the behaviour of other people. If someone gets a large bonus, they are unlikely to make a big deal out of it because it tells their manager that they exceeded expectations, and they do not want to alienate colleagues. If someone gets a small bonus or even no bonus, they do not want to signal to the rest of the organisation that they are considered a failure. Therefore pay-rises and bonuses do not send directional signals to the rest of the organisation. Promotions and resignations do send very strong signals to the organisation as they show what the failureship really value. Furthermore, the more senior the person, the more significant the signal to the organisation. If you are in an organisation where the leadership are promoting TRBL (The ratatouille of the latest buzzwords, pronounced “Tribble”) you should expect to see advocates and early adopters of TRBL get promotions. If the early adopters of TRBL do not get promoted, leave the company, are made redundant, or turn their back on TRBL then you know that the organisation does not value it. An even stronger signal is when people get promoted for doing the “same old thing”, especially if they are not promoters of TRBL, and even worse if they are detractors or prevent its introduction. Simply put, if the organisation is serious about tribbles, you should expect to see ALL promotions go to advocates and early adopters of tribbles. One or two promotions indicates a token effort. If you have a key players who won’t advocate for tribbles or is a detractor, you can always give them a large bonus but you do not want to signal to the rest of the organisation that they are an exemplar for others to follow.

Bonuses are an example of Skinnerism, a mistaken belief that external (monetary) rewards will motivate people to perform when all they do is motivate people to seek rewards. Herzberg’s “One more time, how do you motivate employees” tells us that salary is a hygiene factor rather than a motivator.

The next post will look at the alternatives?

The unit of delivery in a risk managed culture is a cross functional team. How do you create value delivering cross functional teams?

The diagram below displays the most common organisation I have encountered for a system. Teams focused on one part of a system are referred to as component teams. Each valuable delivery requires work from the input, logic and output team, and a project manager is needed to allocate and track the work. Although the output team may be able to deliver business value independently, it is likely that any change involving the logic and input team will also require work in the output team, even if it is only testing.

A shift from Inward Looking to Outward Looking

A common pattern for this structure is that each team contains one or more business analysts who are assigned functionality to deliver. The business analysts in the input team of an accounting system asked me to review some stories they had written for a change to the mapping logic. The mapping determined where values contribute to the line on the output report. The new mapping meant that values on one line were being split, with some of the values being moved to another place. For example, comic books are currently mapped into “Toys” but going forward any comic books worth more than $100 are mapped into “Investments”. The business analysts had created stories to explain how mapping values needed to be changed, and the functional changes. They described the changes in the rules. It is rare to find stories that clearly describe the business value and these stories were no exception. As always we start by understanding how the change is perceived by the user in the output of the system.

With comics worth $1500 of which $500 worth are worth $100 or more, and bonds worth $2000, the system would currently display:

• Investments: $2000
• Toys: $1500

With the new rules, the system would display:

• Investments: $2500
• Toys: $1000

Now that we were looking at the requirement from the perspective of what the user would see rather than simply the functionality to change, we could ask what needs the user would have. The users were accountants and one of their key needs is the ability to evidence any changes to the accounts. Simply changing the rules would not satisfy that need. Either the accountants need to run the rules, take a hard copy of accounts, change the mapping and rerun the rules, OR they needed a report that showed the accounts before and after the rule change. For example:

Date of mapping change: 1/1/2022

Mapping change:

• Old mapping: “Comic” mapped to “Toys”
• New mapping: “Comic” worth less than $100 mapped to “Toys”, “Comic” worth more than $100 mapped to “Investment”

Impact:

• “Toys”: $1500 changed to $1000 <Click here for detail>
• “Investments”: $2000 changed to $2500 <Click here for detail>

By considering the “requirement” from the perspective of the accountants, we discovered that the proposed solution to be implemented did not meet their needs and was incomplete. In order to deliver something of value, not only did the logic and output teams need to do testing, they also needed to add significant functionality. The business analysts admitted that they had already made the change and it had been stuck in user acceptance testing for months as the users would not sign it off.

The first rule of creating teams is that they should be cross functional. The team should contain all the people needed to deliver value as perceived by the user. These teams are referred to as feature teams. This indicates a shift from a failure culture delivering functionality to a risk managed culture where the team takes responsibility for delivering value.

The second rule is that each team needs a product owner. A product owner is someone who understands the needs of their customers, whether those customers are external or internal, human or another computer system. Product owners need to understand customer value and how that leads to business value, and as such they are outward looking (h/t to Scott Zebedee). Traditional roles like business analyst tend to be inward looking with an understanding what needs to be done to produce output but not necessarily understand the value of the output to the customer and the business. This also indicates a shift from a failure culture delivering functionality to a risk managed culture where the team takes responsibility for delivering value.

Typically each product owner will work with one team. Occasionally an experienced product owner may work with two teams but this is such a demanding role that an individual adopting the role for the first time should never work with more than one team.

Teams that deliver value rather than functionality?

When forming teams, we need to consider the VALUE that they are going to be delivering over the long term. To understand the value to be delivered, we look at the book of work (which will eventually be replaced by a roadmap based on metrics) and identify which teams will need to do work for each piece of value delivered, not which teams will need to make code changes.

Epic	Metric Impact	Input Team	Logic Team	Output Team
Regulatory change	Revenue at risk	Y	Y	Y
Accounting rules change	Revenue at risk	Y	Y	Y
New mappings	Retain customers	Y	Y	Y
Ads from third partner service	New Revenue	N	N	Y
Performance	Retain customers	Y	Y	Y
New customer on-boarding	New Revenue	Y	N	N
Migrate to Cloud	Reduce Cost	Y	Y	Y

It is clear that most of the work requires a team that can work on all three components. The work with Ads integration may not need work on all three components but if its a small piece of work there is no justification in having a separate team. The new customer on-boarding may justify a focused team if there is a lot of on-boarding work. The performance and cloud migration may justify a separate team if a lot of work is to be done over a long period of time that does not require work from the other teams.

The result shown in the diagram below would be several feature teams that cover all three components, an on-boarding team that has specialist client handling skills (purple man) and a specialist performance team to improve the performance metrics of the system. The goal is to form the teams so that about 80%-90% of the work they do can be done as a single team without having to work with another team on this system. The key point is that they are stable long term teams with a stable long term mission. The stable long term mission in this case might be business value, performance or on-boarding. The product owners for the performance and on-boarding teams may be people in the “grey” technical lead or project manger role.

At Skype, this group of cross functional teams was called a release vehicle or RV, something that could release value independently of other teams. The number of teams depended on the amount of work that the executives expected they needed to achieve strategic goals. Mark Gillett told us the unit of investment is the team. The quarterly capacity planning was used to refine the number of teams in each RV, with the creation of a new team, moving a team to a new RV or temporarily shifting of a team to a different mission. The teams were moved rather than individuals ( Note that the Skype model only had feature teams, not the specialist on-boarding and performance teams mentioned in this example. )

Anti-Patterns of team formation.

There are a number of anti-patterns that mean the team is not a not fully cross functional team that can independently deliver value.

• Missing skills – The team is formed with only some of the skills that are needed to deliver value. Most commonly, the testing capability is missing from the team and is provided by a central testing team.
• Missing parts of the Value Stream – As mentioned above, the teams are formed around a component of functionality rather than the entire system.
• Non-diverse teams – Jim Coplien has done research that shows diverse teams out-perform non-diverse teams, especially if there is a mixture of men and women on the team.

Another common mistake is to split the teams so that some focus on the delivery of customer value (business facing) and some who focus on code quality (Automated Test Coverage, Clean Code, DevOps). This creates a culture where the customer value teams do not care about code quality. As the teams are funded rather than the projects, the code quality teams are the ones most likely to be unfunded in a review by the business investors.

If you have experienced other anti-patterns, please share in the comments.

So the conclusion is to form teams based on value rather than functionality, with product owners that are outward looking at customers and business value rather than individuals that are inward looking at functionality. The next blog will describe how to get the teams to the right size using a skills matrix.

Thank you to Scott Zebedee for helping me with the inward looking / outward looking concept to explain the ideas in this post.

The unit of delivery in agile is the long lived cross functional team. Rather than individuals struggling to perform their allocated tasks, a team takes responsibility for delivery of work items that deliver value. The team work together to deliver value for the customer, supporting each other to perform tasks, and learning new skills to become “T” shaped. Each team contains between five and nine people. The failureship, especially the frozen middle, act as a serious impediment to the formation of teams, and will destroy teams if they form.

The most common organisational design to support a single system in a failure culture is shown below. It arises out of a desire to reduce costs and use expensive low cost developers that can quickly come up to speed. There are separate “teams” who look after Input, Logic, and Output (ILO). Similar anti-patterns include the Front End, Back End, and Database (FBD), Business Value, Support and Refactoring (BS Refactoring), or Development, Operations, and Testing (DOT). The net effect is that several teams are required to deliver anything of value to the customer. Each of the “teams” will contain any number of people from one to one hundred and beyond.

Each sub-system has a individual shown in Grey who acts as technical lead / architect / component lead / sub-system manager (line manager). This person is normally from a developer background rather than a project management background. Their power comes from having a holistic understanding of the component that they lead, especially an understanding of where the technical debt is hidden or “where the bodies are buried” as it is also known. In effect they have a skills matrix inside their heads where no one else can access it. In order to deliver anything of value, several teams are always needed.

This is not considered a problem because a Project Manager pulls it all together into a deliverable. They take named individuals from the team and form a short lived team (called a project) to make the deliverable happen. The individuals are not part of a real team and are solely responsible for making their part of the deliverable happen. The Project Manager works closely with the Grey who allocates the “resources” to the project manager.

The good news for the organisation is a dog eat dog hero culture will emerge, but the bad news is there are a lot of key man dependency (poor skill liquidity). In reality, apart from the Grey, the developers in each of the teams are not skilled in all aspects of the sub-system and each developer has part of the sub-system that is “theirs” which maximises job security.

Where the delivery of value involves more than one system, a program manager is required to manage the deliverable from the project managers.

A shift to a team based culture would result in an organisation design as shown below. Each team has all the skills necessary to deliver end to end value. ( How to form the teams will be discussed in a later blog post. ) The “Grey” roles would disappear, as would the project manager role as teams took responsibility for their own work. Long lived teams teams of five to nine people would work together and collaborate, sharing knowledge and skills. Although the long term team size is five to nine people, during the formation of the teams, larger teams may form to facilitate the transfer of skills and knowledge (possibly using a skills matrix to assist) before splitting into more appropriately sized teams.

Where more than one system/team is required, the teams would form a scrum of scrums to facilitate the delivery of the value. Where the same teams are coming together in a scrum of scrum over and over again, the teams may merge for a period and then split into two or more teams as appropriate.

In addition to this delivery structure, the organisation may implement the chapter from the Spotify model. The chapter lead acts as line manager for the individuals with a particular skill set to ensure personal development and alignment of skills. Historically this need for personal development lead to the development of departments and silos (Source: Marc Burgauer).

We need to talk about Kevin

One of the biggest challenges for an organisation looking to move to a team based model is what to do about the frozen middle failureship… the Project Management Organisation (Project Managers, Program Managers, Portfolio Managers and PMO) and the “Grey” role. In order for the new organisational design to emerge, the frozen middle failureship must disappear. Whilst they exist, the project based model will persist. The frozen middle has more power than any other group to make things happen, or prevent them from happening. They can easily force any transformation into failure, and they often do. Simply put, the transformation shifts power and responsibility from the frozen middle failureship to the teams. The frozen middle often resent the loss of power, and the teams are often fearful of taking up the responsibility.

The frozen middle anti-pattern

The easiest way to spot the resistance of the frozen middle is in the organisation structures. The frozen middle suggest an intermediate step to the formation of teams as shown below.

The executive failureship cave in to their suggestion because any changes they want to happen either happen through them, or the failureship need to lead the teams to do something that some of them do not want to do. This structure reinforces the roles of the frozen middle failureship, retaining their power base, and prevents the need for the teams to step up and take responsibility. Project managers and “Greys” continue to allocate individuals to projects and nothing significant changes as the teams are not really acting as teams.

All that happens is a cosmetic change of the organisation hierarchy at the bottom of the organisation, possibly with the introduction of addition layers of management (more frozen middle)

I have experienced this failure to remove the frozen middle failureship in several organisations. Normally because executive failureship was either too scared of the frozen middle failureship or because they were not really committed to improvements in the organisation.

An alternative to this structure is the adoption of the SAFE framework with its roles that preserve the frozen middle failureship.

Dealing with the Frozen Middle Failureship.

Removing the frozen middle failureship roles does not necessarily mean removing the individuals from the organisation. Often the individuals in the frozen middle failureship are some of the most effective individuals in the organisation at doing things and getting things done.

It is important for individuals to choose a new role based on invitation rather than be assigned a new role. People who are assigned a new role will almost certainly continue to behave as they did in the old role. Asking a project manager to manage in an agile way will result in no change in behaviour.

This is likely to need an organisation wide change. If the technology group make this change but the “business change” group do not, it is likely that a rival organisation will emerge to manage the new way of working during the period of uncertainty and change. The leadership will need to build alliances across the organisation to shift the organisation from one controlled by the frozen middle failureship to one based on self discipline and teams with lightweight (Scrum of Scrum) coordination.

At one organisation the transformation started with the leader of the company sacking all forty project managers in one go. I joined shortly after and the stories told lead me to believe that sacking the project managers en-masse was a mistake. In that organisation, a healthy product owner organisation emerged that truly lead the development of the product based on customer focused metrics. The development teams took responsibility and pride in their work. We eventually re-introduced the project manager responsibilities as a scrum of scrum master responsible for facilitating cross team development, and with none of the power. It was one of the most impressive organisations I ever worked in.

At another organisation the project managers were given the choice of either becoming a developer, a scrum master or leaving the organisation. Combined with other changes, the result was a 50% increase in productivity.

Subsequently I have worked in several organisations where the frozen middle failureship was allowed to remain intact. The project managers played lip service to change, with agile theatre, and an appropriation of agile terminology but no change in behaviour, and no real improvement.

For many years I thought the wholesale sacking of the frozen middle or forcing them to chose between a new role or leaving damaged the organisation was wrong. I WAS WRONG. I now believe that any transformation that does not actively dismantle the power base of the frozen middle failureship is doomed to fail, It will simply introduce agile theater. The leaders in the two companies above were courageous in the changes they made but that is because they did the research and built their own experience rather simply rely on the recommendations of experts. They owned the changes and ensured their success.

Where do the frozen middle go?

As I mentioned, many of the individuals in the frozen middle failureship are brilliant. They just need to do a different role. They need to give up control of the allocation of work to individuals and making commitments on behalf of other people.

So what are the roles that they could move to?

The “Grey” role has many options due to their deep technical knowledge:

1. Product Owner – They could become a product owner who focuses on delivering value against technical business value metrics ( Performance, Lead Time, Through put, MTTR etc. ).
2. Lead Developer / Developer – Nuff said.
3. Chapter Lead – Line managers responsible for the development of other developers.
4. Architect – Trusted advisor to the product owners, writing technical user stories.

The project managers similarly have many options:

1. Product Owner – They often have the closest relationship with the customers.
2. Scrum Master – Nuff Said
3. Scrum of Scrum Master – More in a later post.
4. Developer
5. Chapter Lead for Scrum Masters

Most of the agile roles are based on facilitation rather than command and control. They require relationships that are adult-adult rather than parent-child. Some people find that idea scary and they may chose to leave the organisation for that reason, or for some other reason.

If your organisation claims to want to be team based, look at the structure of the teams and the behaviour of the middle management. If you see the anti-patterns mentioned above, know that it will be theater rather than genuine change.