The Structure and Process Fallacy

--

“If our teams were just organized in the right way, and we adopted the agile process, we’d be so much more efficient.”

What’s your feeling when reading that quote? Are you strongly in agreement, generally in agreement, or perhaps you’re shaking your head in disagreement?

The quote reflects a sentiment I notice from leaders in top-down, hierarchical organizations. A belief that if teams are organized in the optimal way and the right process is followed, the company will be high-performing, regardless of other factors. This is the structure and process fallacy.

In my experience, leaders with this mindset need to make almost a complete 180 before attempting to carry out any organizational restructurings. Because changing structure and process without addressing leadership, cultural and ways of working issues, usually exacerbates existing problems rather than improving performance.

This mindset is especially dangerous when combined with big reorgs. Gung-ho restructuring of an entire organization without addressing cultural issues is about as risky, and crazy, as it gets.

The Real Silver Bullet?

While this mechanical, factory-like, structure and process approach is seen as a silver bullet by traditionally-minded executives, if ever there was a silver bullet, the closest I have seen is more social: purpose, autonomy, and mastery. But even those things alone won’t suffice, organisational structure plays an important role (check out my recent talk collectively addressing these topics: Sustaining Fast Flow with Socio-Technical Thinking).

If you want to go fast, you need a codebase that can be easily modified. But without investment in strong technical practices that keep code healthy and evolvable, you will never be able to go fast, regardless of how teams are organized.

Likewise, the same mindset needs to be applied to infrastructure. Teams need to be able to build and deploy software very easily. No organisation structure can compensate for a poor Developer Experience.

Empowered teams are also more important than structure and process. Teams that are empowered to own their backlog and how they work are more productive, and figure out ways to address whatever problems they are facing — including structure and process issues.

If you plan on changing your organizational structure to improve productivity, I hope you will stop for a moment and consider addressing these fundamentals first, or alongside, your structural changes.

Start Small, Nail It, Then Scale It — Avoid Big Reorgs

When changing fundamental aspects of engineering and product culture, it takes time and iteration to establish them in the unique environment of every organization. As much as I advocate for autonomy, I’ve seen experienced teams stressed out by being given autonomy and not knowing what’s expected of them.

When you roll out big cultural changes as part of a big re-org, you risk creating this chaos across your entire organization all at the same time. Having seen the results of this, it’s not something I would ever want to put people through, and it’s more likely to reduce productivity than improve it.

For this reason, it nearly always makes sense to start small. Pick one or two areas of the business, identify new structures and cultural improvements, and give the team(s) time and support to adapt to the new ways of working.

Then, once verified that these approaches can work inside your unique organizational operating context, scale them out to larger areas of the organization while continuing to iterate and adapt.

Beyond the Structure and Process Fallacy

Unfortunately, the structure and process fallacy is often imposed on organizations by senior leadership. Trying to get these people to change some of their strongly-held beliefs is hard. Sometimes only a crisis is enough for them to reevaluate their beliefs.

On the positive side, there are large, traditional, top-down organizations that have switched from a factory-mindset to a socio-technical mindset. In my experience, a change of leadership has often been the catalyst, but I have also seen the power of evangelism and highlighting success tories. So I encourage you not to give up too early.

Do you have any experience of overcoming the structure and process fallacy? If so, please leave a comment and share your tips.

** Thanks to comments from Phil Ledgerwood and Rob Bowley on LinkedIn which helped me to clarify some of the points in this article.

--

--

Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)