Marcelo Ancelmo

Hi everyone. Good morning. Thank you for having me here today. My name is Marcelo Ancelmo. I work as Head of Solution Architecture at KPMG Switzerland. Today I'm going to present to you our experience in implementing product management, engineering management, and solution architecture all together — and how we are using Team Topologies to match all of those capabilities together to achieve better outcomes.

01KPMG Switzerland context

For those few that don't know, KPMG is a partner-based network of companies. In Switzerland it's been present for more than 100 years. We currently announced we are merging our business with KPMG UK. We are all looking forward to what this will bring to us as a member firm. We have a very strong business in Switzerland, a good number of customers that rely on us to deliver our services to them and to do our work.

[Slide: 2600+ employees, 145 partners, 59 nationalities, 11 locations across Switzerland (Basel, Zurich, St. Gallen, Bern, Geneva, Lausanne, Lugano, etc.), 34 average age, 42% women / 58% men, 18% part-time. Global Organizational Network: 143 countries, 273,424 people, EMA 153,178 / Americas 62,781 / Asia Pacific 57,465. >70 strategic alliances including Microsoft, Google, ServiceNow, SAP, Salesforce, IBM, SailPoint.]

02A journey of reflection started at DOES23

This is not the first presentation we are doing here on a DevOps Enterprise Summit. We already presented some things we are doing on our journey transforming our technology department — our digital business technology department — at KPMG Switzerland. The core of this presentation today is based on a lot of feedback we received from the presentation we did last year here in Las Vegas about how we are implementing Team Topologies at KPMG Switzerland.

[Slide references DOES23 Amsterdam "Dare to Do — Multi-disciplinary Digital Ecosystem and DevOps at KPMG Switzerland" and DOES23 Las Vegas "Tips and Tricks to Successfully apply Team Topologies."]

03The Multi-Disciplinary Team (MDT) — collective ownership, leading over leader

This all starts on a very core concept that we have inside our team — the Multi-Disciplinary Team (MDT).

The MDT is responsible for owning the whole product. The first big change we made was to shift from a project-management mindset to a product-orientation mindset. The first thing that happened was introducing the concept of the Product Manager — the one responsible for owning the features of the product, dealing with the core stakeholders the product is delivering value to, and understanding from end users how is the experience that they have using our product.

The other angle of the triangle is the Solution Architect — responsible for the design, the quality of the solution, the user experience. He is the one responsible to own the whole quality, the whole solution from the architectural perspective.

And last but not least, the third angle is the Engineering Manager — responsible to guarantee the delivery of the product with good quality, with the quality building blocks, the standards set by the Solution Architect, addressing all features required by the end users.

Those three people — playing those three roles — have the collective ownership of the product. They are all responsible to make sure, from the user perspective, the engineering perspective, the quality perspective, that the product is delivered as expected and that it can provide the expected value.

Because of this, it is paramount that this MDT — or, as some people like to call it at KPMG, our product triangles — needs to have full accountability for what they are building. They own it, they build it, they run it. They also need to be committed to all of those specs — quality, end-user capabilities, engineering excellence. And the most important thing, the basis that keeps these three people together and that makes them thrive is trust. Each one of them trusts that each role is playing what they are expected to do, that they are talking with each other, they collectively own the product. So if anyone sees a problem, they get together and they work together to find a solution for it.

[Slide: Triangle with Outcomes (Value) — Product Manager at top; Outputs (Flow) — Engineering Manager at bottom-left; Design (Quality) — Solution Architect at bottom-right. MDT in the center with "Build it, run it, own it." Pillars: Commitment, Accountability, Trust.]

04…but beware of the positioning

But there is a catch. Collective ownership may be seen by the whole team delivering that product — the engineers working on the development of that product — as the MDT controlling and commanding what the team should do. This is not what the MDT is.

Others may see the MDT as only there when they have a question, when they need an SME to solve a problem or clarify a question — kind of a support function. The MDT is not there to just show up every other day and do some kind of support.

The MDT is part of the team. They are embedded inside the team. They are, as everyone else, delivering the product — team members.

[Slide: Three positioning patterns — Command (red ×), Support (red ×), Embedded (green ✓). The Embedded view shows the MDT triangle on top of three vertical product-team columns, signaling integration rather than command-and-control or external support.]

05The MDT acts as an Internal Enabling Team of the domain

When we look at the MDT and align this structure to Team Topologies, our reflection is that the MDT in reality is an enabling structure inside the team.

Why is it important to keep in mind that the MDT acts as enablers? Because they have been trained — they have been enabled — by another structure that we have inside KPMG Switzerland, which is our Enabling Services team.

This is a pure Enabling Team from a Team Topologies perspective. The Enabling Services team is responsible to prepare, to enable other people — and in this case enable the MDT in all principles and practices that govern our delivery structure. So everything from Agile, Enterprise Architecture, Solution Architecture, engineering practices, DevOps, SRE, software engineering — this team prepares a multidisciplinary team to be the inside enablers of the product team.

[Slide: Enabling Services and MDT shown as two interacting boxes, with the Enabling Services team's capabilities listed: Agile, DevOps, Engineering Management, Product Management, Solution Architecture, Software Engineering, SRE.]

06Facilitate the work of Stream-Aligned Teams

Now the product team — when we look inside it — is delivering to a specific domain. The product team is focused on a core domain, and this core domain is structured in multiple Stream-Aligned Teams. Those Stream-Aligned Teams are focused on one specific value stream.

You have the MDT (Solution Architect, Product Manager, Engineering Manager) working with the Stream-Aligned Teams of their domain to make sure they are focused on the delivery, focused on the value stream, focused on the core domain that they are working on.

Why did we decide that the MDT is part of the team — and inside the team, they are the enabling team? Because we all build software here, and we all have at some point to deal with dependencies — those dependencies being external or internal. If you put the Stream-Aligned Team to stop every other day to talk with someone from the platform team, to talk with someone from some supporting or generic subdomain, they would lose focus.

So the MDT, as an enabler, acts as a beacon, as a connector to the Stream-Aligned Team. Every time they identify something — oh, I need to talk with someone from platform — they can bring it together. It is a single team. They don't just hand over to the MDT, 'you need to go talk to those guys.' No — they raise their hand. They say: 'Look, identified that we are missing something from this specific supporting domain, and I need your help so we can go there and solve that problem.'

[Slide: MDT (Core) on the left, with arrows to Stream Aligned Team 1 and Stream Aligned Team 2 (both Value-Stream-Oriented, Core Domain) on the right. Facilitation interaction mode shown between MDT and Stream-Aligned Teams.]

07Collaboration amongst MDTs — defined via Team APIs

At a very high level, we have multiple MDTs and they collaborate with each other to remove dependencies that naturally exist between the different products. We have a huge collection of MDTs, a huge collection of products. Those products are owned by one specific MDT. And when they need to talk with each other, they use the published Team APIs.

By far, Team APIs is one of the most successful assets we created to enable great communication between the teams at the MDT level. They can talk to each other, they know who they can talk to, they know who they should talk to.

As an example: if the Solution Architect from the core domain needs a new API definition from a generic domain, they can connect to the Solution Architect of that specific data product and they can work together on this new interface definition. Team APIs are a very important and strong asset for the product teams.

[Slide: Two example Team APIs — one for the "Platform Services" team (showing fields like Team name and focus, Team type: Platform, Part of a Platform Group?, Do we provide a service to other teams?, Service Level Expectations, Software owned and evolved, Versioning approaches, Wiki search terms, Chat tool channels, Time of daily sync meeting, plus tables of "Teams we currently interact with" / "Teams we expect to interact with soon") and one for "ECM Services Team API" (Team name: Enterprise Services, Sub team: Enterprise Content Management Services Team, Team type: Complicated Subsystem Team, Team lead: Nicolas Wochner, Team interaction modes for Templafy/iManage/SafeHouse, Product Portfolio). Based on template: https://github.com/TeamTopologies/Team-API-template]

08Collaboration with other Stream-Aligned Teams

When we say I have a Stream-Aligned Team responsible to deliver my core domain, and they are collaborating with another Stream-Aligned Team of a supporting domain — it means we have the MDTs of both products collaborating to make sure that both Stream-Aligned Teams are delivering the value stream. Our focus is on the value stream delivery.

[Slide: MDT (Core) facilitates Stream Aligned Team 1 (Core Domain), which collaborates with Stream Aligned Team (Supporting Domain) via the Collaboration interaction mode.]

09Collaboration with Complicated Subsystems

When you expand the concept, regardless of the type of team you are interacting with, you can always rely on that model. You always have a product team; you always have an MDT.

In this example, the Stream-Aligned Team of the core domain, while working on their value stream, identified: oh, we need collaboration with a Complicated Subsystem — the Security Complicated Subsystem. Let's get together, let's collaborate, to find the impediment that is showing up and to enable the delivery of that value stream.

[Slide: MDT (Core) facilitates Stream Aligned Team 1, which collaborates with Security (Generic, Complicated Subsystem).]

10Collaboration and Services from Platform Team

The same happens with platforms. You have your platform team — they are working on delivering your cloud platform. Our strategy is very strong and reliant on a cloud-based platform. We are moving to a full cloud environment. And the same happens there — I have a multidisciplinary team inside the platform team. Those MDTs are collaborating. They are deciding on which services from the platform need to be used, or which services of the platform need to be built in order to be used.

[Slide: MDT (Core) → Stream Aligned Team 1 (Core Domain). Cloud Platform (Generic Domain) provides X-as-a-Service to the Stream Aligned Team, with Collaboration interaction mode at the boundary.]

11Complete view of teams

When you see the complete picture, with the concept in mind that the MDT is enabling their teams — at the center you have the core domain being delivered. To deliver that value stream I need to work with multiple different teams. I need to engage with multiple MDTs. I need to rely on those MDTs — on those product Team APIs — and I need to do all that I can to break as much as possible those dependencies.

We don't want to have those strong dependencies. Our overall principle is that as soon as any dependency is identified between two different MDTs, they should work together to find a way where an API can be built, and shift the interaction style over time from Collaboration to Service Consumption (X-as-a-Service). Dependencies, we are breaking them as soon as possible, as fast as possible, moving to a full service-orientation style of interaction.

[Slide: Complete View of Teams — MDT (Core) facilitates Stream Aligned Team 1 (Core Domain). Above: Stream Aligned Team (Supporting Domain) enabled by MDT (Supporting), Security (Complicated Subsystem) enabled by MDT (Generic). Below: Cloud Platform (Generic Domain) enabled by MDT (Generic).]

12Challenges

Now, what are the challenges we identified while exercising that model?

- Novelty of MDT and Team Topologies are two hard pills to swallow (Where is my Project Manager?) — MDT and Team Topologies are completely new concepts. A lot of organizations implementing both of those chains at the same time created a lot of confusion. At the beginning a lot of people asked: 'Okay, where is my Project Manager? Why don't I have a Project Manager? Why are you telling me that Project Managers are not required anymore?' The role of Project Manager doesn't exist anymore inside our department. The management of a project, when it happens, it happens via the MDT — because the orientation is shifted from project to product.

The Team Topologies model is also something that's hard for some people to get, especially when they see value stream orientation. We say, 'Look, this Stream-Aligned Team is delivering this full value stream end-to-end.' And the first question they ask is, 'Well, okay — where is the front-end team? When are you going to put the front-end team to talk to those guys?' Say, 'No, no, no. Front end is part of the value stream. So it's being delivered by this Stream-Aligned Team.'

- Difficulty to reach out to some Complicated Subsystem teams (Ask your Project Manager?) — Especially Complicated Subsystem teams that are not part of the IT organization. On my example I used Security — Security is part of your IT organization and they are embracing the model. But when you need to talk with the legal department, with compliance, and you need them to collaborate with you, they turn back to you: 'Okay, ask your project manager to come and talk to me.' And then you say, 'No, no, look — we don't have a project manager. We are responsible for the project here, or whatever you want to call a project. We are the people you need to talk to. We, the MDT, are playing this role.'

- Misalignment of internal Stream Aligned teams (Teams are focused, but may be disconnected) — On the internal view I showed two Stream-Aligned Teams delivering the core domain. Our experience so far is showing us that to really stay focused, and to keep the boundaries of the domain manageable, right now two concurrent Stream-Aligned Teams delivering two value streams is working well.

At the beginning we identified that yes, the teams are focused, but they are kind of always relying on the MDT to talk with the other Stream-Aligned Team when they needed to do something together. Remember, the MDT-as-a-supporter is not what we are trying to achieve. So at the beginning, or when you have concurrent Stream-Aligned Teams delivering your core domain, they may become disconnected because they will wait for the MDT to do their work. This was a big finding, and we are currently doing some experiments to find a proper way to solve that problem. Right now it seems that including the MDT as part of that core domain helps — but it also creates another attention point, which is increased cognitive load inside the MDT.

- Internal processes and policies may not be ready for the MDT model — We may need to review some processes that say, e.g., 'Change management to deploy to production can only be approved by a Project Manager.' There's no Project Manager who's going to approve that. So your change just stays there for a while.

- MDT is exposed to increased cognitive load! — It is critical and extremely important to pay attention to the cognitive load of the MDT. They are part of the team. They are delivering together with the Stream-Aligned Team — the value stream, the core domain. But because they're also collaborating, or facilitating the collaboration with other teams, and because they sometimes need to do internal coordination, we need to be extremely careful on cognitive load. It's easy for the Stream-Aligned Team to just drop on the MDT everything they believe is their responsibility. So we are trying to find this sweet spot on this structure to make sure that cognitive load inside the MDT is within healthy boundaries.

13Key takeaways

- Stream-Aligned Team delivers the value stream. NO HANDOVERS! — If at any point in time there is a handover ('yeah, QA team needs to test this feature in QA' — so you broke the Stream-Aligned Team; 'yeah, I need to ask the front-end team' — Stream-Aligned Team is broken; 'I need to ask the DBAs to perform that change on my DB' — no, no handovers). End-to-end ownership. - Team APIs allow easier communication between product teams — I already mentioned that, and I will say it again: it is an amazing asset to have. It helps so much. Team APIs on the wiki, where everyone should have full access. There's no point in having a Team API beed-down on a Word document in someone's SharePoint site that no one can access. This doesn't work. While it may work for some people that don't want to be contacted, that is not the objective here. Team APIs are extremely powerful — make use of them. - Experiment, Inspect, Learn and Adapt! — It is a continuous feedback loop. We are always finding something. We are always getting together and saying: 'Look, I know that you just delivered this important value stream to one key product. How was it? Did you find anything difficult? Was there any impediment? Anything inside our model — be it the Multi-Disciplinary Team, be it the way that we apply Team Topologies — is there anything there that instead of helping you became a bottleneck, became an impediment? So let's revisit that. Maybe the approach was wrong, maybe applying the concept went on the wrong direction.' Continuous feedback, continuous experimentation — this is extremely powerful.

14Be grounded on a great body of knowledge

We are not doing anything that's not available at large. We have some core principles that are based on knowledge that is available to all of us. We have some key concepts that we are borrowing from some very intelligent people that were kind enough to publish things that we can rely on. Here are some examples — focus on product management, solution architecture, engineering management. We know how important MDTs are and how powerful they are, and how making sure they are working together at their best only benefits the product.

[Slide: Book covers — The Five Dysfunctions of a Team (Patrick Lencioni), Domain-Driven Design (Eric Evans), Continuous Discovery Habits (Teresa Torres), Team Topologies (Matthew Skelton & Manuel Pais), Pete Hodgson's Engineering Management (sketch), The Software Architect Elevator (Gregor Hohpe) — all surrounding the MDT triangle.]

15We would like to connect and learn from you …

- Experience of applying DevOps engineering practices in 'not-entirely-dev-shop' scenarios — KPMG is essentially a consulting company. The technology department is not the core business. So we are implementing a change from inside out, but we are not pure dev shops. Specifics in domains of risk & compliance, SaaS & COTS, workplace technology, no-code/low-code platforms, etc. - Battle stories from adoption of product orientation in service industry — While there is work through #project-to-products, #BVSSH and #VSMConsortium, dialog here will help to understand your experience. - Team Topologies @ scale, beyond single product/service boundaries — How do organizations adopt Team Topologies for reorientation of mid-to-large-scale portfolios? Implementing Team Topologies at scale, and how we are breaking the silos and breaking the barriers between the different departments that are not embracing that organizational model yet. - Connect and Reflect — With fellow practitioners in a similar journey. https://www.linkedin.com/in/marceloancelmo/

16Close

[Slide: Photo of KPMG Switzerland building overlaid with Mel Conway quote] "Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design." — Mel Conway. #daretodo #together4better #valuestreams #teamtopologies #DDDesign #ETLS2024 @marceloancelmo

Thank you.