Last year was exciting, it was my first time going to a DevOps Enterprise Summit and meeting Gene Kim was very cool. The conference didn’t actually start on Tuesday, there was a little session on Monday as people were trickling in from all over the world. And in said session, Gene presented his latest project. He was writing a book with Steven Spears called Wiring the Winning Organisation.

If I’m honest, I am not a fan of the title. Wiring an organisation sounds painful, and winning is just a bit too in your face for my adopted British sensibilities. And I found the subtitle even more puzzling: “Liberating Our Collective Greatness through Slowification, Simplification, and Amplification”. I guess the Americans have a penchant for liberation, but what the heck is “slowification”?

But having said this, I loved the Phoenix Project, was really taken in by Investments Unlimited, so I was quite excited when I was offered an advance copy of the latest DevOpus.

It was immediately obvious from the foreword by a former US Navy Chief of Naval Operations and the ringing endorsements preceding the book that this was going to be interesting. And at more than 300 pages, it was packed with information.

So what is it about?

Gene and Steven want to take organisations from the “danger zone” to the “winning zone”. They identify three different layers where value is created:

• Layer 1 is concerned about the technical objects being worked on, so the software, the gizmo, the product or your app.
• Layer 2 encompasses the tooling needed for creating Layer 1 objects.
• Layer 3 is about the “social circuitry” - the processes, the procedures, the collaboration between people to work on Layers 1 and 2.

Now, this idea of “social” as an important part of development immediately struck a chord with me. I’ve long advocated a bastardisation of the “80:20 rule”: Software engineering is 80% social and only 20% technical. That’s not just because I’m stuck in meetings all day these days! But when thinking about work of a developer, the typing in of code at the keyboard or the number of lines of code created per day is almost never a good indication as to whether someone is a good developer.

Gene and Steven cleverly introduce their ideas by the way a vignette. Yes, I had to look that up, for me vignettes were stickers that you put on your car to pay for the Austrian Autobahn, but according to the dictionary it is a smart, evocative description. And I think it was really smart. The vignette was about Gene and Steven organising movers and painters to redecorate a hotel:

They start out with the obvious: they become project managers and micromanage the movers and painters to the rooms. Very quickly chaos ensues as they don’t know how to best utilise the skills and the people doing the actual work get blocked very quickly and Gene and Steven become overwhelmed as everyone is waiting for them to schedule resources.

People are not resources!

They quickly realise how wasteful this is. Rather than telling people what to do, they quickly realise that they shouldn’t tell experts how to do their job but should rather listen to their advice and set the right conditions for the movers and painters to succeed.

This is achieved by introducing the concepts:

• slowification of the environment in which the problem-solving occurs to make problem-solving easier;
• simplification of products, processes, and systems through the use of modularization, incrementalization, and linearization to make the problems themselves easier; and
• amplification to make it more obvious that problems are occurring so they can be seen and solved.

In the vignette, the works are organised into independent teams of movers and painters that tackle different rooms. This simplifies the collaboration. Gene and Steven can focus on troubleshooting. Interestingly, troubleshooting does not mean pulling workers from one team to the next as this just moves bottlenecks, but to ensure that difficult problems (how to move that piano or how to paint that ornate door frame) are thought about ahead of time, ensuring that there is sufficient time for experimentation and maybe keeping some people in reserve so that they can help out if a team hits difficulties.

A lot of these techniques will be well recognisable to people working in environments where agile is done right. And indeed, the sources for Wiring the Winning Organisation comes from agile, the Toyota Production System, lean, systems thinking and many, many more influences. It is really quite interesting how Steven and Gene have managed to work from the simple vignette, to introduce a really complex theory which they then explained over and over again by the way of case studies as varied as the Apollo 11 space programme, two-pizza teams and Amazon and the Boston marathon bombing.

Slowification

I was triggered by this invented the word. A footnote mentioned that

Interestingly, the Germans do have a word for slowification: verbesserung, emphasizing improvement through slowing down.

Personally, I think even though I’ve not lived in my native Austria for nearly 30 years, I still think I know enough German to consider that Verbesserung is just improvement and not related to slowing down. Though if intentional, this makes for an excellent joke on the idea that there’s a German word for everything.

The idea behind slowification is that instead of having to make decisions in the heat of the moment - when there is no time to think - that preparation, planning and deliberate thinking can be used to make the right calls. The book illustrates this by referencing the moon landing, where Armstrong and Aldrin encountered boulders on the landing site which could have led to aborting the mission but an alternate landing site and endless simulator runs allowed them to land safely.

I think this idea is really important. If we don’t set the right environment where improvements can be made, if we don’t allow ourselves time to think, then we’re more likely to fail.

Simplification

To put simply, the idea of simplification is that complexity is bad. As an experienced developer, I’ve long known that Keep It Simple, Stupid (KISS) is one of the most powerful principles in software engineering. No matter how clever you think you are, complex code never will be as quick and maintainable as simple code.

Keeping it simple can be achieved by keeping tasks small and self-contained, ensuring that they can be done with as little dependency as possible, and we do them in small steps. It is amazing how easy this sounds, but try explaining that to a project manager that wants to know the milestones for the whole project!

Amplification

So, we’ve slowed down and we’ve simplified. But that is not enough. We also need to set the conditions that make it possible for people to warn us when things are going wrong. I’ve been a fan of the idea of psychological safety ever since I first encountered it. Leaders must set the conditions where it is encouraged for people to point out possible problems. A Muskian sense of “say the wrong thing and you’re fired” does not help anyone.

The Important Appendix

One of my favourite bits in the book is Appendix B which discusses the differences between transactional and developmental leadership. On the one hand, transactional leadership is the idea that leaders intervene and change course, they are the ones that direct their underlings and decide what has to happen next. On the other hand, developmental leadership is all about setting the right conditions so that people can develop. Instead of asking “what can we do with our limited resources?” a better question might be “how can we do more?”.

Conclusion

I thoroughly recommend reading Gene and Steven’s book. I don’t think it is the easiest read, but it introduces some very important concepts. And while it is a bit counter-intuitive that great leadership is about not making all the decisions, I think this book makes the point really well!

Tags my-take-on agile book-review

If you'd like to find more of my writing, why not follow me on Bluesky or Mastodon?