TL;DR
This article analyses the transformation of a major bank with org topologies. To understand this article, you first need to know about Org Topologies™.
Summary of the transformation analysis:
An organizational design can be implemented iteratively and incrementally. There is no need for "first time right". There is a need for an opportunity to learn the new design by experiencing it. Org topologies helps to implement organizational change in a structured and controlled manner.
A shared transformation goal is necessary to achieve good results. Org Topologies™ helps to define a visionary overarching perfection goal enabling everyone to understand the underlying principles.
Employees need to be able to make autonomous decisions that will contribute to achieving the perfection goal. Org Topologies is an enabler to place the mandate for continuous improvement of org design in the hands of the employees, low in the organization.
If the org design perfection goal is too ambitious, it will jeopardize the transformation. "Too ambitious" happens when people reject the goal. Therefore, combine an unambiguous perfection goal with transformation sub-goals and use them as "Stepping stones" towards perfection.
Mapping and naming intermediate sub-goals create a clear picture of the maturity-level, relative to the overarching perfection goal. This allows parts of the organization to work on improvements that are most important for their context and provides an objective way to monitor progress.
The success of each step in a transformation journey depends in large part on the extent to which employees (team members and management) can take ownership of the change. The unambiguous vocabulary and transparency provided by Org Topologies™ helps achieve this.
The transformation
This transformation was rolled out bank-wide: About 3,000 people faced a change of work, a change of team, and/or a change of way of working in early 2022. Preparations for this took about a year and a half. The entire organization "flipped" to the new model in one go in March 2022.
My role in this transformation was to "nudge" the organizational design with LeSS principles. The target model became a home-brewed mix of Team Topologies and LeSS. The main changes were: unified governance, continuous improvement, mandate low in the organization, and separation of the WHAT and the HOW. For the latter, the organization was split into a part for producing products and services (the WHAT) and for provisioning knowledge for it (HOW). In this paper, I focus only on the product development organization (the WHAT).
Iterating on an initial design
I observe in larger organizations that quite some time is spent on designing the future organizational blueprint. That's because changing the organizational structure is complex and risky. When the design phase is over, it is implemented with a big bang. The big bang approach creates clarity and reduces costs because no temporary structures need to be rigged to support a hybrid situation. A disadvantage is that it can create chaos because everything is suddenly different. Agile people like the clarity of the big bang. But we don't like a separate design phase. These two concepts can be combined by creating an initial organizational blueprint and releasing it on a flip date. We assume the initial blueprint is good enough, but not perfect and probably incomplete. After the initial release, we start iterating by applying smaller changes incrementally. This allows us to grow toward perfection guided by feedback loops.
For such an approach to work, everyone needs to clearly understand that the implemented model is a starting point or a step of a journey. Also, everyone needs to be able to assess what are good and not-so-good adjustments to the model. Org Topologies™ is invaluable here because it visualizes the current position, the first step, and the perfection goal, allowing the continuous change to be kept "on track" by the employees themselves.
Transformation goal: Uniformity
The overarching perfection goal of the new organization was B3. In addition to that perfection goal, first steps towards that greater goal were proposed in the initial design. That first step was implemented bank-wide in early March and had a different design for each value area (called "Hub"). The design of the 15 new value areas on the flip date was not one single archetype but a mix of archetypes depending on the context within the value area.
This meant that in all Hubs, the Y0/Y1 archetype was dissolved and replaced by:
A2 archetypes (teams with their own Backlog and PO).
One or more B2 types (1 PO, 1 PBL with two to six teams).
Some B3 (fully end-to-end) value areas.
Achieving the more perfect archetypes has more and different challenges and implementation involves a higher degree of uncertainty. Somehow it made sense to migrate in a controlled way instead of creating the utmost chaos everywhere in the company.
Despite each value area (Hub) having its own implementation of various archetypes, there is uniformity. In a transformation of this size, there is no "one size fits all" precisely because the starting positions are heterogeneous. Uniformity should not be sought in "everything is set up the same", but rather by:
the unambiguous basic principles of the model,
the formalized communication structures,
the shared understanding and transparency about the journey.
I believe we would have succeeded in this better and more easily if we'd had Org Topologies™ at our disposal.
Language is important for ownership of the future model
I visited many business units in the preparatory phase towards the flip date. One thing that struck me was that knowledge about the envisaged model and its underlying principles was insufficiently known by employees. And without understanding, no acceptance and hence no ownership of the new model is possible. The model did contain a new, common vocabulary, but we did not succeed very well in sharing it across the organization. Somewhere something went wrong in the communication from the Transformation Office to the shop floor. The reason: Indirect communication from the heart of the transformation passed on via insufficiently informed management layers to the employees. This resulted in a range of differences in the interpretation of the content and operation of the new organizational model. Having a common vocabulary is an aspect that is offered by Org Topologies™. Moreover, that vocabulary is not company-specific, which allows comparison between companies.
Reporting on progress
Progress reporting is always asked for and this bank was no exception. The transformation had been cut into phases and metrics were needed especially for the roll-out phase. Unfortunately, spreadsheets with tick lists were used. The agile coaches were instructed to get the lists ticked off on time. You will see this did not lead to understanding and ownership of the transformation but generated a lot of resistance. Moreover, it did not provide a transparent picture of our actual state.
The Org topologies™ model offers a powerful and transparent solution. The model helps to describe the current situation and the change ambition per value area in archetypes to be implemented. The result is measurable by the decrease in the number of teams per PO/PBL (vertical axis) and the decrease in technical dependencies (horizontal axis).
Some examples
The overarching perfection goal for the future organization was B3. But planning and execution turned out to be two completely different things. I will use some examples to explain the movements of the organization at the bank. I will use the Org Topologies™ archetypes to show that things were less messy than they might seem at first glance.
The bank was extremely heterogeneous before the transformation. It was a classic top-down driven organization, split into Business and IT. On the Business side, I mainly saw the Y0 archetype: departments surrounded by a matrix structure for projects and initiatives and programs led by steering committees. A single department was of the A2 type (feature-focused interdependent teams, reasonably functioning SAFe). This was the bank's flagship department. In IT, it was mainly Y1 archetypes: Component teams with task-level backlogs (poorly functioning SAFe).
Example 1: The situation at HR, archetype Y0
HR was not working agile yet, just like the vast majority of the organization. Although the department leads themselves thought otherwise. They translated being Agile into "working demand-driven". HR was of the Y0 archetype. The department managers distributed the work in their Management Team meetings, called "MTs". I found that they often were in those MT meetings. The meetings lasted long, often a whole day. The managers discussed the various projects and priorities and split the work into tasks. These tasks were then assigned to the "usual suspects", which are the people who already have knowledge and experience of the required topic or technology. They also included available capacity in the allocation without involving the employees themselves. Then ad-hoc teams were set up to do the work. Those teams were tasked with carrying out the work and reporting on progress. Employees were usually in several teams at the same time and had to do "regular work" too.
This way of managing product development is characterized by external coordination, external decomposition of the work, hand-offs, and extreme specialization. It leads to high workloads for both management and employees. The HR director asked me to help make their work process "more agile". My idea was to try to bring this Y0 to a B2, i.e. 1 backlog for HR with the HR director as PO. However, the HR managers were not ready for this. They proposed A2: a separate backlog for each manager with responsibility for a particular journey (employee life cycle, recruitment, healthy and fit, ...). To get used to working in Sprints with fixed teams, I thought this was a good enough starting point. I foresaw that due to the dependencies between the journeys and the micro-management of the managers, this setup would lead to new problems for which the next step to B2 could become a realistic option. There was a danger in maintaining the existing management structure alongside the introduction of component-team Scrum. I foresaw that this would lead to dumping the Scrum experiment again. My approach was to dismantle the existing pattern in service of the org change. After all, the long MT meetings were a bottleneck that needed to be resolved. We started the movement towards A2 by removing activities from the MT meeting. We delegated them to the Scrum teams, except the Sprint Review. A joint Sprint Review was a logical start to grow towards B2, where the Sprint Review is a central event for the entire value area.
Example 2: In the IT teams, Y1 archetypes
The IT department consisted of specialized component teams. There is a huge variety of tools, applications, products, and systems in use. And they had not yet succeeded in simplifying the architecture and infrastructure. The core banking systems, for example, are old and very specific. It makes no sense and the risk is high for all teams to learn these systems. For these environments, the choice was made to stay in Y1. In Team topology terminology, these would be called "Complicated subsystem teams".
Other IT teams with more common technology (such as Pega), were merged with business specialists into cross-functional teams. These were mostly A2 archetype teams. They could not deliver a full end-to-end product. In the preparatory phase, significant architecture changes were implemented to reduce dependencies between value areas and CI-CD, and provisioning (AWS) low-code/no-code solutions were devised to get the teams more towards the 2 and 3 columns of the Org Topologies map. Here and there, a single A3 or B2 area could also be formed.
Example 3: Mortgages and business banking, from Y1 to A2/A3 and B2/B3
The bank's flagship branch was Mortgages. They delivered faster and were better organized compared to the rest of the bank. This was because, as a forerunner, they had moved away from the standard Y0 archetype. They had moved to the Y1 archetype with the introduction of SAFe. The dynamics that prevailed here will seem familiar to you: Days of planning events focused on coordinating dependencies, low predictability of delivering customer value, lots of handoffs, frustration, and sense of powerlessness among the teams, and lack of learning by the group as a whole. This area did have a few exceptional teams doing "reasonable" SAFe. These A2 teams delivered specific front-ends with minimal dependencies on the back-end systems.
The Mortgages value area implemented the SAFe framework because it provides clear guidance for scaling cross-team coordination. I remember the conversation I had with the Director of Mortgages about this. After seeing the B3 archetype (one consolidated backlog per area, end-to-end cross-functional teams) and the routes leading there, he realized that institutionalizing coordination is precisely the limitation of the SAFe model. He saw that SAFe does not focus on solving the root causes of the coordination need. Instead, SAFe keeps specialized component teams (horizontal axis of the Org Topology map) with narrow domain knowledge (vertical axis) intact. His insight was reinforced by his experience with their very best teams; after all, they were already at A2 level in that they fully knew their domain and had virtually no technical dependencies with the rest of the organization.
Some consultants might argue that the above result is not a successful transformation because of the presence of Y1 and A-archetypes. I agree that migrating to an A-type is in general not a good option because it offers too few advantages over the Y-types. I share the view that migrating to a B-type archetype is better because the key de-scaling concept of multiple teams with one backlog adds substantial value. Some say A-types should be avoided because the concept of a single backlog per team is difficult to roll back once implemented. I think we should not be afraid to allow A-types in larger organizations if they are a step toward perfection. I consider A-types bad when they are an end-state. In larger organizations we need to make a trade-off decision: Do we force B-level as the minimum (consulting) or do we allow less adaptive archetypes and let the customer find their own meandering path (coaching)? In large transformations (hundreds of employees), I see the benefits of A-types being set up alongside B-archetypes as an intermediate step toward perfection. In smaller organizations (up to 50 people), A-types are not a sensible option, implementing B2 is not the biggest success and a C3 is the best achievable result.
Using Org Topologies™, we focus on a journey with a clear perfection goal and we have a good tool in hand to monitor and drive change towards an unambiguous perfection goal.
Conclusions
Org topologies™ provides support in a number of areas that can improve the journey of continuous organizational design adaptation:
Structure of and control over the change process
Meaningful progress monitoring (can be used as a maturity model)
Transparency about the shared transformation goal
Ownership of the transformation by the employees
Controlled context-dependent variations of the organizational design
Improved communication through unambiguous language
(C) 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™.
This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.
