How the way we work slows down the work we do
I have expansive music tastes, but one genre that was never among my favorites was the late 70’s-early 80’s classic rock period. I do not mean punk, new wave or hard rock, but the mainstream rock from bands like REO Speedwagon and Bachman–Turner Overdrive.
There was one song though that got stuck in my head. It was “Takin’ Care of Business”. I think it’s the piano riff* that bored into my skull, but the song is the typical work life versus rock star life trope. The “9 to 5” crowd are chumps, while the rock stars live the good life. That being said, I think right now we are all longing to get back to the “9 to 5” routine.
Even in normal times, getting work done can be a major drag, particularly for developers. There are endless meetings, searching around for stuff, getting answers to questions, prodding others to respond to requests. It is no wonder that depending on which survey you refer to, developers only spend between 32% (The New Stack) to 50% (Infoworld) of their time writing code.

I read The Unicorn Project by Gene Kim this weekend which brings to light the struggles of many developers on enterprise technology teams. While it’s a work of fiction about a fictious company Parts Unlimited, it reads like the real life travails of many organizations.
The story follows a senior developer, Maxime Chambers, on her journey to make life a little bit better for her fellow developers. It begins with Maxime being demoted and sent to the troubled Phoenix Project, an epic disaster of a three year digital transformation initiative to turn around the fortunes of an ailing, laggard retailer.
Despite being sent to IT purgatory to “document’ stuff, she starts poking around as any curious problem solver would. What she finds would put the paperwork nightmare of Brazil to shame. Whereas the protagonist in Brazil is the bureaucratic Central Services, the morass at Parts Unlimited is one of their own making.
You know when process has gone wild when even the simplest task is impossible. Maxime spends over a week to get a Phoenix build to run on her dev machine. She only gets that far because she decided to take the initiative to file numerous tickets, track down helpdesk staff, bug Ops, and manually scrape together enough fragments of information, config files, and code repositories that she has a workable build.

What Maxime experiences is the “Waiting Place”. Even with mounting pressure, incredible stress, looming deadlines, and urgent situations, the entire organization is in a state of paralysis. In a “Waiting Place” work culture, there are only two groups. One group waits in vain for responses while the other group is triaging, routing, escalating, prioritizing, and closing work requests. It is like the movie Brazil, but in real life!
Waiting not only directly impacts productivity. It corrodes morale and increases opportunity costs due to missed higher value business investments. You are stuck fixing the busted up engine of your car, while another car whizzes by with a totally modern engine. That creaky engine is not just a metaphor for legacy technology and technical debt, but also the tangle of processes, the labyrinth of silos, and the divide between IT and the business.
When an organization has strong alignment of IT and business, that alignment closely follows the Five Ideals as discussed in The Unicorn Project:
The First Ideal — Locality and Simplicity
The Second Ideal — Focus, Flow, and Joy
The Third Ideal — Improvement of Daily Work
The Fourth Ideal — Psychological Safety
The Fifth Ideal — Customer Focus
A positive engineering culture that operates with high productivity and alignment of goals does not happen in a vacuum. This is the result of a tight partnership where business and IT are peers of each other working in tandem towards the same vision.
Parts Unlimited is anything but aligned. The most visible manifestation of dysfunction is a lack of attention to “how” work is done. In high performing cultures, as much focus is given to the improvement of work as there is to the work itself. The most common example of this is the Andon cord on the Toyota factory floors where any worker is encouraged to stop the line if they encounter a problem. While all five ideals are at work, the cord is a reminder that continuous improvement of daily work is a virtue.
How then can we build continuous improvement as a part of our work? Maxine joins a group of IT rebels that slowly builds a following and chips away at the corporate beast one step at a time. The key is that people have to be aware that change is possible and to experience the joy that comes with a new way of working.
There are numerous ideas to spark these moments of joy, the most obvious targets are places where developers get stuck in the Waiting Place. Based on observations from companies I have worked with and conversations with IT leaders, these are a few practical steps to battling the Waiting Place culture:
Building relationships — In a faceless bureaucracy, it is easy to ignore people. Maxine instead works the sneaker network and meets people to build empathy. The only way to influence people is when you can gain an mutual understanding, and that requires spending time to know people so that you can build up a trusted network that can support your change efforts.
Improving engagement — Communications is often the biggest cause of delays. Instead of humans, you are dealing with SLA’s and processes and approvals. This is what causes the “Square” where one manager escalates up, someone at top alerts a peer, the other manager passes the message, and only then does an engineer get an answer. Ticketing systems reinforce this wasteful path. Instead, rely upon messaging systems to allow instant communication within and across teams. Then you can slowly wean yourself off of the need to logging tickets.
Identifying expertise — Ticketing systems mask all sense of humanity. The support person that closed Maxine’s ticket for a dev environment was a jerk until she met Derek in person. Most organizations have lost track of who the real experts are as they have scaled, so it is hard to immediately get the right type of help. Having a directory of people with their skills and roles would be a start (every company has an HR system for this). A better way to naturally bring experts together however is to create Communities of Practice. These are like the Spotify “guilds” and they bring together people with common interests such as NoSQL or Go or Kubernetes. From these groups emerge leaders and subject matter experts that can then help anyone across the organization with questions in the messaging system or other places for collaborating across teams.
Automating environments — It was not until Maxine received a big binder of info that she was able to build for her own dev environment. Later she finds other hurdles like manual testing Ops processes, meaning code changes take several weeks to deploy. DevOps toolchains are the obvious answer here, but even more critical is that Developers, QA, Ops, and InfoSec are all on the same page on how best to automate the rules to ensure stable, resilient, compliant, and secure deploys.
Deciphering code — A massive codebase over time resembles Frankenstein because of the many languages, frameworks, methodologies, dependencies, and habits that build over time. Many of the wikis and Q&A systems meant to capture this information often fail because no one wants to write documentation. This is where AI enabled technologies can help. By building contextual understanding of code, developers can spend more time problem solving and writing better code than wrangling legacy spaghetti.
Some of these ideas flow into each other. Building relationships leads to more direct communications that avoid the ticketing system trap. With more open communications, experts become easier to find and brings people together to solve problems faster. But some of these can also be tactics independently tackled, such as better tooling to enable developers to focus on flow rather than friction.
When you observe the landscape of large IT transformations, it sometimes feels like 90% of them resemble Phoenix Projects. Without the discipline of the Five Ideals, alignment of business goals to software delivery performance is impossible. While the journey to enable culture change is a long and winding one, if you begin that journey by making continuous improvement of work as a core value, you can allow developers to escape the Waiting Room and focus on building valuable solutions for customers.
Have you read The Unicorn Project? If so, what did you identify most with? If not, what are some ways you might build continuous improvement as a practice on your team?
* There is a urban legend that the piano was added by a pizza delivery boy, but it was actually by a session musician, Norman Durkee, who laid down the track for $90.

Mark Birch on Failure, Learning & Taking Risks
Podcast | Perseverance Overrated | Digital Transformation and Leadership
Edit descriptionwww.perseveranceoverrated.com
This time I’m the guest on a podcast hosted by Deepthi Rajan. I share my philosophy around failure, learning, and taking risks. Please let me know what you think!

Check out past Heretechs podcast episodes on Apple Podcasts, Google Podcast, or wherever you listen to your favorite podcasts. Please like and subscribe 😁
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.