ORG TOPOLOGIES 

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. 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. Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by Steinar provides great examples of what we now call Elevating Katas . Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Elevating Katas Identified (Deep Improvements Only): Adopting a Whole-Product Perspective Repeatedly mapping and reevaluating team scopes from isolated components toward broader product domains. Over time, this sustained focus on holistic ownership helps teams better understand end-to-end customer needs, reducing fragmentation and dependency. Expanding Multi-Learning Within Teams Encouraging team members to continuously broaden their skill sets and product understanding. Repeatedly filling skill gaps and addressing recurring dependencies shifts teams from narrow specialization to more complete, customer-focused capabilities. Systematically Reducing External Dependencies Incrementally incorporating previously external tasks (e.g., operations or platform integrations) into team skill sets. This ongoing practice consistently lowers lead times, enhances responsiveness, and fosters more adaptive, continuous value delivery. Iterative Organizational Redesign with Holistic Prioritization Regularly realigning responsibilities and boundaries based on evolving product goals. By repeatedly refining structures to align with strategic objectives, teams achieve faster, more streamlined delivery and better organizational coherence. Establishing Regular, Objective-Based Assessments Incorporating neutral frameworks like Org Topologies in a repeated cycle of diagnosis and action. Each assessment informs targeted improvements, ensuring the organization continuously evolves toward higher adaptability and flow efficiency. Increasing Direct Customer Interaction Embedding routines where teams regularly engage with customers or user feedback. Over time, these habitual feedback loops guide more precise product choices, strengthen customer alignment, and improve the speed and relevance of delivered solutions. More on Elevating Katas here .

Org Topologies ™ : A brilliant frame to clash "expectations" with "conditioning" and to let them explode. Let me explain. Once upon a time... There was a Y0 group in the realm of HR. A land where decision power lies beyond their domain. Their courageous manager believed that the team could thrive and perform better. She acknowledged internal and external limitations, just enough to believe "the team" to be of A1 nature, when given time to map them onto the Org Topologies ™ . When it comes to expectations towards them, she naturally assumed they would act as if they were A2 . Desired collaboration, knowledge exchange, and approaching challenges together as if those were features. She wanted "the team" to generate brilliant ideas as a result of working together as a group. Her and the company's aspiration was to elevate "the team" to B3 status. To gain full empowerment in shaping the recruitment process and campaigns in the company. To take the lead in strategic talent pool planning. To shape actions of today that would become the company's reality tomorrow. In the meantime… All the measurements were aimed at Y0. All KPIs were focused on throughput, and all tasks required a single skilled individual to perform them. These tasks were designed for execution, not for collaborative problem-solving, and there was no room or desire to change that. Communication was directed at Y0. Expectations were set for individuals. Messages were channeled to individuals. Tasks were divided for individuals to execute, with no room or appetite for change. The career path was aimed at Y0. Annual paths, goals, and assessments were centered on personal objectives. The one-on-ones, the reviews, and ultimately, the grades were built solely around individual performance. Collaboration was discouraged. Techniques like swarming or pairing were branded as wasteful in the pursuit of achieving KPIs. Customer collaboration and knowledge transfer were limited to a minimum to allow more time for individual work to meet quotas. Following the plan was paramount, while prototyping, experimenting, and the pursuit of innovation were acceptable only if they could yield immediate benefits. Therefore… The team remained at Y0 as conditioned . They were a group of skilled professionals sitting in a shared workspace. Competencies and work areas were cleanly separated. With few occasional meetings, they quickly returned to their tasks. The team focused on a consistent flow of individual tasks, optimized for high proficiency and low collaboration, much like a well-oiled engine. The problem didn't lie with the team but with the manager and company expectations. Let's venture into the woods… All the conditions that surrounded these professionals led them to believe they should act as Y0, like solitary bobcats hunting alone. They had been hired this way, measured this way, communicated to this way, provided with a corporate development path shaped this way, and delivery techniques-wise incentivized to behave this way every single day. Expecting this group to transform into a pride of lions or a wolf pack, into an A2 or even into a B3 type of team, simply by stating it as a managerial expectation, without introducing any changes to the Organizational Structure, was irrational. It was as effective as having a face-to-face coaching session with a hungry grizzly bear about the benefits of becoming a vegan—it just wasn't going to happen. Clashing expectations with conditioning… Org Topologies ™ provides a brilliant framework to set the stage for such discussions. Engaging organizations in journey like the one described above: Acknowledging that the team is currently a Y0 Recognizing that the manager actually perceives them as A2 Understanding what the board's aspiration to elevate them to B3 really means Recognizing that the upstream dynamics, KPIs, career paths, and practices that promote Y0 Observing the confusion when all the above come together Initiating a rewarding coaching quest to bridge the disparity, unlock human potential, and enable individuals to excel.

The Engineering Manager’s job includes helping their team become more effective at solving problems, and collaborating with other teams and departments to achieve results that their own team cannot achieve alone. EMs work to improve software development processes, encourage collaboration within the team and with the team’s stakeholders. They help the team to structure their work. A complex software system is made from many components, and most development requires changes across several components. Which teams get to work on which components? The answer to this question has a large and often unacknowledged impact on how Engineering Managers spend their time. The more components a team can work on, the less time an EM spends on negotiating with other EMs. But, the tighter a team’s focus, the more inter-team coordination is necessary. John Cutler calls this invisible work A huge source of "invisible work" in companies is managers having to essentially manage sideways to sort out dependencies, etc. It is basically asking managers to be the human load balancers of the org instead of focusing on their teams, and connecting with customers. Marcus, a good friend of mine, is an Engineering Manager at a Big Tech company in the US. During our regular video chat, I introduced him to Org Topologies ™, and learned something about the work of EMs in Big Tech. Org Topologies is a diagnostic showing what kind of organisational dynamics your team structure is generating. Also, how changing team structures in specific ways can bring about changed dynamics. Hi Steve! Hey Marcus! So one of my consulting clients has a complicated development process, with lots of meetings and tickets. Their managers and architects are super busy just keeping things connected up. The company’s senior management feels that product progress is slow, and they’re right. We’ve both seen that before. The first step is acknowledging you have a problem. Right. I’m showing them how to use the Org Topologies chart as a navigation aid: First figuring out what kind of team structure they have, and what kind of problems and benefits come with that. Then, where on the chart they’d like to end up. Finally, what it’s going to look like getting there. Sounds too easy… There’s a lot of nuance to the tool, and a bunch of work to actually make the changes. That’s one of the reasons we’re charting it out — so that we can work one step at a time, and take everyone on the journey together. Okay, I’m interested… tell me how it works. The map shows an organisation through the lens of what kinds of results an individual team can achieve on their own. Within a team, while there are norms and conventions, there doesn’t need to be so much formal process. The longer a team has worked together, the less formality is needed. But between teams, we need coordinating roles or project management systems. Scope of work The vertical axis is called Scope of Work. What kind of a goal can a team take on? The rows are labeled Y A B C. Let’s start on the cherry blossom row “Feature focus”. Cherry blossom ? How poetic! Oh wait… you mean the red row Row A . Teams are asked to make product features, where a feature is some new or changed functionality that the system should provide. Work on a feature is usually focused on a single system component, maybe with dependencies on other components. It’s common to see several A teams, each owning a system component. Work is assigned to teams based on what component is involved in the work, and there are project management systems to track dependencies. The one component to one team model is popular, maybe because when a team is solely responsible for something it’s easy to hold them accountable[1] for that thing. But it means that a team can only change their own component; for anything else, they need to make arrangements with another team. That sounds like my team There’s also task-focused work ( row Y ), where individuals or teams are given narrowly-focused and often technical work to do. You see this sometimes when a team seems to work together, but each team member is working on a different near-term goal. In this case, it’s wrong to call them a team, as there is no shared objective they’re working on together. It’s like a football team, but where each team member is playing a different match. So, we call these units instead. No, we don’t do that. We actually have shared goals every two weeks and everyone on the team contributes Row B product part focus is where a team is asked to provide a customer outcome or business need. They can work across many components as necessary to create the desired outcome, even while other teams are doing the same for other customer needs. Teams collaborate with other teams as needed, without needing to assign work to dependent teams, and without external project management. The top row C, whole product focus, is the same. Each team can work across any part of the system that is needed to get something done. The difference between B and C is in how much of the system, and how much of the business domain of the system, teams are responsible for. At B, a team works on parts of the business domain and parts of the system. At C, a team can be effective across everything, because they are supported and equipped to learn as they go. If a component is owned by several teams, how does that work? Shared ownership could lead to chaos Sure, if there’s an “anything goes” approach, it’ll be chaotic. Code quality, tech debt, and all that stuff. Fortunately, there are several ways to share ownership in more structured ways. A team can have a stewardship or guardianship responsibility for a particular component, and when another team wants to make changes, the guardian team helps them with the change design, and reviews the changes. So, there can be lighter-touch involvement between teams than “add it to their backlog and wait”. That’s how it works here. You “file tickets against other teams” when you need something changed in a component owned by another team File tickets against sounds like getting parking fines It does. Actually, it often feels like a kind of punishment, because the team receiving the tickets now has more work to do that they hadn’t planned for. That’s how we normally work. But sometimes, if you know the other manager well, and there is trust, there’s an opportunity to work in a more shared way. There are other teams that you share components with sometimes? Not usually — we have this B-ish collaboration sometimes, but it requires Engineering Managers to put time and energy into enabling it. After the feature is done, things fall back into the usual pattern on the A row. Getting work done despite the organisational structure. That’s a good way to put it. A lot of an EM’s job is helping things to work well despite the organisational structure So, that can happen, but it takes extra efforts to make it work, and it’s not sustainable without continuing to apply the effort. Wouldn’t it be nice if the organisational structure supported the requisite work, instead? (Marcus offers a knowing smile) Changing structure is difficult; it affects career ladders and how people are seen within the organisation, and lots of other things. Is there anyone who has a broader remit than one or two components? Sure, some senior managers have a broader B-row kind of scope. But they’re also rather disconnected from what the teams are actually doing. There’s also SVP and VP level executives whose actions make it harder or easier to “work despite the structure”. Often because their actions impact how much trust there is between team-level engineering managers. Okay, high levels of trust is needed for work despite the structure ? It’s the most important thing. I get the rows now; tell me about the columns. Completeness of skills The columns are about completeness of skills . They’re labeled 0 1 2 3. My guess is your team is a multi-skill unit Do we have to be a “unit” ? I’d prefer to be called a Team You were in the Feature Focus row A, so it’s quite likely you are a team. We still call the column “unit” because when there’s a narrow task-focus (row Y) there’s usually not a shared goal, limited amounts of interdependency. So while there’s people doing work, there’s not a lot of team work. Ad hoc collaboration is possible within a unit. But the structure of the organisation determines how coordination between units happens. So, people in the same unit can work together with little overhead; but when multiple units are involved, we typically see some level of bureaucracy. Got it. We do have multiple skills: development, test, design, deployment. There are two things[2] that regulate whether a team can do some work without needing to be blocked by others outside the team. Can they work on the component areas of the product as required? Does the team have the requisite skills? This second point is about all the skills needed to take a feature from the point where we recognise that it’s something we want to do, all the way through to shipping the feature to users. That probably includes design, test, coding, integration, deployment, release. Are the requisite skills known on the team? And if they are, are they allowed to use them; or do they need to hand off to another department for some kind of security test, or deployment? No, we’re good. In most cases we can release all the way. A single-skill individual, column 0, would be like a Database Administrator who deals with the Oracle database. I worked in a company once where there was one DBA (Microsoft SQL Server this time), and he was the only one allowed to edit stored procedures and do certain deeper database stuff. To get him to do something, you would send him an email, and a bit later he’d do it and mail you the results. He was in the same office most of the time. Okay, let me guess… Y0 for the task-oriented DBA Exactly, Y0 single skill individual. Now imagine there’s a whole department of DBAs, managed by a senior DBA. Across the whole department they know different databases. A few can do deep performance tuning; others specialise in 5th and 6th Normal Form. Y1, functional unit Almost right. Column 1 for “functional unit”. But we don’t know about the Y — if they’re task-focused. From the description it sounds likely, if the database is one of several system components. But if the product is in fact a database, and their customers / users interact with it directly (maybe using a B.I. tool like Looker or Tableau), they might be at A1, B1 or C1. So it depends on what the product is: what are customers paying for, and users expecting to use? Multi-learning teams Got it. So right-hand column: what’s a Multi-Learning Unit? A team that has support to learn new skills of different kinds (domain knowledge, technical knowledge), and learning perhaps being more like figuring out proofs-of-concept together, rather than being sent by a manager on a 3 day training course then being expected to have a new skill. Teams that learn by doing and collaborating; rather than having to add people to the team to bring in new skills. Going further, groups of teams that choose when to take the most direct line to delivering a feature, and when to take the “scenic route”, slowing down in order to acquire new skills and knowledge. Optimising capability and learning across the entire group. Developing ways of predicting what skills and knowledge will be needed in the mid-term future, so by the time they’re needed the teams are prepared. If our tech stack is stable, and our business isn’t changing, is there much benefit to being multi-learning? Maybe not! But over the course of months and years, technology changes whether we want it to or not. Whether it’s software versions, new internet protocols (e.g. HTTP/3), consumer hardware (new iPhone models)… And a business that doesn’t change either has a captive market, a monopoly, or owners with a lot of disposable income. If there’s a lot of employee turnover, people won’t stick around for long enough to learn and then apply those learnings. But that’s a sign of more serious problems. Okay, I think I understand how the Org Topologies chart works Teams at my company are more or less at A2, multi-skill teams with feature focus. Sometimes Engineering Managers make special efforts to get teams together and soften the unit boundaries, so we’re at a B2-ish place, working across several components. But this lasts only as long as needed to get some specific feature delivered. The organisation’s structure and politics naturally returns to A2. Is there anything EMs can do to shift the organisation out of A2, perhaps into B2? Would there be a benefit to this? We’ve shown we can work in a B2-ish way when there’s trust between the EMs and teams, and when the need is there. But to do so long-term would mean changing a lot of things — progression / incentive structures, technical practices around component ownership, company-wide project management… Engineering Managers can support such a change, but it needs to be driven by more senior roles. Starting a journey with intention, you need to know where you are. If you’re planning to go somewhere, it helps to know where you’re starting from. And even if you’re happy where you are, maybe it’s reassuring to understand more about why this is the place to stay. Learn more about Org Topologies . [1]: In many companies, hold accountable is business jargon for blame. The company’s leadership want to be able to blame specific people if something bad happens. They are reluctant to give this up, even if it means having less effective teams. Part of the reason for this is that they don’t understand what blame is, and what might be used instead. Blame is an organisational development tool, and a particularly blunt and clumsy one. Wielding it always causes unintended consequences, chronic wounds that resist healing. Giving up blame, and switching to more subtle and precise organisational development tools is an important enabler that allows companies to shift into the top-right area of Org Topologies. [2]: A third thing that enables teams to have dependencies without blocking: whether the other team is available to them without the need for a backlog. Both teams work on dependent features at the same time, and are fully available to each other to mutually adjust the features as they are developed. But this is for another conversation.

This article is a detailed analysis of James Shore 's talk at the AgeofProduct . We recommend watching the full video of the talk . We're looking at this case study from the viewpoint of Org Topologies™ to understand better the chain of transformations he is describing in this talk. The story he is sharing spans several years while he was helping a company to move away from a rigid multi-team constellation of component teams to an org design based on mainly stream-aligned teams of Team Topologies ® and later on to a more fluid FaST - ecosystem. The meta-level goal of this article is to demonstrate the power of Org Topologies™ as an approach to visualizing and communicating org design and org change ideas. Thus, this article contrasts three different organizational designs showing their significant differences. First Org Design: Component Teams In the video, James Shore first shares his definition of component teams: In the Org Topologies™ language, we are trying to avoid the black-and-white definitions like 'component teams'. That's why we have a map of 16 archetypes, with 7 of them being the most recognizable . If we map the 'component teams' as James describes them, they will be represented by the orange post-its on the map below as Y2 and Y3 archetypes. The exact classification will depend on how incomplete or complete those work units are in terms of their technical capabilities: In James' words: "Component Teams ... is the most common thing I used to see and actuallty the most common thing I still see today.... This is where each team is focused on a particular technical part of the system... A front-end team and a back-end team... The database team... Or the Ops team... People who are focused on specific technical areas. James was hired to help that organization with component teams because "the work was grinding to a halt." This is not surprising if we analyze an ecosystem of such teams: structurally, such teams cannot independently ship customer features or work on business objectives end-to-end (that's why they are mapped at the Y-level, the task focus level. They can't complete user features); they cannot see the bigger picture, simply because that is not their focus; therefore, such teams require external specialists and functional groups to provide them with detailed requirements and task breakdowns and help them coordinate and integrate their tasks into a shippable valuable piece of software. An organization that has such an organizational design will have many blocking dependencies, hand-offs, queues, coordinating roles, upfront plans, dependency boards, and integration issues to manage. Such an organization will be too busy dealing with its world of self-imposed complexity. Rather than being customer-focused, outcome-oriented, and product-centric. The mapping below depicts all the overhead archetypes that are needed to complement the Y-level archetypes for the whole system to deliver a working product (individuals and groups dealing with analysis, design, coordination, integration, operation, etc.): No surprise such organizations would want to improve, eventually. But in our experience, the required management awakening can take years. Why is it so hard to change? An org design with component teams is very sticky. First of all, the developers in component teams might not see a problem at all! They strongly focus on what they are good at (and everyone likes to have focus). They feel a strong sense of ownership (of components). All the excessive complexity such a component organization needs is handled by people external to the developers. So, the developers usually don't feel the burden. Sometimes, when you talk to the developers of component teams and ask whether they know of many cross-team dependencies, they might surprisingly respond: "No, not at all!". Component teams might not see the dependencies, as each team has its task-level backlog that someone external to the team populates and manages. They live in an illusion of independence. "We can do those tasks without any other team," they'd say. And they would be correct. But from the value flow viewpoint, a feature touching multiple components that are owned by different teams has to be broken down into separate tasks. And those separate parts of the feature sit in many different team-level backlogs. Will they be picked up by different teams simultaneously and worked on in a single cadence? Very unlikely. So there are dependencies and asynchronous work that slows down the delivery of value, but one needs to see the bigger picture to see that. This can be summarized by this famous definition of a cognitive bias described by Daniel Kahneman in his book "Thinking, Fast and Slow": What You See is All There Is (WYSIATI) says that when presented with evidence, especially those that confirm your mental model, you do not question what evidence might be missing. The dependencies are between the backlogs, not within them. But these dependencies are not what the teams are looking at... That's why component teams might linger in sweet ignorance of being 'efficient' and 'productive'. This can be illustrated with the following map overlay: See how this illusion of independence and the focus on internal concerns (better developers' focus, stronger developers' ownership) create a dysfunctional organization where rich collaboration and joint work of multiple teams becomes almost impossible. James reports that the company had 200 engineers, 300 people in the R&D, and 42 teams. And based on his value-stream mapping analysis, it had 97% of waste or wait time! So they were spending months on something that would take just 2–3 days of work. That was caused by all that waiting and asynchronous, unaligned work of the component teams. James wonderfully describes in one passage the dynamics and culture such an organization exhibits, showing how such companies "get killed by their cross-team dependencies": A team would start working on something, but they would need another team to do something, so they would hand off and then they would wait. And while waiting they would take on other work. So when another team came to them saying "we need something from you", they said "sorry, we're in the middle of something" and now that team would wait... They created what James calls "the spaghetti diagram". Each card represents a team and every line represents a blocking dependency: Second Org Design: Stream-Aligned Teams James has helped the organization of 42 component teams to move away from the spaghetti state by redefining the responsibilities and making, what he calls, "full ownership teams.", which is very similar to the "stream-aligned teams" popularized by Team Topologies: Looking at this organizational redesign through the lens of Org Topologies™, this was a move from a Y-level team setup of entangled component teams to an A-level setup with the majority of teams being able to work on customer features end-to-end. And that is a great improvement! That organizational improvement helped the company to grow and got up to about 67 teams. However, with the new design and increased number of teams, the company started running into new problems, which were mostly around product management . And this is not surprising: Every new solution will create new (better) problems. In an earlier article, we made an extensive analysis of the Team Topologies, and concluded that such a setup creates a low-level ecosystem: So the "product management" problems referred to in the story by James are caused by the fact that the stream-aligned teams are focusing mainly on what they are good at already. They build and deliver features that lie within their field of expertise. And that is not a coincidence, That’s intentional. In the language of Team Topologies: "The goal is to optimize for fast flow of change". Because of this optimizing goal, stream-aligned teams will be given work that is in their field of expertise because that is the fastest way to get that work done. They will be given some set of features in which they can develop deep expertise to be fast at shipping those changes. That's why the steam-aligned teams are mapped at the A-level, the feature focus level. Because of the relatively narrow scope of work, stream-aligned teams " did not truly own a significant portion of the final product " (a direct quote from James in the video). A rhetorical question: what happens when you have work units that are fixed to work only on given parts of the whole (components or feature sets)? You will have dependencies between the teams! But we agree such dependencies are less strong than between the pure component teams. So the new setup is an improvement compared to the previous state. According to the storyline, the new org design with stream-aligned teams was significantly better than the initial one with component teams. With the stream-aligned teams, you can focus more on external concerns such as shipping features to serve known user needs, getting fast feedback thanks to the fast flow of change, and then improving the product features. That feedback cycle is the essence of agility. Yet, James also mentions issues related to this design. One issue had to do with not having enough "specialties" such as UX, Security, and SREs (site reliability engineers) in each team. In other words, the teams were incomplete (A2 as per Org Topologies™). In this phase they had to deal with two different kinds of dependencies: product-level dependencies, due to the narrow scope of work (features) in teams specialization dependencies, due to the incompleteness of skills in teams The second issue mentioned is of greater importance. It had to do with the architects (likely a C1 archetype, as per Org Topologies™) not being able to constantly match the team structure to the changing business and architectural needs. This is substantial: the "essential agile" team archetypes, as per the illustration above, cannot sustain business-level agility. By design, such teams tend to be stuck at whatever they are already good at (they have a feature focus). Thus, they are not fluent and unresponsive when it comes to changes in the product strategy or changes in the architecture. They can't adapt quickly and easily. They are stuck to build and ship fast what they know how to build and ship (remember: the fast flow of change is the goal for stream-aligned teams). To keep the organizational design and the business strategy in sync, narrowly specializing teams (like all stream-aligned teams) need to be reorganized regularly. This is expensive and difficult. James concluded in his story that the architect group failed at that task. But our view on that is that the task of realigning the team structure to the strategy is too complex to be performed by anyone regularly. And the scale they had (40+ teams) was also not making it less of a challenge. So the next step the company was heading toward was to craft an organizational design that would enable true (business-centric) agility. This should be a design where the structure is in constant re-alignment to the business needs. A fluid structure. Third Org Design: Towards True Agility with FaST James got excited about the FaST . He learned it from Quinton (Ron) Quartel and Paige Watson around 2019. FaST stands for Fluid Scaling Technology, and is about combining open space technology (a tool for self-organization) with a frequent opportunity to change team compositions. The reason FaST appealed so much to James, in his own words: What we were doing in the Team Topologies approach is that we were scaling horizontally . We're adding people by adding new teams... That requires careful design... Ultimately we're talking about making a big design change to the organization and potentially reflecting that also in the architecture... Sort of a top-down approach ... and to be done in kind of a big bang way. So the self-managed, bottom-up, and incremental approach offered by FaST was appealing to James, being much more in the spirit of agile: In the FaST approach we're scaling vertically . We're adding people by having more people participating in one virtual team (a Collective), having more people act as a single team. Essentially, James ran an experiment in that company with a subset of seven very tightly coupled stream-aligned teams (around 50 developers) and turned them into a FaST Collective. This essentially is a single large team that regularly self-organizes into temporary small teams based on the work at hand. James concludes with these five key takeaways: We conclude that FaST has helped to design and sustain a high-level product-centric ecosystem in that company. James also talked a lot about the high transparency such an ecosystem created for its business stakeholders. And we know in empirical process control, transparency is a prerequisite for proper inspection and adaptation. Hence, it is an enabler for better steering and governing. So the third organizational design was displaying better manageability and higher adaptability than the other two options (component teams and stream-aligned teams). This positions FaST in the top-right corner of the Org Topologies™ map, potentially spanning the area from B2 and B3 up to C2 and C3. And where does a FaST collective as described in the video live, exactly in the land of FaST? The vertical aspect: It depends on the size of an organization: with only 50 people in R&D, all developers would belong to a single Collective. And by definition, that Collective would own the whole product. Therefore, that would be a C-level ecosystem. We cannot imagine the constant creation of temporary teams with hundreds of developers in an open space every other day (we are open to learning that this is possible, so we need more case studies, experience reports, or invitations to implement this). However, for now, with the facts that we have, we believe that with hundreds of developers, there will be a need for several Collectives. And likely each Collective will own its product part. Therefore, this would be a B-level ecosystem. The Collective described in the video was formed from seven tightly coupled teams, while the rest of the organization remained unchanged. Although it was not clear in the video whether the Collective worked on the whole product or just its part, it is safe to assume that they worked on a product part. Therefore, the case presented in the video would be classified as a B-level archetype. The horizontal aspect: For a work unit (a team, a team of teams) to qualify for a multi learning unit (Y3, A3, B3, or C3) it needs to exhibit a unique observable behavior: over time people in that unit are acquiring new skills, hence they 'multi-learn' (we borrowed this term from an HBD article ). Multilearning is very much different from multi-skill work. In the latter case, people with existing skills work closely together, utilizing their existing skills. In a long-living stable team with a broad product scope, it is simply not possible to keep utilizing one's existing skills forever without being constantly under or overloaded. That's because a constant match between the existing skills and the demand for skills is highly unlikely in a complex work environment (i.e., product development). That means, the fewer skills you have, the bigger the chance you won't be able to utilize them all the time when working on the business priorities. So, in a long-living stable team, to stay relevant, one will have to acquire new skills that are currently in higher demand, hence: multi-learn. That's the dynamics expected in LeSS with feature teams (as a side note: in the video James is misusing the term 'feature teams' equating them to 'stream-aligned teams'; which is a big misunderstanding). In FaST, people have a chance to change work and with whom they work every few days (for the next FaST cycle) because of the built-in fluidity. Will the people be acquiring new broad skills in such a fluid environment? Or will they follow the work and maximize utilization of their existing skills? Will a back-end developer self-volunteer to work (and multi-learn) a front-end task for the next cycle, or will she be pulled in to contribute with her existing back-end skills? That is very contextual and will depend on many things, including personal motivation, stress, level of engineering practices, code-sharing policies, coaching by the managers, the existing reward systems, HR policies... So we can't say that FaST will always be fostering the creation of multi-learning work units, though, we believe it is not impossible, but FaST alone (as a process) won't suffice. Hence, it is safe to assess the target org design in James' story at B2-level Collective. Summary This case study illustrates the power of the Org Topologies™ approach in assessing different organizational designs and organizational change ideas from the viewpoint of structural facts and observed inter-team dynamics. We encourage you to apply it at your workplace and report back. There is a growing learning community: join us in Slack attend our educational events report back your experience reports (C) 2023, Alexey Krivitsky and Roland Flemm. Org Topologies™. This experience report presents a personal view of the change story based on the provided references. 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.

De Volksbank is the fourth largest bank in the Netherlands. The bank was formed two hundred years ago from regional savings banks. Today, de Volksbank focuses on consumers, independent entrepreneurs, and small and medium-sized enterprises. The bank operates mainly in the areas of payments, savings, and mortgages. In 2021 a new four-year strategic agenda was introduced focusing on growth by strengthening customer relationships and further increasing the banks' social impact. To realize this ambition, a transformation was initiated that aimed at implementing a uniform agile way of working with independent, integrally responsible customer journey teams. The new strategy should make the bank more customer-centric and enable them to get better, faster, and more effective at delivering value to customers. The transformation impacted the whole bank. In March 2022, about 3,000 people faced either a change of work, a change of team, and/or a change in the way of working. In the new structure, the bank was split into 14 "Hubs". These are value areas with P&L responsibility. Each hub is responsible for a specific customer journey. A Hub is set up integrally, which implies that each hub contains business, IT, and operations. The entire organization "flipped" to the new model in March 2022. This case study analyzes the transformation journey using Org Topologies™ Scans and focuses on the Business Banking Hub. It covers three organizational design phases: Org scan of the pre-agile setup before August 2021. Org scan of the 2022 dVM pilot . Org scan of the current layout per February 2023. We will clarify the stages with OT maps using the following symbols: More explanation and background information on Org Topologies™ that help to understand this case study can be found here and here . 1. Pre-transformation setup before August 2021. The department "Business Banking" was divided into three sub-departments: Operations, Business Lending Sales Support, and Customer Onboarding. These departments were focused on servicing business customers. A single team "monitoren en verbeteren" (monitor and improve) was responsible for product development. This was the department's R&D team. The picture below is a detailed view of the Business Banking department in deVolksbank prior to the transformation. Of the 10 people in "monitoren en verbeteren", 6 were tasked to improve the operational workflow of the three operational teams. They had task scope, no product vision, and no value-based prioritization of work. They were working on improvement requests given to them by the operational teams. These requests did not necessarily have high customer value. They were working as individuals on unprioritized tasks (three operations groups with different requests). They did not have the skills or authorization to make software and configuration changes in the banking systems. Their work was restricted to: specifying changes requested by the operational teams, assigning them as tasks to technical teams somewhere in the adjacent IT group , chasing progress. Working as individuals on unprioritized tasks (three operations groups with all kinds of change requests) makes them a Y0-level group on the OT map . The queue of work was huge due to the long waiting times for the work in progress. Larger and more complex initiatives were hard to implement and took many months, sometimes years to complete. Tasks belonging to these initiatives got stuck in the worklists of teams in the IT department due to unclear decision processes. The people were used to working in an environment where asynchronous communication via email requests was the norm. They were spending most of their time lobbying in IT to get their requests prioritized and negotiating with a vast landscape of stakeholders. A huge amount of time was wasted waiting. The other 4 people worked as a Scrum team focusing on New Business Lending products. The subgroup's work was specifying and accepting changes in collaboration with an external software company that developed a New Business Lending product. This team specified customer-centric features for the vendor to develop. The team and their PO were decomposing the customer requirements into tasks to hand them over to the vendor's development teams. This makes them an analyst team for the external developers, archetype A1 in "the speculation department" on the OT map. The New Business Lending team did not suffer from the bank's IT dependencies but had 100% dependency on their external vendor and they had some dependencies on business stakeholders ("Brands"). They were able to deliver value much faster than the teams with internal IT dependencies. The developers at the vendor were processing tasks for multiple clients. The vendor did not have dedicated teams per client but had two groups of developers working on specific parts of the product. 2. Pilot with feature teams 2021-2022. Prior to the bank-wide adoption, a new self-invented model (based on team topologies and Spotify) called "dVM" (de Volksbank samenwerkingsModel) was piloted in the Business Banking department. It is noteworthy to mention that this transformation initiative was driven by the Business side of the bank, not by IT, which is more common. The people working in the R&D team "monitoren en verbeteren" were placed into four groups, each focusing on a specific customer journey. Each group contained one R&D team and one or more service teams. The R&D teams focused on developing products and the service teams kept their focus on daily operations, serving the customer. There was a tight feedback loop between them. The operational teams were important stakeholders, providing valuable customer feedback. Each R&D team had its team PO, prioritizing work on value. The following groups were created: The Customer Onboarding group: everything related to smoothly welcoming new customers. The New Business Lending Group: building new business lending solutions. The Business Lending Maintenance Group: Supporting existing business lending solutions. The Bloxx group: developing an approach allowing business customers to configure their own service and product catalog Each R&D team was formed with cross-functional business people. Each team was able to address a full range of business problems (features) related to their domain but they had no technical expertise. This makes them A1-level teams (analyst teams, or "the speculation department"). The backlogs contained customer-centric features instead of service-oriented tasks. The fact that the R&D teams did not have IT capabilities was a problem because most of the changes they were working on required changes in IT systems. Some teams were able to do no-code changes, but all 'n all, their technical capabilities were limited. Although still low on the Org Topologies™ map, this setup was experienced by the team members as a huge improvement because now: they were working full-time in a steady team, they were working on the specification and delivery of customer features, they were working on high-value work because work was prioritized on customer value. At the same time, having limited capabilities combined with end-to-end responsibilities was frustrating. They were wasting time chasing their changes to be delivered. We gradually improved this situation by extending their (technical) capabilities. This desire for autonomy was not appreciated by the surrounding organization. Don't forget this was only a very small pilot in a very big bank, so not surprisingly, the team's appetite for mandate, capabilities, and speed was causing resistance in the remainder of the bank. The New Business Lending team continued working with the external vendor. In the beginning, this made their life relatively easy since they had limited dependencies on the technical infrastructure and IT teams of the bank. However, the number of teams at the external vendor had grown and now were organized as component teams: Each vendor-component team had a team "PO" managing their team's backlog. Coordinating the work across the other vendor teams was difficult and slowed down the development process. An additional complication was that the external vendor was not solely focused on delivering the bank's requirements but they were also productizing the requirements to market them to other customers. This makes total sense, but it was not helping the bank. In summary, from the bank's point of view, the vendor's business model and organizational design had a negative effect on the quality of service. The other three teams were depending heavily on the bank's IT teams. The IT departments worked as component teams (Y0 and Y1 archetypes). Due to the high number of technical dependencies and the lack of support for the new feature teams, the Customer Onboarding PO got completely stuck. She had to split customer requirements to feed the IT component teams, she had to fight to get her work prioritized, and she had to bend over backward to find a way to get her changes integrated across multiple release calenders. Not a job you would envy... The Bloxx team was fortunate because they were the first team to have developers in the team. However, there were some startup problems here too. The developers in the Bloxx team were working under the strict guidance of the bank's PEGA group. This group had a strong architectural drive and was focused on building centralized and reusable solutions for the whole bank. The PEGA developers were telling her how to change the specifications so the solution could fit into the PEGA architecture. It was the world upside down: the Bloxx PO found herself being a lobbyist trying to get the PEGA developers in her team to build what she needed. One thing all teams had in common was their dependence on "the brands". The bank exposes its services in the Dutch market using four distinctive customer-facing brands. These brands had different and conflicting requirements for the solutions built by the four R&D teams. The brands were powerful: they were deciding on requirements and approved or rejected the changes created by the R&D teams, often on the technical level. Customer Onboarding tried to get around this problem by adding a brand specialist to their team. This person was working as a proxy on behalf of all brands. In practice, this did not work because the brand specialist's decisions were overruled by other (brand) stakeholders. The dedicated teams were able to deliver in a regular Sprint cadence, which was much faster than before (weeks instead of months). But their mandate was not respected by the unchanged organization. In addition, the contradictory demands of the business stakeholders, and the complex IT environment were frustrating them. These were the most important learnings from the pilot that helped to improve the dVM org design: Feature teams with a PO to prioritize work on value and the operational teams' focus on servicing the client resulted in faster delivery of better solutions and better service to the customer. Reducing the power of the stakeholders (i.e. brands) by clarifying the R&D team's mandates is required. Reducing the influence of (middle) management by repurposing their role in the service of the teams is needed. Teams should be bus-dev-ops teams by adding all technical capabilities to the teams required to deliver "Done". Clear responsibilities and capabilities of the feature teams attract stakeholders who are in need of the capacity to get things done and try to feed their changes into the feature teams. This was unexpected behavior that actually proved this initiative was successful. Creating feature teams creates much resistance in the organization surrounding these teams. Gradual change is more complex to manage. 3. De Volksbank SamenwerkingsModel (dVM) in Feb 2023. The pilot setup with R&D teams and service desk teams (operations) close together in groups was implemented in the whole bank. All four Business Banking R&D teams gained autonomy by growing their technical capabilities. Some reached A3 (autonomously working end-to-end on customer journeys) and most were A2 (incomplete teams working on customer journeys, not end-to-end). The majority of the dependencies on the brands have been resolved by moving product responsibilities of the brands to the feature teams in the Hubs. The brands now have teams that focus purely on work like marketing and campaigning, not banking product development. The separation between roles and responsibilities is clear: the R&D teams have the mandate and the brand teams are stakeholders to them. Most of the dependencies on IT have been resolved. Two of the R&D teams now all have the technical capabilities they need to work autonomously. The solution to remove the technical dependencies was achieved by adding developers to the teams. The POs determine what is most valuable, not stakeholders like the architecture group via the (PEGA) developers. The New Business Lending team's dependencies on the external vendor were not resolved. The vendor has added a "first contact" proxy team to better serve de Volksbank. The proxy team provides lo-code/no-code solutions, is a single point of contact, and handles coordination with the vendor's internal component teams. The bank and the vendor collaborate on further reducing lead times. The proxy team operates at the feature(set) level and is narrowly specialized in analysis (A1 Archetype). The teams inside a value area (Hub) coordinate using OBEYA . The same practice is used to align with teams in other hubs. The Business Banking Hub Lead says that the implementation of the dVM model was very successful in creating strong autonomous teams. Alignment between all teams inside the hub using OBEYA has proven to be pretty successful too, but there are challenges in resolving cross-hub initiatives. Higher management has a tendency to fall back to old patterns to manage cross-hub problems (instead of trusting the Hubs to self-organize). On one hand, this is due to a lack of experience using OBEYA for that purpose. On the other hand, the Hubs suffer from local thinking. The Hub leadership teams should be more aware of the recurring dependencies between Hubs (and teams) as an indication that the org design can be improved. Conclusion Did the new org design make Business Banking more customer-centric and get better, faster, and more effective at delivering value to customers? It definitely did. Further improvements will be achieved by eliminating remaining dependencies, re-evaluating the current org design and improving the OBEYA for better cross-Hub collaboration. We are happy that the Business Banking Hub POs perform experiments with cross-team collaboration (applying practices from the higher B-level). The dVM design was intended to be an evolutionary model. The OT Scans (TM) can serve as a guide to monitor the progress of the bank's journey to further improve its organizational design. We recommend each department (Hub) plots a current and future state map. This will increase our understanding of why things currently work or do not work, and will enable us to find the root causes and best possible solutions for improving the management of cross-hub problems, resolving remaining impediments, fixing staffing problems, etc. Acknowledgments We want to thank the following people for investing their time in creating this case study with us: D. Karacan (PO New Business Lending) J. Verhey (Hub Lead Business Banking) (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.

Exploring Org Topologies at Loglass This article is also available in Japanese . I have recently become interested in Org Topologies - a framework designed to enhance organizational design through thoughtful structuring, fostering higher adaptability, and ensuring a transparent change process. Org Topologies revolves around two key axes: the "Scope of Capabilities" and the "Scope of Work." Together, these axes form 16 archetypes that represent different organizational patterns or types. These archetypes help in identifying, assessing, and designing organizations to optimize their adaptability and performance. The Scope of Capabilities measures the level of cross-functionality and the ability of a unit to deliver value independently. High capability consolidation means fewer technical dependencies and greater autonomy. The Scope of Work evaluates the breadth of the work a unit can handle, from narrow task-specific work to broad value definitions that encompass entire customer needs. This framework allows for simple visualization and classification into the 16 different Archetypes on a two-axis map. By understanding these archetypes, organizations can craft a thoughtful design, fostering higher adaptability and resilience in the face of changing business needs. In January 2024, I introduced Org Topologies to Loglass - a Japanese company providing a cloud-based management system aimed at improving the productivity of budget and performance management. I have recently been supporting. The company divides its product into multiple functional areas, with each area being developed by independent Scrum teams. Each Scrum team is highly capable as a stand-alone unit, but there is not much collaboration between the teams. I gave a brief introduction of Org Topologies in a short 30-minute session. The participants showed a strong interest and immediately held a one-hour workshop the next day with all employees in the development organization, where they plotted the current status of each team on a map. Although it was only a self-assessment in a short workshop, most teams plotted themselves onto A1 - A2, as I expected. To clarify, the A1 and A2 archetypes represent specific types of organizational structures: A1 (Siloed functional group with feature focus) : Teams within this archetype are specialized in specific functions and work on particular features. They tend to work in silos, with limited interaction with other teams. A2 (Incomplete multi-skill teams with feature focus) : These teams have a mix of skills but are not fully cross-functional. They also focus on specific features, similar to A1 teams, but with slightly more collaboration among team members. There were internal discussions, mainly about moving up from the A-level to the B-level. The B-level archetypes are more collaborative and aligned with business goals, promoting greater agility and responsiveness to market needs. For instance: B2 (Incomplete multi-skill teams with business area focus) : Teams that are not fully cross-functional but work more collaboratively across different business areas, fostering better alignment with business goals. B3 (End-to-end fast-flow teams with business area focus) : Highly cross-functional teams that manage entire business areas, promoting faster delivery and greater adaptability. During my observation, I noted a few things: Some people's perspectives were focused on their own team rather than the whole organization. For example, several stated that their teams wanted to advance to the B-level, but they did not seem to realize that this would require strong agreement and collaboration with the other teams. Most participants acknowledged the benefits of B-level teams but couldn't imagine what B-level or "a team of teams" would be like. Some people felt that staying at the A-level was also a viable option. They admitted that the teams were "optimized" and each individual team was quite productive. They mentioned that moving to the B-level would be costly. They and I had long discussions about what their organization's challenges were and what their goals should be. It took several months before they finally decided to "go up". 5 months later, in June 2024, there was the "Developer Productivity Conference", a Japanese domestic tech conference, where Hiroshi Ito (VPoE of Loglass), gave a talk. He introduced Org Topologies and their mapping activity from the beginning of 2024, where their teams were currently at A1-A2, and they decided to move to B2-B3. He went on to talk about scaling their agility and for the moment, they would be trying it based on the adoption of FAST Agile. FAST Agile is an approach that blends ideas from Kanban, Open Space Technology (OST), and Agile to create a lightweight, scalable framework. It emphasizes forming collectives, setting up the organizational foundation in a one-time setup, and continuously improving through a cycle called the Value Cycle. This cycle promotes self-organization, synchronized activities, and regular meetings to keep everything aligned. It might be a big challenge for Loglass, but I believe that the experience they gain from it would be a valuable asset. I also intend to actively support them going forward. 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.

photo by unsplash Background to the use case At the beginning of March 2024, I was lucky enough to join the very first OrgTopologies™ training course in France with the two co-creators Alexey Krivitsky and Roland Flemm. OrgTopologies™ map As is often the case, ideas evaporate after training courses. However, I had the opportunity to use this beautiful tool just three weeks later, during a workshop with a group working on a banking domain's information system. The scope of this domain was account management and the management of different payment methods (SEPA; IP; Virement Gros Montants...). The people working in this area bring together a range of fairly traditional skills, such as Business Analysis, programming in different languages, and Ops. These areas of expertise are sometimes in the same team, and sometimes in separate teams. Setting the scene Before the workshop, the sponsors requested to identify ways of "being more agile". I shared with them that gaining fluidity and the ability to change priorities was a way of qualifying and quantifying "being more agile". I began the workshop by telling the story of a startup I know in the C3 archetype. This startup was launched in 2013 by its two founders, who did everything for their first customers. As it grew, the startup changed its structure and ended up with several specialized teams, losing the global vision of the product and the initial fluidity. To illustrate the Y0 archetype, I evoked the caricature of the security expert who forbids everything to everyone. Next, I suggested that participants map out their current teams, working in groups to share their views on the place of different teams. To do this, I briefly explained the map using a 2x2 version of the map (showing only no team/team and outputs/outcomes) and then went into a finer level of detail with the map of the 16 archetypes in a 4x4 matrix. Blank OrgTopologies™ map The only people present were managers. Developers were not present. So we clarified the objective, which was to generate ideas for improvement. As many people were absent, I didn't want participants to commit to action plans involving those who were not present. Sub-group mapping The sub-groups raised subtle questions about the granularity of the definition of "Products". On the one hand, talking about "Products" that are too small (SEPA Transfer; IP Transfer; Large Amounts Transfer...) leads to very local optimization; makes us lose sight of the global vision; leads to the accumulation of work lists, queues, the need for a layer of coordination and priority arbitration... On the other hand, talking about "Products" that are too big (the Bank) becomes too abstract and makes employees lose touch with reality. I let them determine their approach to read the map, to encourage their involvement in the workshop, rather than adopting a "trainer" posture, which was not on the agenda. As a result, several tickets were placed at level B (team of teams or meta-teams, multi-functional and multi-technology) when it would probably have been wiser to place them at level A (group of teams more or less focused on distinct functionalities and areas). Other debates arose around the boundaries between columns 1 and 2 or even 3, which I have steered towards the "lower" archetypes to keep improvement options more visible. Current mapping The groups placed their tickets on the shared board and discussed to align their points of view. I launched a few discussions around certain teams identified as A1 or A2; B2 or C2, but decided not to waste our time on unimportant details for this first workshop. The participants appreciated this graphic representation, even if they didn't make any major discoveries, as the map was already partly in their heads. Next, we drew lines to clarify the interactions between the different teams, which will be invaluable for the idea generation that follows. Links between teams Based on these tickets and links, participants then discussed their options for improving and restructuring the teams in order to progress towards the higher-level archetypes, towards the right upper corner of the map. We can see here the grouping of three teams together (Business Analysts + Programmers + Ops), three times, as well as splitting an Ops team to quickly share its expertise. Ultimately, this should lead to the creation of multi-functional, multi-technology teams with broader scopes of responsibility and autonomy than initially envisaged. Final Org Topologies Map I didn't reveal my magic trick until the end of the workshop, only then mentioning that I had used the Org Topologies map. To conclude the workshop, I proposed a few questions for reflection, with a round-table discussion so that everyone could comfortably express themselves: what did the workshop reveal to me? What did I learn? Knowing that many people are absent, what could MY next action be (tell them about the card; repeat a similar workshop in a few months' time)? How do I feel now (confident; curious...)? Conclusion With this material produced, Roland Flemm subsequently helped me to clarify several points related to the map that emerged from the workshop, enabling me to better understand the map and improve future workshops. We've started a movement with a fairly simple workshop thanks to the map. We now need to maintain this momentum and support our teams in moving towards these higher-level archetypes. And you, in what context could you use this map?

Contexte du cas d'usage J'ai eu la chance de participer début mars 2024 à la toute première formation  OrgTopologies  en France avec les deux co-créateurs  Alexey Krivitsky 🌈  et  Roland Flemm   Carte OrgTopologies Comme souvent, les idées s'évaporent après les formations. Or j'ai eu l'opportunité d'utiliser ce bel outil seulement trois semaines plus tard, à l'occasion d'un atelier avec un groupe de personnes travaillant sur le système d'information d'un domaine bancaire. Le périmètre de ce domaine étant celui de la tenue de compte et de la gestion des différents moyens de paiement (SEPA ; IP ; Virement Gros Montants...). Les personnes du domaine regroupent différentes expertises assez classiques telles que Business Analyse ; programmation dans différents langages ; Ops. Les expertises sont parfois dans la même équipe, parfois dans des équipes distinctes. Mise en scène Avant l'atelier, la demande des commanditaires portait sur l'identification de piste pour "être plus agile". J'ai partagé avec eux que de gagner en fluidité et gagner en capacité à changer de priorité était une manière de qualifier et quantifier le fait "d'être plus agile". J'ai débuté l'atelier en racontant l'histoire d'une startup que je connais dans l'archétype C3, qui a été lancé en 2013 par ses deux fondateurs, lesquels faisaient absolument tout pour leurs premiers clients. En grossissant, la startup a changé de structure et s'est retrouvée avec plusieurs équipes spécialisées, perdant la vision globale du produit et la fluidité initiale. Pour illustrer l'archétype Y0, j'ai évoqué la caricature de l'expert en sécurité qui interdit tout à tout le monde. Ensuite, j'ai proposé aux participants de cartographier leurs équipes actuelles dans un premier temps, en travaillant par groupe afin de partager leur point de vue sur la place des différentes équipes. Pour ce faire, j'ai expliquer assez brièvement un premier niveau de lecture avec une carte 2x2 (no-team / team et livrables / bénéfices) et ensuite je suis allé dans un niveau de détail plus fin avec la carte des 16 archétypes dans une matrice 4x4. Map OrgTopologies d'exemple vierge Les personnes présentes étant les managers seuls. Les Développeurs n'étaient pas présents. Aussi, nous avons clarifier l'objectif qui était de faire émerger des idées d'amélioration. Beaucoup de personnes étant absentes, je ne souhaitais pas que les participants s'engagent sur des plans d'action impliquant les absents. Cartographie en sous-groupe Les sous-groupes ont apporté des questions subtiles sur la finesse du grain des "Produits". D'un côté, parler de "Produits" trop petits (Transfert SEPA ; Transfert IP ; Transfert Gros Montants...) conduit à de l'optimisation très locale ; fait perdre de vue la vision globale ; amène à l'accumulation de listes de travaux, de files d'attente, de besoin de couche de coordination et d'arbitrage de priorités... Et de l'autre, parler de "Produits" trop gros (la Banque) devient trop abstrait et fait perdre pied avec la réalité des collaborateurs. J'ai choisi de les laisser régler eux-mêmes leur curseur de lecture de la cartographie afin de favoriser leur engagement dans l'atelier, plutôt que de rentrer dans une posture de "formateur", ce qui n'était pas à l'ordre du jour. De ce fait, plusieurs tickets ont été placé au niveau B (équipe d'équipes ou méta-équipe, multi-fonctionnelles et multi-technologies) alors qu'il aurait probablement été plus judicieux de les placé au niveau A (groupe d'équipes plus ou moins focalisées sur des fonctionnalités et des domaines fonctionnels distincts). D'autres débats ont émergé autour des frontières entre les colonnes 1 et 2 voire 3. Je les ai orienté vers les archétypes "bas" afin de garder les options d'amélioration plus visibles. Cartographie actuelle Les groupes ont placé leurs tickets sur le tableau partagé, et discuté pour s'aligner sur leurs points de vue. J'ai lancé quelques débats autour de certaines équipes identifiées A1 ou A2 ; B2 ou C2, mais j'ai décidé de ne pas gaspiller notre temps sur des détails peu importants pour ce tout premier atelier. Les participants ont apprécié cette représentation graphique même s'ils n'ont pas fait de grandes découvertes car la carte était déjà partiellement dans leurs têtes. Ensuite, nous avons dessiné des lignes afin de clarifier les interactions entre les différentes équipes, ce qui sera précieux pour l'émergence d'idée qui suivra. Liens entre les équipes A partir de ces tickets et des liens, les participants ont ensuite échangé sur leurs options d'amélioration et de restructuration des équipes afin de progresser vers les archétypes de plus hauts niveaux, vers la droite et le haut de la cartographie. On peut observer ici le regroupement de trois équipes ensembles (Business Analysts + Programmeurs + Ops), trois fois, ainsi que l'éclatement d'une équipe Ops pour partager rapidement son expertise. A terme, cela devrait donner lieu à la création d'équipe d'équipes pluri-fonctionnelles et pluri-technologies ayant des périmètres de responsabilités et d'autonomie plus vastes qu'initialement. Carte finale OrgTopologies Je n'ai révélé mon tour de magicien qu'à la fin de l'atelier, en ne mentionnant qu'à ce moment là que j'avais utilisé la cartographie  OrgTopologies . Pour terminer l'atelier, j'ai proposé quelques questions de réflexion, avec un tour de table pour que chacun puisse confortablement s'exprimer : qu'est-ce que l'atelier m'a révélé ? qu'ai-je appris ? Sachant que de nombreuses personnes sont absentes, quel peut être MA prochaine action (leur parler de la carte ; refaire un atelier similaire dans quelques mois) ? Comment je me sens maintenant (plutôt confiant ; curieux...) ? Conclusion Avec ce matériel produit,  Roland Flemm  m'a aidé par la suite à clarifier plusieurs points en lien avec la carte qui a émergé de l'atelier, ce qui m'a permis de mieux comprendre la carte pour des ateliers futurs. Nous avons amorcé un mouvement avec un atelier assez simple grâce à la cartographie. Il nous reste à entretenir cet élan et à accompagner les équipes à monter vers ces archétypes de plus hauts niveaux. Et vous, dans quel contexte pourriez vous utiliser cette cartographie ?

Management Summary  Leaders set business objectives and define strategies to achieve them, yet often lack the tools to sustainably drive organizational performance. The good news is that this can be learned and thoughtfully applied today at organizations. Org Topologies (OT) will help you get the desired change going. How do you define and successfully lead the change that’s right for your organization? Here’s a key point: Different goals—rapid delivery, global adaptability, resource optimization, or amplified innovation—require different and tailored org designs. As a leader, you can define that goal and use the approach offered here to evolve your organization in the chosen direction.  Why does change fail so often? First, existing solutions may seem suitable when analyzed superficially, but, in fact, don’t fit your unique context. Second—an underappreciated factor behind failed change—people, when not owning the change ideas, won’t fully accept them and won’t go the extra mile to make them work. As a result, the promised benefits of change often remain unfulfilled despite all the wasted resources and opportunities. This case study explains how applying Org Topologies ensured that a company was implementing a correct organization design and how OT helped to introduce the change in the product development group. Strategic Org Design What is Org Topologies? Org Topologies (OT), being a strategic org design system, helps you align all the moving pieces so that your (1) business strategy, (2) organizational capabilities, and (3) change process work together cohesively to drive the desired organizational performance. Why Use Org Topologies? When organizations undergo transformations, choosing a framework like SAFe, Spotify, or LeSS alone may not be sufficient. OT helps identify if your new organizational design will genuinely solve the underlying issues or if it will fall short due to overlooked systemic challenges. OT helps companies align their internal structures with business goals, resulting in a performance boost, measurable by faster innovation and efficient delivery of customer value. Customer Case: Elevating XG Customer profile: XG (anonymised for confidentiality purposes), is a scale-up in the EV market. They provide an EV information platform and empower the most ambitious players to meet EV power demands. The challenge at XG  The business was growing fast, but the R&D department could not keep up with the growing demand for features. Although XG was the number one innovator in their market, they noticed that they were losing their pole position. Competitors were catching up in releasing new customer delighters. Growing the number of R&D employees did not solve the problem. The time to market for customer requests increased from weeks to multiple months.  XG management studied the possible causes for the declining delivery speed. Their R&D department consisted of 7 teams, each team responsible for one component of the complete XG solution. Their org design had grown organically over time, with its main driver being clearly defined component ownership by deep specialists. While growing from 8 to 50 people, the R&D group had turned into a collection of isolated silos.  The managing directors agreed on the need to improve the organizational performance. They would need to restructure the processes of the teams at R&D. Middle management (Head of Engineering and Head of Product) were tasked to implement a change to solve the problems.  The solution designed by XG To solve the performance problem, middle management informed themselves on existing frameworks. Before any external consultant was approached, they crafted a custom org structure for the R&D department by themselves. They anticipated implementing key characteristics of the LeSS Framework: removing Product Managers at the team level in favor of three product areas, with each one having a single Product Owner and multiple teams. They designed the product areas by customer type. Each area should work as a team of cross-functional teams. They had designed a new Target Operating Model and were looking for external consultants to implement the TOM and support them in improving their scaled Scrum processes.  Org Topologies It seems XG had found/created a solution that needed no further discussion. However, a closer look at the TOM revealed that implementing it would not result in a sustainable change.  Three observations led to this conclusion:  The TOM design did not completely resolve the root cause of the long time to market. The change was not systemic, meaning it focused only on restructuring R&D and did not yet consider other elements of the organizational design that influence organizational performance. Top management was very supportive, but not involved.  To address these challenges, we used the Org Topologie MADE method (Map Assess, Design, and Elevate) as a guide in our consulting and coaching activities. Map   We used Org Topologies to map the existing design and assess the future TOM. OT Mapping entails determining the prevalent archetype of each org design unit (teams, managers, etc) involved in the value creation chain and plotting them on the OT map.  Org Topologies mapping at XG, existing design The current design shows a Head of Product (H) working at the whole business level. He works with eight Product Managers (items with a P on the map) who work at the capabilities level, each responsible for one team (items with a T on the map, one color representing one capability).  Each team is locked to one component (capability) of the whole solution. And each team depended on (most of) the other teams to deliver customer value (depicted by the lines connecting the teams). Assess Assessing with the OT MADE Method consists of verifying if a design is fit for purpose. In this case, we asked ourselves if the new TOM XG was fit for purpose. Was the new org design the correct solution to achieve the business goals in their market? How well was the design understood, and how well did (upper) management know the change implications? Each org design provides certain organizational capabilities. Org Topologies proposes three recognizable topologies: The Resource Topology, the Delivery Topology, and the Adaptive Topology. The business ambitions and market conditions determine which organizational capabilities most likely support achieving our goals. In the XG case, the market was uncharted, finding new innovative solutions to win customers and being fast in delivering known solutions were required. The Adaptive topology can provide this.  Mapping the existing org design confirmed the root cause for slow value delivery: the dependencies between the teams caused hand-offs and coordination work.  We mapped the TOM proposed by XG. In the new design, the Head of Product works with three Product Owners, each for a specific customer type. Each PO has a group of teams working at the feature capabilities level.  Reducing the number of product managers and elevating them to manage three partial business areas was a great idea. However, having three product areas would not completely solve the inter-team dependency problem since product backlog items might span multiple areas. The middle managers acknowledged this problem, but this sub-optimal design was deemed to be a great improvement considering the component landscape they were coming from. Creating a single Backlog for the whole company was too big of a stretch for upper management at that moment in time. Design The Design phase explores options to consider which topology could best be implemented in which part of the business.  Mapping and assessing the XG target design demonstrated that the proposed TOM was the Adaptive Topology. They designed three product areas containing cross-component and cross-functional teams that worked as a team of teams per business area. Each team had the capabilities of delivering end-to-end functionality at the business area level. Note that the colors of the three teams in the new design are similar, since their only level of specialization is the focus on their business area.    Final design at XG Understanding how the new TOM would or would not improve the performance before the change is implemented is a great win. Discussions showed there was insufficient understanding at XG of how the adaptive org design would work in practice and that it was unclear what was needed to elevate the existing org design to the new TOM.  The Org Topologies mappings of the existing and proposed designs were extremely helpful in the sessions where we communicated the change with the development group. They had heard about the change initiative, but did not have a concrete idea of what the change would be like. Especially, the formation of new cross-functional teams was unknown to them. And yet, this was the most impactful change that would hit the teams. The mappings transparently explained that the existing component team ownership would be broken and replaced by end-to-end capable teams. Explaining the existing component team dynamics with the map, visualizing the inter-team dependencies, was a feast of recognition for the development group. Talking about expanding the mandate on skills and scope of work created the understanding of how to move forward to end their dependency hell. Explaining the current and future situation using the map has become an ongoing activity. Learning simply takes time and repetition. Elevate   The last step in the MADE method is Elvate. The Elevating Katas answer the question “But how are we going to do it?”. It is a rich set of practices that bring the ongoing transformation effort into business as usual.  We prepared the existing teams to be ready to work in the new business area team of teams. We flipped the organization in two days. We ensured everybody had time to work on the change preparations while the business as usual was going on before the flip. Time and effort were spent learning and preparing at the cost of a productivity loss. This is a necessary investment: slow down now to accelerate later.  We applied the following Elevating Katas to enable the flip to the new design:  Single product backlog at the partial business level Elevate three team PMs to partial business POs Promote remaining team PMs to become product developers Self-design team workshop to create new teams per area Elevate the Definition of Done to the whole business level Practice multi-team product backlog refinement sessions After the flip, the change work needed to continue using the Elevating Katas to execute smaller experiments to further improve the development system: Pair programming Mob programming Opening all repositories Communities of practice Code mentorship Integration test automation Architecture and knowledge sessions The results When the teams started working in the new setup, the performance increased dramatically.  Happiness has gone up for almost all employees. However, some devs have difficulty accepting shared code ownership and broadening the mandate on the business domain. Some single-skill specialists struggled to find their new purpose outside of their comfort zone. Initially, upper management was thinking lightly of the impact of the anticipated (process) changes in R&D. During the change process, they started seeing the impact of the transformation and the need for employee buy-in to embark on a never-ending journey of continuous improvement. They enjoyed the energy of the people crafting their journey within the boundaries set by management. The Support department was onboarded and included in the change, not only to manage their expectations, but also to involve them during refinements and Sprint Reviews. The Map, Assess, Design, and Elevate steps brought the client from supporting the change initiative by funding it, to being involved by understanding the change. The MADE method revealed omissions in the target design and demonstrated the complexity of the change..  We used the OT mapping in various workshops to explain to the employees the current design and the new org design. The visualizations are a powerful means of communication to bring understanding of the why and what of the change. We emphasized that elevating a development group impacts how the company sells its product, hires new people, provides support, and manages its human capital. Org Topologies elevated managers and employees to become systems thinkers.

Une organisation choisie ou subie ? Toute entreprise a une organisation (structure) qui a tendance à guider les interactions entre ses membres. Ces mêmes interactions font circuler de l’information et orientent le travail effectué. La définition, la mise en place et le maintien de l'organisation dans le temps peut être contrôlé par sa tête mais également évoluer de manière organique et décentralisée avec les années au sein de grosses structures. Quelle que soit la manière dont cette organisation évolue, elle aura toujours un effet sur la circulation de l'information et des travaux. Cet effet sur la capacité organisationnelle est alors non négligeable. Si cette organisation est importante, il convient alors de ne pas la subir et d'effectuer des choix pour mettre la structure dans de bonnes dispositions pour parvenir à ses fins. Tout comme les formations des légions romaines, les tactiques des équipes de sports collectifs ou les formations aériennes de l'armée de l'air, agencer différemment les mêmes unités permet de faire face à des situations différentes. Photographie d'une formation aérienne, schéma d'une formation d'équipe de football et extrait d'une reproduction d'une formation de légionnaires romains Dès lors, il vient la question suivante : mais quelle organisation adopter ? Pas de bon choix sans objectif #StartWithWhy Afin de trouver une organisation pertinente, il est nécessaire de connaître le but qui souhaite être atteint par le système que l'on souhaite réorganiser. Plus de rapidité à livrer ? Plus d'apprentissage ? Une plus grande richesse d'opinions ? Une réduction des coûts ? Quelle que soit la motivation ou l'objectif à l'origine d'un changement d'organisation, il est primordial de le formaliser puisque c'est cet élément qui permet de guider les choix d'organisation par la suite. Dans notre exemple, nous choisissons  une réduction du Time-to-market. Mais comment Org Topologies™ peut contribuer à cela ? Org Topologies™ offre un outillage léger pour cartographier et évaluer son organisation afin d'envisager la direction souhaitée des modifications organisationnelles. C'est tout simplement un outil de réflexion pour faire un pas dans le design organisationnel.  L'outil clé d'Org Topologies™ est une carte bi-dimensionnelle avec une dimension représentant l' étendue des capacités  et une seconde représentant le  périmètre d'activité. Les deux dimensions de la carte Org Topologies™  En simplifiant la matrice 4x4 en matrice 2x2, on facilite l'entrée en matière  Visualisation de la simplification Etat des lieux : où en sommes nous aujourd'hui ? Avant de déterminer un chemin d'amélioration, il est nécessaire de dresser une représentation fidèle de l'organisation telle qu'elle est au démarrage des réflexions. Pour cela, nous pouvons utiliser la carte d'Org Topologies™.  Vous retrouvez dans l'image ci-dessous l'exemple de l'organisation autour d'un produit. Cet exemple est un cas hypothétique basé sur des cas que j'observe sur le terrain. Exemple de cartographie avec la carte d'Org Topologies™ Selon la matrice simplifiée (2x2), nos équipes se répartissent comme suit : FLOW-BÉNÉFICES  : --- RESSOURCES-BÉNÉFICES  : Architecte, groupe métier RESSOURCES-LIVRABLES  : Groupe d'analystes, production FLOW-LIVRABLES  : "Équipe Scrum" incomplète Notons ici que pour des raisons de simplicité, il n'y a qu'une seule "équipe Scrum". Cela peut correspondre au développement d'un petit produit. Dans le cas où il y aurait plusieurs "équipes Scrum", il serait possible qu'elles ne soit pas toutes placcées au même endroit de la carte.  (J'utilise des guillemets autour d'équipe Scrum car ces équipes ne sont pas réellement pluridisciplinaires) Envisager des adaptations d'organisation Une fois l'état des lieux réalisé, il est possible d'envisager des modifications. Dans notre cas, nous voulons réduire notre  Time-to-market . Actuellement, il y a de l'attente entre le groupe d'analyses, "l'équipe Scrum" et la production. Nous faisons l'hypothèse que rassembler ces personnes en une seule et même équipe permettra d'accélérer la chaîne et donc le  Time-to-market . Après cette modification, nous avons une équipe Scrum qui dispose de toutes les compétences pour aller de l'analyse jusqu'à la mise en production. Cette équipe passe donc en A3 : Unité à débit rapide avec un focus fonctionnalités. On peut se demander pourquoi cette équipe Scrum ne passe pas au niveau  B3 . La raison est que le Product Owner de cette équipe n'est pas investi au niveau du domaine d'activité pour le moment. Le groupe métier qui est en  B1 , réalise un travail préparatoire qui fait que dans ce cas, le Product Owner n'a pas la responsabilité.  Exemple de modification possible visant à améliorer le Time-to-market. Mesurer l’efficacité de sa formation vis-à-vis de l’objectif Comme tout changement dans un environnement humain présente un haut niveau d’incertitude, il est judicieux d’évaluer a postériori l’effet des modifications effectuées dans l’organisation. Premièrement, il est incontournable de mesurer l'indicateur que l'on vise à améliorer avec nos changements organisationnels pour voir à quel point les modifications ont été pertinentes. Si ce premier indicateur à mesurer peut paraître évident, j'aimerais également souligner l'importance de mesurer d'autres indicateurs pour évaluer des effets imprévus à l'origine. Dans notre exemple, nous voulions réduire le  Time-to-market . En le mesurant avant modification puis un mois après la modification d'organisation, nous nous apercevons que nous l'avons réduit de 20%, génial ! Par contre, qu'en est-il de la qualité des livrables, de la valeur apportée, de la satisfaction des collaborateurs ? Notre organisation est un système complexe, (présentant beaucoup d'incertitude) ce qui signifie qu'il est difficile (impossible, en réalité) de prévoir les conséquences d'une action, aussi bonne soit l'intention de départ. Pour trouver l'équilibre entre les différents indicateurs, utiliser le cadre Evidence-Based Management (EBM) de  Scrum.org , peut être judicieux pour s'astreindre à une rigueur d'expérimentation ainsi qu'à une balance entre indicateurs de valeur et indicateurs de capacité organisationnelle.  En se référant à EBM, on divisera donc nos indicateurs en deux grandes catégories, elles-mêmes découpées en deux sous-catégories, appellées domaines de valeur clés (KVA) : Valeur marchande :  Valeur actuelle  (CV),  Valeur non-réalisée  (UV) Capacité organisationnelle :  Capacité à innover  (A2I),  Time-to-market  (T2M) Donc, dans notre cas, Le  Time-to market  est sous les projecteurs. On peut par exemple suivre le Lead Time ou le Mean time to Restore (tiré des métriques DORA). Pour assurer l'équilibre, il nous faut alors des mesures dans les autres domaines de valeur clés comme par exemple : la satisfaction utilisateur pour la  Valeur actuelle les parts de marché potentielles pour la  Valeur non-réalisée la tendance des bugs pour la  Capacité à innover L'utilisation d'Org Topologies™ couplée à EBM fera sûrement l'objet d'un prochain article. Il est important de noter qu'en fonction des modifications effectuées, les effets peuvent mettre plus ou moins de temps et être plus ou moins difficiles à observer. Conclusion Il est judicieux d'adapter l'organisation de son entreprise, de sa business unit, d'un ensemble d'équipes développant un produit pour atteindre au mieux ses objectifs. Pour faire cela, Org Topologies™ offre un outil intéressant pour faire l'état des lieux et esquisser les changements envisager pour atteindre son objectif. C'est alors l'expérimentation et la mesure régulière de la performance de l'organisation qui permet de naviguer dans l'incertitude, avec la carte d'Org Topologies™ pour dessiner ses expériences et des indicateurs pour assurer la tenue du cap. Toutes les étapes présentées plus tôt peuvent se réaliser avec différentes populations. Il y a un monde entre faire cet exercice seul en chambre ou le faire en présence de l'ensemble des personnes présentes dans le dispositif étudié. Aucun de ces deux extrêmes ne me semble pertinent. Pour sélectionner les personnes, je vous invite à avoir à la fois des personnes dans les archétypes les plus bas (Y & A) ainsi que dans les archétypes les plus haut (B & C) afin de croiser les perspectives qui peuvent être bien différentes.

A chosen or imposed organization? Every company has an organization (structure) that tends to guide the interactions between its members. These same interactions circulate information and guide the work performed. The definition, implementation and maintenance of the organization over time can be controlled by its head, but can also evolve organically and decentralized over the years within large structures. Whichever way this organization evolves, it will always have an effect on the flow of information and work. This effect on organizational capacity is therefore not negligible. If this organization is important, then it's important not to suffer from it, and to make choices that put the structure in a good position to achieve its goals. Just like the formations of the Roman legions, the tactics of team sports teams or the air formations of the French air force, arranging the same units differently enables us to deal with different situations. Photograph of an aerial formation, diagram of a soccer team formation and extract from a reproduction of a Roman legionary formation. The question then arises: what kind of organization should we adopt? No good choice without a goal #StartWithWhy To find the right organization, you need to know what you want to achieve with the system you want to reorganize. Faster delivery? More learning? A greater wealth of opinions? Lower costs? Whatever the motivation or objective behind an organizational change, it's vital to formalize it, since it's this element that will guide subsequent organizational choices. In our example, we have chosen to reduce time-to-market . But how can Org Topologies™ contribute to this? Org Topologies™ offers a lightweight tool for mapping and evaluating one's organization in order to envision the desired direction of organizational change. Quite simply, it's a thinking tool for taking a step into organizational design. The key tool in Org Topologies™ is a two-dimensional map with one dimension representing the scope of capabilities and a second representing the scope of work . The two dimensions of the Org Topologies™ map Simplifying the 4x4 matrix into a 2x2 matrix makes it easier to get started: Simplified visualization Where do we stand today? Before determining an improvement path, it is necessary to draw up a faithful representation of the organization as it is at the start of the reflections. For this, we can use the Org Topologies™ map. In the image below, you can see an example of our organization for which we want to accelerate time-to-market. This example is a hypothetical case based on multiple cases I've observed in the field. Mapping example with Org's Topologies™ map Note that for simplicity's sake, there is only one "Scrum team". This may correspond to the development of a small product. If there are several "Scrum teams", they may not all be placed in the same place on the map. (I use quotation marks around Scrum team because these teams are not really fully multidisciplinary). Consider organizational adaptations Once we've assessed the situation, it's time to make some changes. In our case, we want to reduce our time-to-market. At present, there is a backlog between the analysis group, the "Scrum team" and production. We hypothesize that bringing these people together into a single team will speed up the chain, and therefore time-to-market. After this modification, we have a Scrum team with all the skills needed to go from analysis to production. This team has therefore been upgraded to A3 : Rapid throughput unit with a focus on functionalities. One might ask why this Scrum team isn't moving up to B3 . The reason is that the Product Owner of this team is not invested in the business area at the moment. The business group, which is in B1 , is carrying out preparatory work, which means that in this case, the Product Owner does not have responsibility for the business area. Example of a possible modification to improve time-to-market. Measure the effectiveness of your change in relation to the objective Since any change in a human environment involves a high degree of uncertainty, it makes sense to evaluate the effect of changes made in the organization a posteriori. Firstly, it's essential to measure the indicator we're aiming to improve with our organizational changes to see how relevant the modifications have been. While this first indicator to be measured may seem obvious, I'd also like to stress the importance of measuring other indicators to assess effects that were originally unforeseen. In our example, we wanted to reduce time-to-market. By measuring it before and one month after the organizational change, we found that we had reduced it by 20% - brilliant! But what about the quality of deliverables, the value provided, employee satisfaction? Our organization is a complex system (with a lot of uncertainty), which means that it's difficult (impossible, in fact) to predict the consequences of any action, no matter how well-intentioned. To strike a balance between the various indicators, using Scrum.org's Evidence-Based Management (EBM) framework can be a good way to ensure rigorous experimentation and a balance between value indicators and organizational capacity indicators. Referring to EBM, we will divide our indicators into two main categories, themselves divided into two sub-categories, called key value areas (KVA): Market value: Current value (CV), Unrealized value (UV) Organizational capacity: Ability to innovate (A2I), Time-to-market (T2M) So, in our case, Time-to-market is in the spotlight. We can, for example, track Lead Time or Mean time to Restore (taken from DORA metrics). To ensure balance, we then need measures in other key value areas such as : user satisfaction for Present Value potential market share for Unrealized Value bug trends for Capacity for Innovation The use of Org Topologies™ coupled with EBM will surely be the subject of a future article. It's important to note that, depending on the modifications made, the effects may take longer or be more or less difficult to observe. Conclusion It's a good idea to adapt the organization of your company, your business unit, a group of teams developing a product, to best achieve your objectives. Org Topologies™ offers an interesting tool for assessing the situation and outlining the changes needed to achieve your objectives. It's then experimentation and regular measurement of organizational performance that makes it possible to navigate uncertainty, with the Org Topologies™ map to draw one's experiences. All the steps presented earlier can be carried out with different populations. There's a world of difference between doing this exercise alone in a room, or doing it in the presence of all the people present in the device under study. Neither extreme seems relevant to me. To select the people, I suggest you have both people in the lowest archetypes (Y & A) as well as in the highest archetypes (B & C), in order to cross the perspectives, which can be quite different. 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.

This video features Mauro Sacchi discussing a significant change initiative within his company. The focus is on transitioning product development to be more aligned with business objectives and customer value. The Org Topologies mapping method is used as a tool to visualize and guide this organizational transformation. Company and Product Context: The company is a large, 190-year-old multinational corporation operating in the maritime and energy sectors, transforming energy into power [ 03:09 , 03:47 ]. It heavily invests in R&D, viewing itself as an innovator [ 08:00 ]. Their digital products are integrated into their lifecycle business, primarily related to engine technology [ 07:20 ]. The product architecture spans industrial equipment with automation, edge solutions, and cloud-based solutions [ 10:00 ]. Different user needs (on-site vs. office-based) shape solution design and deployment [ 13:12 ]. The Transformation Journey: Initial State:  The organization began with a resource topology, characterized by "doers" and "directing" archetypes [ 16:42 ]. Challenges included software engineering being treated as a service provider, fragmented requests, and isolated teams [ 21:11 ]. Desired State:  The goal was to move towards an adaptive topology by integrating "doing" and "driving" archetypes [ 16:17 ]. This involved a shift to a single product owner, broader product thinking, and product managers focusing on product management over project management [ 36:16 ]. The vision included more self-managing teams working directly with customers and owning the entire product [ 39:45 ]. Investments were made in scrum masters, agile coaches, and people management to support this [ 42:35 ]. Current Reality:  The transition has created "positive friction" in prioritization and mandate, leading to better dialogue and decision-making [ 51:41 ]. Teams are progressing towards effective delivery, with varying levels of maturity [ 52:54 ]. The current focus is on transparency, problem-solving, and continuous improvement [ 55:48 ]. Key Learnings and Insights: Software engineering should be viewed as a core discipline, not just a service function [ 33:38 ]. A product management mindset is crucial for sustainable product development, rather than a project management approach [ 29:06 ]. The Org Topologies is valuable for visualizing and managing organizational change [ 15:06 ]. Organizational change is an ongoing process requiring continuous adaptation and learning [ 01:02:04 ]. Leadership plays a critical role in fostering an environment where teams can succeed [ 01:05:08 ]. Integrating diverse engineering domains (software, hardware, mechanical) presents challenges [ 01:16:46 ]. Balancing agility with safety is essential in regulated environments [ 01:11:27 ]. Organic learning time and the impact of product expansion on team capabilities are important considerations [ 01:27:07 ].