I vividly remember my years as a waterfall project manager. I was earnestly doing the best I could, but in hindsight, I can see how I sometimes failed miserably. One of these disasters is a great example of bad ivory tower behaviour.
The goal of the project was to repair a financial regulation issue. I had an architect who designed a high-level solution. After careful review, the solution was approved. Then a senior software engineer created the detailed solution. 4 months in, once this was also reviewed and approved, I asked the development team to create the solution.
To my big surprise, the development team said “Don’t bother. We already deployed our solution 2 months ago. We quickly found a way that we thought would work and it indeed proved to be the case. You burned all these hours for nothing. We informed your architect, but he ignored us.”
Now, you would expect the leaders to be happy. We needed to solve a regulation issue and the development team did this quickly and effectively. But no, they told the development team to work on the architect’s solution instead. Only he was allowed to propose changes to the system. His way was the only way.
This truly happened! That development team never forgave me for my inaction. I could have defended then and I didn’t do this. It was the next straw on the camel’s back, which was about to break.
I learned my lesson and embraced agility. So did the organization I worked for. But many organizations still have people who sit in their ivory towers. In this article, I will discuss how terrible this is.
It creates animosity
When an organization has different teams with entirely different objectives, they will bump heads. In my introduction, the architect and senior software engineer had the objective to do a thorough analysis and create a solution document that then needed to be reviewed and approved. In their minds, they did everything required to have a solid solution for the problem.
The organization labelled the architect and senior software engineer as the experts. They had the responsibility to solve the regulation issue. In their understanding, the development team had to work with what they built.
The development team, however, used Scrum. They had the goal of quickly and effectively finding ways to address the most important topics. Top of their list was the regulation issue. So they worked on it immediately. They had informed the architect, but he felt the development team went out of line.
In the end, we had two camps that couldn’t stand each other. Both felt mistreated by the other. Whenever people have different and perhaps even opposing goals, animosity creeps in. The frustration of being ignored or impeded by others is a recipe for animosity.
It blocks collaboration
To be effective value creators in today’s world, people need to collaborate. The architect and senior software engineer would have been more successful if they had engaged with the development team. While doing so, they would be able to align quickly and effectively. In this case, they would have concluded that their engagement could be minimal. They could act as reviewers of the team’s work, which would allow them to spend their time on other topics.
Sadly, both the architect and the senior software engineer stayed in their ivory tower. They expected they only needed to throw the solution over the wall. By doing so, they missed the opportunity to save the organization a lot of money.
In my years as an Agile Coach, I have witnessed many situations similar to my experience. Often this had to do with how Agile approaches were introduced and used. By limiting Agile to the development teams and ignoring the roles of people outside of the team, the rest of the organization kept on working as they did. I have seen all kinds of teams being cut off from communication, like marketing, sales, architects, finance, approval boards, risk management, security, and IT ops.
It breaks the learning loop and value creation
In an ever-changing product world, it is vital to quickly understand what brings value and what doesn’t. Teams need to learn fast. But when people in an ivory tower block the progress, the learning loop can break.
These days, organizations don’t have the luxury trio to spend months creating to perfect solution through thorough analysis and rigid approval rounds. It all is potentially wasted time, effort and money when the idea proves to be rejected by the users.
It always baffles me when organizations want to make the Agile teams more and more efficient while the actual waste is outside of the teams. There’s so much more to win by critically looking at those processes.
As soon as you break the feedback loop, you hinder value creation. You could be working on ideas for months on end, only to conclude that all the effort is wasted. The experience I shared in the introduction was even worse. Here a perfectly valid solution was abandoned because a team “crossed the line” and “ignored mandatory procedures”. While this was not what happened, they followed all the necessary steps. The truth was: that the architect and senior software developer flexed their muscles.
Step down from the ivory tower and collaborate
Any organization that wants to learn and adapt quickly to be on top of the game in an ever-changing world needs to remove the ivory towers. Everyone involved in the value creation needs to be aligned. They need to work towards the same objectives and understand how they can collaborate to add value.
An architect or senior software developer can perfectly add value by being close to the team or even being part of the team. They can consult, they can review, or they can help create the solution.
People from marketing, sales, security, and finance can play an active role in reviewing the items the team created and collaborating on what to do next.
There are many ways to organize around a product. You might want to start here.
As long as you assume that silos are an effective way of organizing work, software development is an easy target for blame because it is abstract and hard to understand.