The initial context:
This story took place in a European fintech in 2022.
This story is told anonymously from the perspective of an organizational consultant. The first draft version of Org Topologies™ was not yet launched when this mission started. Org Topologies™ was introduced to the company at the very end of the mission. This case study is a story about how Org Topologies™ contributed to improved awareness of needed changes to org design and ideas on how to move the change forward.
This case study also illustrates what the contribution of OT was to moving the change forward.
Some of the initial wishes for improvement, as expressed by the company, when the consultant was engaged:
Become an even more customer-oriented org
Be a leading tech-/ product organization with a focus on continuous learning and insight
New ways of working, e.g. common principles and processes.
As stated by the company: “The org shall be founded on empowered teams who set clear directions for their* products based on the overarching strategic direction and vision for the org as a whole.” Changes to the org design were initially not a mandate
(*to be commented further down)
In Org Topologies™, the wishes would map like this:
Characteristics of the org context before the OT introduction
The company was a merger of two companies. Two different B2B products. Two different contexts for providing value. Both legacy products were well-positioned in their respective markets. One product targeted at companies in need of a payment solution. The other product focused on companies in need of highly trusted user authentication.
The company was strongly demanded to keep the lights on, 24/7, for their legacy services. Outages would cause severe impacts for the users. Some argued that the high-quality demands required them to keep a traditional organizational design compliant with established methodologies- and handover processes. Their good market position depended on two things:
Being highly trusted for their quality and safety.
Staying at the very front in their competitive market.
Point 2 was causing a strong need to continuously improve the user experience without losing track of point 1.
A part of the company came from a power- and rule-oriented org culture. That culture included a quite monumental project methodology. Comprehensive processes and task handoffs between units and single-skill specialized people were dominating. Some processes were argued as unalterable due to laws and industry regulations.
Other parts of the company consisted of people whose background was dominated by more agile approaches to product development.
Overarching org design:
High-level illustration of the company. 15 groups/ teams + sales- and admin units like HR, Marketing/PR, Legal, Internal office services, and support. Approx. 200 people in the whole company.
The pre- Org Topologies™ period:
The consultant built a broad in-company network including people from different units- and hierarchical levels of the organization. The outcome of this was a better understanding of the status quo.
Despite this, it was a complex matter of understanding the whole product at a full-picture level. Different go-to persons could sketch parts of the full picture. Access to these go-to persons was limited due to their very tight schedules and their priority towards burning operational matters.
Here is a snapshot of some of the consultant's notes from this period:
Talking about organizational design is a sticky matter. Kind of a taboo for some.
The high amount of product components. The company calls these components products. When they initially expressed a wish to found the company on empowered teams who set clear directions for their* products, they meant such different components.
Almost every product component has a manager whose roles are named things like Product Owner, Product Manager, Technical Product Owner, Business Product Owner, etc. No common understanding of what these different role names mean in their context.
Some teams include both roles such as “PO”, Project Manager and Tech lead
The high degree of single specialist positions (heard: “it's not in my job-description”)
Several of the teams experience blocking dependencies versus other teams. Waiting for other teams, followed by “fighting” for priority in other teams’ backlogs.
UX/ UI is organized as a specific unit. Sometimes they hand over their stuff for implementation by developers within teams. (some “PO's” and other higher-in-the-hierarchy people from the teams are actively involved in using their mental faculties to understand, learn, or solve problems. And making decisions. Other “PO's” are treated more as order-takers expected to execute design, architecture and specifically described functionality by UX/UI and more senior product -roles).
Separate department for testers (Y1 group)
Separate operations department (acting as Y0 individuals)
Three teams are quite empowered with broad skill sets within the team. Two of them are given responsibility for value stream parts of the product. (A2). One of them has a complete skillset to create the whole feature by the people within the team (A2)
One team calls them a Scrum team, though the people within the team are directed by a project manager titled as Scrum Master. Single-task-single-person orientation within the group. Lacking a common goal for the sprints. (Y1)
The largest team (The new app team, 15+ persons) includes some people who are very inspired by the approaches suggested in the book named Empowered and other things they call “the product literature”. Others in this team are inspired by Scrum and some practices articulated as agile. Seems to be an ongoing conflict based on arguments that redefine the Scrum definition.
Several of the people in the New app team feel like order takers of tasks given to them. (Y2) One of the team members reached out to me to share concerns about lack of structure, motivation, and sometimes chaotic scenarios where important stuff falls through the cracks.
Hard to establish a company-wide common language. A significant amount of people have strong opinions of what agile is - or not is. Some perceive the ingredients of agile as binary things - i.e. either autonomous or not. The original content and intentions articulated as agile often have been redefined or diminished. Some developers have really bad connotations of the word agile. One of the developers said: “those agile people who came up with the idea of estimations should personally go say sorry to all the developers in the world. The estimations demanded in agile methods have caused so much pain and hurt people badly”. (Diving deeper throughout that conversation, it turned out this person had been exposed to people who used practices associated with agile but done in ways causing scapegoating and time-consuming no-value overhead.)
Why the consultant introduced Org Topologies™ to the company:
The consultant shared his list of observations with his mentor when they met in October 2022.
He also shared how he felt a need to help the company see the characteristics of different parts of the org with an objective, non-judgemental, and agnostic approach.
The mentor pointed him to a very early draft version of Org Topologies™. He found the following potentially useful:
structured way to articulate, and help the company see, the different levels of team autonomy in terms of completeness of skills within the team. (At that time, there was an ongoing discussion about team autonomy. Binary, - like yes or no)
Help the company become aware of how its org design is dominated by component thinking rather than the whole product.
A more neutral language to avoid words like i.e: agile, waterfall, lean, scrum, empowered teams, and product thinking. (These words had turned out to be disturbing for constructive reflections about org design.)
A way to help people connect better to a common direction for transformational efforts.
As Org Topologies™ emphasized adaptiveness as optimizing goal, it fitted another important learning during this mission:
After a 1:1 chat with the CEO, the consultant noted:
“I connected the word agile with the organization’s ability to respond to changes. We reflected together on how affected the company actually is by frequent changes in everything from laws and regulations to customer needs, competitors' offerings, new tech, dying tech, etc, etc. With high enthusiasm, the CEO stated that: “It's not enough that the employees accept that we need to respond to changes frequently. They really need to EMBRACE CHANGES!”
The consultant understood Org Topologies™ as a tool supporting the communication of this.
The introduction of Org Topologies™ to the company:
The consultant shared the information on Org Topologies™ with some people in the leader group and his network within the company. At this time the materials consisted of the OT website, a download, and a recording from a conference.
The consultant felt that Org Topologies™ made it easier to communicate and help them own the following awareness:
The company's initial perspective that each of the teams owned their product was replaced by a slightly increasing whole-product (whole business) perspective.
With the more holistic product perspective, it also became clear that product prioritizations needed to be done at a more holistic level.
They concluded that a person placed at leadership level 2 in the org in reality was acting as the product owner.
They started reflections on how to optimize their organizational design towards an ideal where they were in a better position to embrace changes.
Key stakeholders started talking to each other in new ways: I.e “That department is obviously a Y0 / Y1”, “I don't think the C3 level is realistic, but maybe we can reorg team X, Y, Z and start optimise them more in the direction of B2/ B3”.
The org scan based on their status quo, Nov 2022:
(This org scan is done in retrospect almost a year after the verbal assessment done in Nov 2022. Might not be accurate, but made to illustrate the essence)
Using Org Topologies™ for a brief assessment one year later
As mentioned, the introduction of Org Topologies™ happened at the very end of the consultancy mission. If the timeline was stopped there, the consultant's experience report would be that it felt helpful for communication and awareness.
October 2023:
A brief assessment was done with two of the transformational enthusiasts in the company.
Some of the highlights as perceived by those:
1. Overall, more talk about the holistic product perspective. “I feel that we have lifted the perspective. We used to have long discussions concerning the task-level. Not so much of that any more”.
2. The New app team used to be a hotspot. The other teams used to have a lot of dependencies on what happened there. This has changed now. Their org design has changed. They are now divided into smaller collaborating teams and the dependencies are reduced significantly. Teams coordinate more directly with each other.
3. The Forgotten PW team has moved vertically towards a more product-part focus. (Now named onboarding and issuance)This includes a more holistic customer-centric perspective. The PO now influences the org to apply organizational development as a tool to get more value. He knows where he is going.
The team had also heightened their focus on necessary multi-learning while ascending on the Y-axis. The vertical indicators were reflected in an expansion of the team's scope of work, and there was a deepening of their overall product understanding. The team had been proficient at engaging with customers. Subsequently, they reduced the distance to an even broader segment of the customer base.
Observable growth indicators in this team:
The red arrow illustrates that the team reduced the distance to customers by having more direct dialogue with them. The team's focus moved toward a more holistic part of the product (onboarding and self-service admin where reset PW is just one of the features). As the team fixed the burning matters that were the reason for establishing a "forgotten PW team" the focus- and the team's scope of work matured in a more holistic direction. The same people stayed in the team and they learned new skills, increasingly building a broader product understanding.
The "forgotten PW" feature was still a part of their responsibility, but no longer their only focus.
The green arrows illustrate that the org involved them, and shared more of the holistic customer domain. The team's scope of work increased to a more holistic perspective. The people in the team were motivated by this. The team members in this team are forward thinkers and feel that they can provide more value for the company by having a more holistic perspective on what they are creating.
4. The Biometrical R&D team has increased their multi-learning capability even more by exploration of the whole product. They are moving towards a broader understanding of the core, serving as an engine for the whole product. They have started to simplify by building elements from the core component in ways that reduce the dependency on that component team. Increasingly becoming more capable of solving whole product needs.
Observable growth indicators in this team:
The red arrow illustrates that the team reduced the amount of blocking cross-team dependencies by learning more about the functionality that a legacy platform team owns. This team can now go faster and doesn`t need to wait anymore. The reason is that they have learned how to create a broader scope of functionality in their own code-base. Done by multi-learning. The team identified highly frequent reciprocal dependencies and developed their skills to deal with those within the team. Leaving the team with only some pooled dependencies. The functionality is replaced in the code base accessible by this team, and they can not go faster without waiting out the more rigid processes as they did.
The green arrows illustrate that the team has grown more complete in regard to their skills. The focus on multi-learning moved them from A2 to A3. Though they are still not B they are more "B-ready”. This team could probably be a catalyst for a change towards B for all the teams involved in this product part.
Conclusion
The introduction of Org Topologies™ helped communicate and reason about the status quo. It supported the consultant’s efforts to create awareness of blockers/ delays caused by the narrow scope of work in several of the company's organizational building blocks.
There are some signs indicating that this awareness led to, or at least contributed to, changes in organizational design optimizing for better flow and increased adaptiveness in product development. In Org Topologies™ terms; contributions to reduced transaction costs and switching costs.
