Dear leaders,
Many of you have invested much time and money in new ways of working in your organizations to empower autonomous teams either because you really understand the benefits they can gain in both the efficiency1 and value2 of the products they develop. Or because you’ve been under the influence by current trends or expensive consultants like McKinsey or alike, who are now also recommending modern product teams as the way to organize for future challenges. It’s been the same promises that’ve been made during the last three decades – since the birth of Agile.
You bought into the need for more business agility to be able to compete and saw a chance to find a path out of the heavy process that slowed down the organization. But many of you who have moved in this direction have also experienced that the promises made have been hard to fulfill and have not come without significant challenges.
You were also promised transparency, but for many it seems more like a glass floor through which they can observe the organization than insights they can use to understand and act upon. For example, they miss what we perceived as clear requirements and progress of projects in the old days. How did we end here?
We’ve all been surprised that following team empowerment, for example, comes resistance from the teams to the organization’s traditional line of command, i.e., the behaviors of leaders.
Suddenly, teams begin to
- question your strategy,
- find portfolio planning suboptimal,
- request or resist organizational changes,
- diverge from enterprise architecture
- refuse to accept deadlines,
- refuse to be measured,
- etc. etc.
When did that become a concern of theirs? That is how leaders control the organization!
Why are they not just delivering what they are supposed to? On time!
How did the leaders end up on a glass floor that prevent them from doing their job? They can see through it; They can see what is going on on the surface, but they cannot get a grip on it. It feels like I’ve lost control.
Did the leaders create the glass floor or did the teams?
If you’re one of those leaders with similar frustrations, you should read this article to understand what is happening. By understanding the other side of this challenge, you may be able to solve it! Because it will always be your accountability that the organization perform. If you’re not a leader yourself, you may use the insight to help your organization align expectations from both leadership and teams.
You must work through the glass floor to be able to move your organization from team-level agility to organizational business agility. Otherwise, you’ll be stuck with limited performance.
The team perspective.
Where you experience the issues mentioned above as a glass floor that the team perceivably won’t let you through, agile coaches/scrum masters have referred to this mismatch between leadership and teams with the metaphor of the agile glass ceiling for years. A ceiling that prevents them from interacting with the organization beyond the team.
It’s the same problem, the same glass plates, they see. It just looks different from the one below the glass. The organization below has radically changed the way they work, while they experience that the rest of the organization functions as before.
From their perspective, this misalignment between what you wish to achieve as a leader and their understanding of the organization and how it should operate originates from the fact that the teams have been asked to change ways of working, while the rest of the organization do not take into account the profoundness of the changes in the teams.
Teams see leaders who continue to operate as they did before changing teams ways of working. They struggle to align the empowerment of the teams with the unchanged leadership structure. You unknowingly do not live up to the promise of autonomy and empowerment. Your existing organizational operating system is not designed for empowered autonomous teams.
The organizational topics mentioned above are just a few where a misalignment exists above and below the glass ceiling/floor. Needless to say, this is suboptimal. It causes friction, and that costs money. I use friction here as loss from:
- misunderstandings in communication
- moving in different directions
- lost benefits from reuse
- endless discussions
- lowered motivation
- … and keep going
These different perspectives may not be new, but in traditional organizations, the leaders were, by definition, right when they decided, and the organization followed. However, this has changed: Empowering teams means that teams’ perspectives should be respected—to the degree that they are empowered to make many more decisions related to the value they create for users.
As long as they decide according to your directions, that’s usually no problem that teams make decisions. Nor is it when pressure on the organization is low: When competition is low, money is made, and customers are happy.
When this is not the case, it is your responsibility as a leader to ensure that the “stairs” function and that they do so in accordance with your promise of autonomy and empowerment. That requires that you change your behavior while leading and facilitating solutions that may have been unthinkable before.
Examples of misaligned perspectives
Let’s take a closer look at a few examples of situations from above where the perspectives of leaders and teams do not match:
Strategy from teams
Leaders mostly understand strategy as gaining more business, while teams focus on enabling users to do their work better. Both perspectives can easily be correct simultaneously since the better your product supports users; the more inclined users are to buy more. This attracts more users and improves the business (see illustration below). However, how to get there can be very different depending on who makes the detailed decisions.
To take a small example:
An insurance company wanted to increase the sales of extensions to basic policies. Therefore, a team was asked to build a web solution that successfully allowed customers to purchase extensions. However, the team went further in their pursuit of increasing sales. They went directly against company policy and conducted a limited experiment in which customers were allowed to deselect extensions as well—something that was against the existing strategy that disallowed that in fear of losing revenue.
A development team was changing corporate strategy!? How do you prevent them from using their autonomy to do so? In this case, everything went well. The experiment showed that sales doubled when customers were given the option to deselect again, while they only lost 10%. It shows the strengths of empowerment, but what if the experiment had failed? Would you enforce that the team only do what they are told, or should you work to align the strategic insight and decision-making in a new way so the different perspectives are not perceived like a separation of glass?
Organization structure from teams
Leaders change the organization to improve their chances of meeting their goals in revenue, cost cutting, employee satisfaction, technological progress, etc. It is only natural to try to meet the goals set for you. For leaders, restructuring the organization is one tool that they use to create focus on their most important goals. That perspective, however, does not always fit that of the teams.
This example is from a large financial data-center that was heavily impacted by a large regulation package from the European Union that needed to be implemented within a very tight deadline despite that the law text and guidelines were not nearly finished. The regulation hit almost every part of the many systems used by the banks that are their customers.
The consequences of not meeting regulations on time could be that the banks could loose the license to operate.
How to solve a task of this size and complexity within a tight deadline with large consequences if missed? Management in the data center and the banks – of course – started an analysis to form the project that could lift the task. They were thinking that they needed a project with 100% focus on this one task. Just like we all would’ve done.
But this organization had been through an agile transformation the previous years, and had succesfully implemented teams that felt a great ownership of their products and had established good relations to users in the banks.
When these teams learned that this big regulatory project was on its way, they also realized that they probably would be split up and new teams would be working on ‘their’ products – some with 100% focus on the regulatory project, others on the remaining roadmap, bug fixes etc. They realized that the learning cost in regard to the systems, the users etc would be extremely high.
Therefore they suggested to keep the product-oriented organisation they had already, and adjusted capacity within the product teams as needed when the task was better understood. So they held a few fullday workshops where they tried to understand the requirements and how they fit their individual products. They also identified shared ressources e.g. new data and agreed which teams would be responsible for these.
This of course did not remove the risk and severity of the task, but it showed that existing wellfunctioning teams could continue their flow of delivery without being split. As time went on it was also proven that the existing relationship between teams and users, helped to make compromises when the deadline required it and that other improvements from the roadmap could be delivered along side the critical regulatory functionality. The users were engaged and happy.
After what would be the end of a traditional project the approach suggested by teams also proved that getting ‘the last few things’ done was not an issue and most of all, there was not loss in handing over the new functionality, because these teams felt ownership before, during and after for their product.
This was a learning for the organization to search for solutions within the product-oriented organization before breaking everything up to form an effective project. Here was added a few people to support the continuous teams collaboration and communicate to management, customers and users in a coherent form. The task itself was understood and lifted by the teams, especially their Product Owners.
What would have happened if the teams had not been brave enough to suggest an alternative and the management had not trusted them – we’ll never know.
Corporate architecture from teams
As responsible leaders, we want all our teams to follow the defined corporate architecture. That allows for higher reuse, consistency for users, higher quality, higher agility, etc. Or that is at least the intent of enforcing the limitations of predefined boundaries on the teams.
Typically, we have dedicated enterprise architects who draw up the corporate architecture based on higher-level principles. They often consult expensive external specialists. Once the architecture has been decided, every team must adhere to those boundaries.
The teams’ challenge is that they often meet business/user requirements that were either not considered when the architecture was decided or that the enabling projects that should implement the technological change defined by the architecture were not prioritized. In either case, the teams must determine how their local architecture should be, as they have to deliver user outcomes.
The example I’d like to mention here is from a financial institution where many systems have been integrated into each other over the years in numerous projects. The corporate strategy was to shift to an enterprise service bus, which, in principle, would let everybody, by simple configuration, reuse any integration. It replaced the complexity in the architecture drawings of one-to-one integrations with a single box connected to any system. (see illustration below). It “just” required a project that rewrote all integrations. Needless to say, a project with no immediate business impact had a hard time getting prioritized.
As the organization reorganized into product teams, it became apparent that maintaining the existing integrations had become a time-consuming burden for the integration developers. They were supposed to develop new integrations in their teams, but they experienced again and again being the bottleneck for finishing that work. They had no capacity to implement the service bus. Still, they could, as a community of practice across teams, decide that every time that they had to change an integration, create new integrations, or to fix an old bug they had inherited, they made a little extra effort to remove individual solutions by extending the common base to improve error handling, operations, etc. They also improved documentation to ensure that everybody could maintain every integration. During the first quarter of the year, they had created the maintainability that the big integration bus project should have given.
The integration developers took responsibility for their teams’ poor situation and solved a problematic architecture—not the way leadership had agreed with the enterprise architects, but the way it was possible—when the enabling project was never prioritized. A lot of small decisions locally in empowered team behind the scenes solved a painful problem.
Where would they have been if the Product owners in the teams had not understood how their long term success was dependent on giving a little leeway to the integration developers? If they complained that they couldn’t deliver as promised to management instead?
Your responsibility
Common for the three examples above is that the team perspective was radically different from the traditional leadership perspective and that teams, sometimes, despite conflicting leadership directives, successfully can implement a change in strategy, organization, or architecture.
These are successful examples of teams breaking through the glass floor – or ceiling – and, over time, making a difference to the organization. Empowered teams took the chance to improve their conditions and deliver more value to their users.
However, not all examples of empowered teams going against corporate decisions end happily ever after. Surely not! And I do not intend to swing the pendulum completely to the other side.
As mentioned initially, I want to provide another perspective and inspire you to understand the power of including the employees near the complexity of business in these examples. These three organizations’ indeed have very complex user needs, organizations, and technologies.
I would claim that developing products is complex for any organization due to the size of organization, the problems that products solve, and the required technologies. The complexity is inherited, so it does not help to wish it was simpler or try to remove what from above the glass ceiling appears to be excessive complexity. It rarely is. The consequence of ignoring the complexity will be a loss of business opportunities.
The job of leadership isn’t to “reduce complexity” in the work itself but to create an environment where people can work effectively with complexity—where the right practices and boundaries reduce drag and make complex work fun, challenging, and productive3.
It should not be up to the teams themselves to take the initiative to create an organization like that, but they should be involved. The three examples above show that they can participate in solving some very complex tasks better.
In the end, it is your responsibility to build the organization for business success. Will you take on this challenge and embrace complexity with your teams?
Are you prepared to invest time in adapting the life on each side of the glass floor/ceiling to each other?
My next articles aims to spread more light on how you beyond the examples here can facilitate this as a leader.
—— THE END ——
- https://www.managecomplexity.dk/blog/2018/06/28/agile-is-organizational-re-design/
- https://www.managecomplexity.dk/blog/2024/03/12/three-decades-of-agile/
- this paragraph is from https://cutlefish.substack.com/p/tbm-321-reducing-complexity