Have the courage to be kind to those left behind

Face failure or fail

“Go agile, and your employees will be more happy.”

A common narrative leading to upcoming transformation is the attempt to define the leap as purely positive. Whether related to Agile, DevOps, New Work or some other change, potential pitfalls are usually addressed as a footnote at best - nobody wants to talk about those who won’t make the jump.

After all, by bringing up these pitfalls aren’t you in effect arguing against the very thing you are championing for in the first place? We say no. In fact, we are here to argue that it is important to talk about the risk of failure in order to avoid actual failure.

To illustrate this in practice, let’s use an analogy where you have to walk through a child’s dark room at night, and there are hard plastic toys all over the floor. Most of us will not stop to think about what will happen if we step on a sharp toy, scream (and probably curse) and end up waking the child.

But hoping nothing will go wrong doesn’t mean it won’t. Would it not be better to solve the problem by either briefly turning on the light or sweeping away the toys? After one painful stab into the foot, Boris’ parents wised up and always turned on the light. Your organization should do the same, and avoid painful disaster by addressing the problem head on.

Following the logic

There is not just one, but many pitfalls related to transformation. To reap the benefits while avoiding the pitfalls, it’s important to focus on the logic surrounding the details of transformation. Experience shows that ignoring one or just a few factors in something as complex as an organization filled with equally complex lifeforms can lead to a failed transformation.

Using a logic tree, let’s look at an example most of us are familiar with:

“Infrastructure is going to be at least as stable and secure as it was before we changed to cross functional teams.”

This paraphrased argument is at the center of agile transformations. A previous collective of backend developers, frontend developers, UX, operations and more is now just one team. We will look at Dev <-> Ops as an example.

Figure 1 shows the argument (the selling point) and some of the primary requirements that need to be true to make the argument itself true. The black arrows from the yellow boxes (the primary requirements) to the main argument indicate this.

In figure 2 we see orange dotted arrows going from the yellow boxes to a set of blue boxes with negative effects. These negative effects will come to pass if the primary requirements are not fulfilled. The Cross Functional Team (CFT) will quickly become aware they are not able to produce the same quality of work.

As we are in an industry where professional pride makes us strive for quality work, a team will likely make someone the new “Ops guy”, forming an even bigger bottleneck then a full team of Ops was before transformation. The new bottleneck will lead to sluggishness and demotivation, as the team is running into the exact same problems it was running into before. 

As a result, the quality of their work will take a dip, and transformation fails. A failure in one primary requirement can affect another, such as the inability to produce quality work leading to a decrease in willingness to adopt new methods.

Branching complexity

In figure 3 we see the secondary requirements - things that need to be true to validate the primary argument.

The critical success factors are the CFT developing a technical understanding of their new tasks, and their ability to get into a new mindset. As a rule of thumb, developers get measured by features and Ops get measured by SLAs. This difference in mindset cannot be taught in a single webinar, but takes time and patience.

Not helping the CFT to adopt a new mindset, or not giving them ways to get the required technical understanding will result in the team being unable to work properly and a failed transformation.

In figure 4 we see just a few more examples of primary and secondary requirements. This simple diagram gives a good idea of what needs to happen for the one basic argument to be true. Similar trees can be built for other arguments.

Trust issues

The requirements in the examples above have been quite general, so let’s consider a high-stakes transformation where one of the requirements is that nobody loses their jobs. If a worker has even a hint of mistrust in the validity of an argument for transformation, they can follow a simple line of logic (something engineers tend to be good at) and come to the conclusion that they may lose their jobs. No matter how nice the promise sounds, a perceived gap in logic or a belief that something is being withheld will lead to eroded trust and a failed transformation.

By directly and courageously talking about every part of the transformation, we can increase stakeholders’ understanding of it and subsequently build trust. When defined, addressed and spoken out loud, risks of failure become concrete and are easier to mitigate. Leaving the plastic toys on the floor and the lights off will only make the pain harder once you step on something. 

Key takeaways

Knowledge about the complexity of the logical chains and the requirements for transformation gives us three important insights:

1. By seeing its complexity, those in charge of the transformation get a better understanding of what needs to happen or maybe should have already happened.
2. It makes clear why some oppose the transformation. If workers perceive that change will decrease the quality of their work, they will oppose said change.
3. A lack of trust or understanding of any part of the logic chain can lead to failed transformation

Experience shows that every transformation, especially Agile and DevOps, has teams that fear they will be left behind. This blog post should give you an idea on how to be critical of your own arguments and whether you have created enough trust and understanding towards them. If not, be more open about the future, of both potential benefits and risks. This is your chance to lead an organization through a difficult period and come out stronger for it!

Finally, with courage and openness we can be kind to those left behind by:

1. Letting them know why the organization is moving on
2. Making sure they know everything was done to prevent them from being left behind
3. Making sure they felt like they were heard and their experience acknowledged

That is transformation with courage and kindness.