Marcelo Ancelmo

Welcome, everybody. Thank you. Welcome, welcome for coming.

This is our session about our experience implementing Team Topologies at KPMG Switzerland. Today I am together with Dinkar to present our lessons learned, our takeaways, and where we are on the journey so far.

I am Marcelo, Head of Solution Architecture in KPMG Switzerland. Dinkar is our CIO and CTO.

For those of you that don't know KPMG, we are one of the Big Four. In Switzerland, we have almost 2,500 employees. Our headquarters is in Zurich, and we have offices in 11 locations across the country. We support primarily KPMG Swiss clients, but also global clients that have their headquarters in Switzerland.

This presentation is a continuation of what we presented in Amsterdam this year. We presented the whole framework that we are implementing in KPMG Switzerland that is based on Team Topologies, on Project to Product, and also Better Value Sooner Safer Happier.

After our presentation, we got a lot of positive feedback and a lot of questions about how we are doing Team Topologies, how we are organizing ourselves, what we already learned from what we are applying. Then we decided to continue this conversation, focusing on the new presentation, just looking at our Team Topologies experience and implementation.

If you want to know more about our previous presentation, this QR code takes you to the IT Revolution library, where you can see the presentation that we did in Amsterdam.

Now I will hand over to Dinkar, where he can talk about how we are organizing ourselves for fast flow.

Dinkar Gupta

Thanks.

There are two parts to the story today. One part is how we are doing it, how we are organizing, and what are the key takeaways. Then, of course, we'll take you through a case, how it's actually being done for one of the systems.

Let me quickly walk you through what we did.

When we started this journey about 18 months ago, that's where we were in our classical IT organization, which has two things: make sure IT is running well, it's efficient, it's not too costly, and it supports the business in doing what the business is doing.

The model here is representative of the last 20, 30 years. Most of the IT organizations have been there. There are some people who are interfacing with so-called business, who work with them on typically what's called demand management, what the business needs. There's a team which occasionally engages in projects doing what the business needs, and an extremely strong focus on managing IT well: cost, regulatory compliance, vendor management, and things like that.

That's where we were about 18 months ago. Three things were very obvious when I took over this role.

One was the split between business and IT. So there was business, and there was IT. Good old, right?

It was actually very well organized for efficiency, whether it's efforts, whether it's money, whether it is how we deliver value to our internal customers. It was optimized for that efficiency.

Finally, most of the work that was being done, it was done in the model of projects. You get certain projects, you exit those projects, and make sure it is running in time, within budget.

When we looked at this, it was primed for change, because it was a model which had served itself pretty well for many years, but it was time it changed for the new realities of the world which we were living in.

That's where we took our Team Topologies approach. But we said we are going to design it intentionally. But intentionally for what? And that "what" was our business.

A typical Big Four business is about serving the clients around three major areas: helping them with their audits, helping them with their tax, helping them with their legal work. Finally, a more and more prominent business for our audit firm these days is also being a consulting firm, which is advisory business.

What we did was we took inspiration from domain-driven design and oriented ourselves thinking in terms of the three layers in strategic domain-driven design. What are the core business domains? What are the supporting business domains? What are the generic business domains?

We said, let's look at our business that way. The business that brings money to our firm is what's core to us. That's the three business functions for us: audit, tax, and advisory.

However, we, being a professional service organization, have three major elements which bring that business to us: our people, our client, and our ability to instill trust, which is risk. These three became the second layer of domain-driven design, which is the supporting business domains.

Finally, it doesn't matter which firm you are. There are a few domains which any firm needs. That's managing money, finance, managing logistics, managing controls, enterprise digital workplace, and ICT, the end-user computing. That became what we call the corporate services technology.

So we divided ourselves into these three major portfolios, and any business service that we deliver for our firm or our clients gets delivered from there. It's important. I'll just come back to that in a minute.

However, that's not the whole story behind this. There are other things.

What are those other things? At the core, right from day one, we took a platform-centric approach to running the backbone of technology, which is infrastructure and the underlying services. So that was a big pillar.

The second part was services, which has different names for us. It was services which are applicable to the entire company, entire firm. This was three or four major topics, which are pretty obvious.

One was we are in the business of professional services. A lot of content and data gets created there and managed. So enterprise content management is a service which we call an enterprise service.

Then identity and access management, workflow automation: these things run a professional services organization.

Last but not least, audit and compliance. That became what we call an enterprise services portfolio.

Last but not least, somebody has to take us to the next journey. That became our enabling services. That's where three major enablers were required: architecture, engineering, and services which help us become operationally excellent. That's around GRC, sourcing, ops, these kinds of things.

Now, why these four different segments? That's where Team Topologies comes in. They all have their nature to the four types of teams that you have, but this is Team Topologies at large, at portfolio level.

Our business value gets delivered through stream-aligned organizations on the business services portfolio. We, of course, have a platform-oriented team structure down there. We have enterprise services, which lend themselves very well to what we call complicated subsystems, and that's what Marcelo will walk you through, what we mean by that. And of course, enabling services.

So this was our first attempt at applying the same Team Topologies model, but at a portfolio level, not the individual teams of three people delivering a particular project.

Now, this was a model. However, to succeed with that, there are certain things that we had to take care of. You can call them maneuvers. These maneuvers are what I'll just quickly share with you. There are four of them.

The first of them is we reframed what leadership is all about, leadership of team. There was no single leader of any portfolio or team. It's not like, who runs this team, or who is running this team? We changed the leadership model on its head, and instead of a leader, we reframed itself as leading, and we led it to a co-leading model.

This, which many people in my company call Dinkar's magic triangle, is what I call the MDD team model. What we did with that was we decided that it's going to be a focus around leading on three distinct elements.

We often discuss in enterprise communities, what are we optimizing for? Here, the three things are optimizing for value outcomes, optimizing for flow delivery, and optimizing for quality. You cannot compromise on any of them unless you know there is a very significant reason for that, and you know that there are negative sides to that.

In order to ensure that you can balance all the three priorities, you cannot have one person leading the entire effort. That's why we changed this to a collective ownership model. So the leading became important, not the leader. Any of them, at any point in time, can take a leadership role for that team, given what is the context.

Are you right now in architecture phase? Are you designing certain things? Are you currently looking at road mapping and planning? Are you looking at delivery? Are you looking at currently working with your stakeholders to define what exactly needs to be built and taking their feedback?

At a given time, any of them can take up the role. But collectively, this team is not just accountable for success of the portfolio, but also empowered to take decisions on their behalf. That's the team-first approach of Team Topologies: team as a leadership.

Before I go there, I want to share one thing, and this is the experience. Consider that to be a tip. There are a lot of issues with this model which can come in. So you need to be careful how you position this team model, multidisciplinary team model.

There are three ways you can position it.

One is the leadership model, where this team is the anchoring team, the steering team on top of a team. Now, this box there is an abstraction, which means there is some value delivery. You can call it vertical or horizontal. And then there are competency areas, classical squads, tribes, whatever you may call. But there's a team where there's composition.

So this is one model where the team commands the rest of the team how to do. They steer it, they guide it. You can use any term. This is not what we were looking for. This is leading from the top.

The second model was leading from the sidelines. You are the enablers, you are the support system. We are there for you. We'll guide you when the team is autonomous, but we'll be there to support. But this also seemed like playing from the sidelines. This is not something we were looking for.

What we looked for was this, where we actually embedded the leaders into the team. All three leads are actually part of the delivery organization. They are actually part of the team which is delivering software. They are working with their end users to define product roadmaps. They are working on their roadmaps. They are part of the teams doing CI/CD. They're part of the team doing infrastructure and everything.

So this fundamental shift is very, very important. We did not want reporting leaders. We didn't want supporting leaders. We wanted leaders who were embedded into delivery. That's where you actually immerse into day-to-day delivery.

This is also pretty close to the DevOps principles of improvement of daily work. Leadership can only improve daily work if they're involved in daily work.

This also takes away one other side effect. Often people feel psychologically unsafe that there are these three people who are our leaders, or there are people who are on the sidelines, so they're not getting as much immersed into the team. With this model, we were able to take care of both of the things.

So that's the part around team first.

Second part, and this is fast flow. There is often a lot of talk around fast flow. What we observed is often these talks are very locally focused on engineering.

As we spoke in Amsterdam, we took Better Value Sooner Safer Happier as our approach to delivering software. One major part of that is around sooner. How do you achieve something sooner? You try to remove bottlenecks to speed. That's essentially what you do.

What we decided was we are going to do a few things more often and try to reduce things that have been doing in the past, which are bottlenecks. We took up some actions, and I'll share with you what it is.

The first thing was taking care of bottlenecks when it comes to three things: bottlenecks which are not even visible. So we took a value stream management approach. We started mapping our value streams, not just delivery value stream, but also outside of engineering. Where requests originate, how are these mapped, how are these taken to production, how post-productions happen. So we took that value stream management approach and identified what are the bottlenecks we can reduce.

Second was we went a little upstream. We started thinking upstream, which was getting out of IT, because a lot of complications and bottlenecks in IT are actually a result of sourcing somewhere else. So we started working with stakeholders early, whether it is GRC stakeholders, whether it is our business colleagues who are originating some of the requirements, to ensure that those bottlenecks don't emerge later on.

Then, of course, very importantly, we talk a lot about empowered execution, but this is where we made changes. So that MDDT I talked about is actually the decision authority when it comes to teams' portfolios. They take their decisions. Once they've got an approved budget or an approved amount, they are the deciders of how they're spending in different parts of their work.

When it comes to risk management, trade-offs between debt and features and many other things, that triangle decides, not somebody sitting outside where you have to seek permission.

Second thing, and this is where a lot of inefficiency comes in: handoffs. With this MDD model and the teams aligned and long-running, teams which are given to a portfolio, those are the longstanding teams. Of course, within the portfolio, you keep reshuffling your teams a bit depending on team dynamics. But the longstanding teams within an MDD model give stability and much fewer handoffs.

We also simplified governance: how decisions are taken, what decisions can be taken within the team, which ones are taken within a domain boundary, which ones will need to go to a steering group, et cetera.

Then the third thing, and this was essentially making your work visible, and simplifying as much as possible by adopting standards. Now, this is the part where engineering starts to take a lot of shape. However, there's also work outside engineering.

As I said, we started to ensure that every team is now working on Azure DevOps. We use quite a lot of Azure. Every portfolio has its own space on Azure DevOps, and all the teams work there. There's no other mechanism to manage your work in our group. Now you are on Azure DevOps, and that's where all the work happens.

Very importantly, our leadership team, my management team, we are also a service organization. So all our management team work also happens on Azure DevOps. That's why we have made it visible, and everybody can see what is the leadership team working on right now.

So we also deliver certain features, and we have to pay off certain debts.

Last but not least, we are actually a finicky organization when it comes to learning. We have taken learning very, very seriously, and there's not a single day when we don't learn. That's very important, because with that, we are able to understand how to ensure that we are able to move faster in our work.

So these are some of the things that you can try. A lot of these learnings came out of not just Better Value Sooner Safer Happier, but also some things which, I say, often are not told. And this is corporate culture.

Third thing, quickly, I know we are running out of time, is team APIs. I have to admit, this is the hard part. Not hard part because it is deceptively simple. It's hard part because it's extremely difficult for every team to write what they do.

Whenever you start this kind of work, the first question comes in: who does what, how, and whom should I contact? That's the hard part. That's why we started first with platforms.

So platform team has well-defined APIs. They've written who should they be contacted, what are their channels, which Teams channels they should contact, what is their ticketing mechanism, et cetera, et cetera. And also publish a little bit of a roadmap.

On the other side, you see something which is working on, he'll walk you through this, is the team API of the team building our new content management service. As you see, there are also some roadmap definitions, what is the governance structure, and things like that.

The fourth one, very important one. We have heard a lot about this during the last two days: cognitive load reduction. Now, that's where platform played a key role. It was so good to hear U.S. Bank today morning, because our story is actually similar to that.

How did the platforms help? You see some of these pictures. These are nothing but our platform portal, where all our developers can find, hopefully, blueprints of all the automated mechanisms that have been provided on the platform when they need to use platform services.

As I mentioned, we use Azure. So all the infrastructure as code templates are available as Bicep templates on these repositories. It's not just templates, but these are all certified. You can trace back to all our governance policies. You can see which policies these are complying to. Compliance has been baked in. There are samples in there how to use it, and there are also references on how they can onboard to these platforms.

This has been extremely valuable because when we started this journey, after that, we brought in a policy as "cloud unless," which means everything we do from here on will be on cloud, unless you can give me a reason why not.

Which also meant, unconsciously, where was I stressing my team with cognitive load to adopt new things on cloud? Are they ready? Has anybody told them? Is somebody supporting them? That's why this came in quite handy as an instrument for enablement.

However, this was not the only thing. There were a few other things.

One of those things is basics, like, do I have adequate capacity in my team? Do I have adequate capability? If not, who's going to help me out? That's where enablement comes in.

Things like there are enabling teams, but these don't remain consultants outside. They need to be immersed into daily work. This needs to happen. Otherwise, they cannot understand what's happening on the ground day in and day out.

We eliminated toil intentionally, automating quite a lot of things, moving from scripts over to development, software engineering.

Very importantly, incidents are a daily part of any technology organization. Through that, we started to bring in a culture of psychological safety: no blaming, no name. Anybody can challenge any other person, including management team, and can provide their candor.

This is still something which is evolving for a Big Four audit firm. This is a big cultural shift, I can tell you. But it's happening right now.

Last but not least, as I said, we are a sucker for learning. So training is a big part of our change here.

So these are the four major mechanisms, as I have to say. We have applied it. We are still on a journey.

However, quickly, we would like to show you an example of how we are applying the tactical design patterns, taking the same language of domain-driven design into our area.

So Marcelo, maybe you want to walk us through one such example?

Marcelo Ancelmo

Yeah, my pleasure. Thank you, Dinkar.

As Dinkar explained, we have the whole concept and how we see Team Topologies being applied at portfolio level, but we also have the same concepts, same tactics, same strategy applied at team level.

As he mentioned, I am responsible for the enterprise services portfolio. Enterprise services is essentially the complicated subsystems that are used by all stream-aligned teams.

What we use to classify a complicated subsystem is essentially the whole need of highly specialized SMEs that are required to deliver that service. Some things like a mix of complex products that needs to be put in place in order to deliver some key capabilities, like enterprise content management and identity and access management, which are the ones that I'm going to use to walk you through how we see Team Topologies helping us on fast flow to uncover opportunities and to reduce cognitive load.

The first step that we did was to create what we call the social architecture view for the teams, which is essentially applying the Team Topologies diagrams to show the connections and interactions that exist within our team.

So when we look inside the ECM, it's a stream-aligned team, because they are delivering ECM capabilities. When delivering those ECM capabilities, the ECM team needs to interact with our global platform, because global platform delivers our Microsoft 365 infrastructure where we build the ECM product.

But it also needs the enablement from our enabling services team to provide the architectural guidance, the agile guidance, so they can deliver while doing the architecture of ECM.

We identified also that we need external support, support from a partner that cannot only enable us on those key ECM capabilities, but can also collaborate with us in order to accelerate the global platform to deliver the services that we require.

Then we have two types of collaboration: the partner collaborating with us and collaborating with global in order to engineer the services that we need.

But we also have our local platform team, our services delivery platform located in Switzerland, which provides the infrastructure for us to deliver the ECM capabilities that are above, beyond, or on top of what global provides.

Now, this is the inside view of ECM.

When we look at how ECM interacts with other applications, some interesting things happen. I have two key applications in this example: CRM and our ERP, that need to collaborate with ECM because ECM is a key application for our business. It's all documents that we create, that we provide, that we exchange with customers while doing the collaboration with those key applications.

Those stream-aligned teams for CRM and ERP are also supported by our enabling services team. We identified that, look, this is not what our architectural strategy says that we should be doing. Our strategy is API first. It is to consume everything as a service.

So I need to hook up into this view the integration platform. But integration platform is not ready yet to support those types of interactions. So this triggers a new value stream working on integration services.

This value stream, given that cognitive loads on both ECM, ERP, and CRM value streams are not able to provide integration platforms, our integration services value stream is led by architecture, enterprise architecture, and strategy, supported by our cloud center of enablement and platform services.

So they work together to deliver the integration platform, which in reality is a platform provided by the services delivery platform. Doing this work, they can enable the proper usage of integration platform as a service, in this case by ECM.

Being conscious of time, collaborating with our complicated neighborhoods.

One key system that needs to be part of this collaboration is IAM, which, as I showed, is also a complicated subsystem. Now, from ECM perspective, the ECM stream-aligned team is collaborating with the IAM complex subsystem to deliver the key security capabilities that are required by ECM. So all the documents that are worked at home on ECM can have all the proper minimal security requirements for them.

But when we look inside IAM, it's very unique, very different from the complex subsystems team. As a complicated subsystem, it has multiple value streams, but it also has some key technologies that are required to deliver the services that they need.

In this particular situation, we know that ECM requires the enterprise IAM capability from this complicated subsystem team to deliver what they require. Of course, this gives them time to work on all other capabilities that they need in order to deliver.

Now, as these neighborhoods evolve, our target state is to deliver everything as a service, to support everything being delivered as a service, and to enable, via a conscious platform, new services to be onboarded in a proper, quick, and easy way, following the everything-as-a-service standard.

Now I will hand over quickly to Dinkar, where he can wrap up.

Dinkar Gupta

We're running out of time. So as usual, none of us are in time.

Quickly, what are the takeaways? Three major things.

Be careful of how you divide your teams. Team Topologies has the concept of fracture planes. There are different ways to divide and conquer your team designs. Those fracture planes can be related to complexity. It could be related to your competence. We just saw an example where a specialized product had to be used. In some cases, it's different.

Second thing, be patient with adoption of interaction patterns. That's the part which takes most of the time in doing this work. Designing an internal of team are fine, but it's the arrows which are mostly the complicated part. Be a little patient with them. People will take time to do it.

Flow is important, but don't do it at the expense of people's cognitive load. Then the risk of burnout is extremely high here, so be careful with that.

Governance, risk, and compliance: make sure to engage them from day one in your endeavor. Otherwise, you will see a lot of issues coming later at the later stages, because no system can be done without adequate risk and compliance control. So please engage them early.

Last but not least, it's all about people. Be ready to invest in them, their training, maybe in hiring, also re-skilling and reorienting them. Enablement and platform teams are extremely critical.

However, quickly before I wrap up, three more things which I think are very important, but there are no tricks here.

One is if you do it within IT, there is only limited advantage possible. You'll need to go outside IT to see real benefit of Team Topologies, and that's very critical.

Second, do not underestimate governance and budgeting procedures. Engage them in your design from day one. Otherwise, this doesn't work. You'll need to align even your budgeting process and how decisions are made into this design process.

Last but not least, there's no right size of team, like microservices conversation. There's no right size of team. You need to experiment a little bit with the different kind of teams, and that's where dynamic reteaming comes to the rescue. Apply that, and that will be quite useful.

I know we are running out of time, so thank you very much. Hopefully it was useful. Any other questions?