Dinkar Gupta

Hello, everybody. Good afternoon. I hope you're enjoying the sessions so far. So, dare to do. Dare to do what you just heard. Some of you probably heard colleagues from Accenture talking about auditors, and the audit firm is here. We would like to share with you a story of what we are daring to do in a professional services firm, trying to bring engineering to the core.

Today in front of you: Dinkar. I'm the CIO and CTO for KPMG in Switzerland. And I have my colleague Marcelo, who heads the solution architecture practice in our company.

Before we get into our story, one very important thing to understand is who we are. KPMG is well known, but Switzerland is an independent firm. We are a firm which is part of a larger network of member firms globally. KPMG is a well-known Big Four company: auditors, tax consultants, management consultants. We are a member of a much larger organization across 140 countries. However, Switzerland offers a unique perspective. We are a nimble organization, not pretty large, around 2,500 people. But the interesting part is that in those 2,500 people live 56 different nationalities. It's a fairly diverse workforce, not just in terms of where we come from, but the kinds of backgrounds we come from. You put auditors, tax consultants, and now engineers in the mix, and you have really a recipe for some interesting change.

One other small part of this change which is helping us a lot: it's a very young and dynamic company at heart. While these are 2,500 people, the average age of our colleagues is around 34 years, which makes us quite vibrant in terms of change. We can drive change; there's quite a lot of new thinking.

When we took up this challenge, one thing which struck me -- I joined the firm about one and a half years back -- was that the ethos of this firm reflected what I was enjoying in the DevOps community: inspire confidence, empower change, and dare to do; breaking new ground. As a result, we took up this journey, and the journey started with something simple: what are we here for?

We were not here for technology excellence or engineering, as both of us engineers would like to achieve. What we saw was that our CEO, executive management, the EXCOM, and the board were really after growth. So we made that growth our agenda. As the firm dares to grow, which is embedded in our strategic document for the next three to four years, we made that change our agenda. What we wanted to do through technology was become that engine of growth, because most of the growth the firm was seeking was going to come from digital transformation, from our work in the digital business space. We decided we'll make change central to our strategy.

As a result, we made a little tweak to our key message from our CEO, which was, change is an opportunity; our business is change. Change is the business. We adjusted it a little bit: technology-led change is our business. When it is technology-led, then by default practices that come from the DevOps movement, practices that come from reliability engineering, practices that come from the technology industry at large start to take a central role in our transformation. That's something we pursued ourselves: let's go ahead and try to make this work.

But we had a problem. What are we after? We had to make a choice. You can come in and start doing the nifty stuff of geeks and technologists, or you can just get immersed in supporting the business. We thought, no, that's not going to work. There were three choices. One option was to seek certain outcomes: let's try to pay technical debt off in the next six months; let's try to move to cloud in a few years; let's have our ERP running on cloud. Or, from tomorrow, we are going to do this agile method; we will follow a particular approach to reliability; a particular method we will adopt. But that's just process.

Instead, what we chose was an identity-driven transformation. We took our inspiration from Atomic Habits, because one of the things that struck with us was that we really wanted to change our identity. When we said "we," it was technology's role in the business. We didn't want to stay just a function within the organization. That was the identity: this is a function which supports the business. If you really want to bring a change, you can't live with that identity. You can do any process you want, you can achieve any outcome you want, but you need to change that identity. The identity was that we will be the torchbearers of a larger technology ecosystem in the company, not a function sitting on the side supporting somebody.

That was extremely important to us because this required some inspiration. Our inspiration comes from Turn the Ship Around. We really made our mission to turn the ship around. That's been driving our change agenda since then. We started when I joined the firm in November 2021, and around May last year we started our journey to turn the ship around. This story is what we have tried to achieve and the progress we have made over the last 12 months.

The first problem to deal with was the name. Most of what I've heard over the last two days is that IT services is a classic name in any enterprise. As soon as you hear the term, it's like somebody sitting in the corner fixing my laptop or my infrastructure. That's the real problem. If you want to be intentional about your role in transformation, your name needs to reveal that intention. The intention was: we are not a support organization sitting on the side. We are the business. If technology-led change is your business, then your name needs to reflect that.

So we said, let's start where we can start to speak a different language. That was the name, and that was going to be our identity. We started with three traits we wanted to achieve. One: whatever happens in technology in this company will be towards business outcomes, value generation at the front where we make money. Simple. Second: whatever will be done through technology, through engineering, through business value creation will be service-oriented in nature. That means we will not just offer services; we will deeply care about quality of service. When you have a service, quality of service becomes extremely important, whether it is reliability, performance, maintainability, or the experience our users get from those services. And finally: comfort may never leave the pursuit of agility. Always be agility-centric, being able to respond to changes, whether they come from within the firm or from the external environment.

As a result, that was the first change we made. We started calling ourselves Digital Business Technology. That is an ecosystem, not the name of the function. While the central function within corporate is called DBT, the entire ecosystem is called DBT. When somebody talks about technology at KPMG in Switzerland, we do not talk about IT services. We talk about Digital Business Technology. That started to change quite a lot of things, because it started to clearly reflect the fact that technology means business within the firm.

Then we asked: how do we do it? The point was pretty simple. We can't do it alone, and of course you don't need to reinvent the wheel. We have a community to fall back to. We both are avid members, participants, and followers of the Enterprise DevOps community. We didn't have to look far; we had our backs covered.

We picked up three things to drive our journey. The first was a very serious and extremely important pursuit about moving to products. That was an interesting challenge: dare to do products in a services industry, and that too professional services. That's another daring thing. Second, we are not going to organize ourselves hierarchically, but we looked at Team Topologies so that we are orienting towards how to deliver value and adopt some of the mechanisms there. Last but not least, we made Jon Smart's Better Value Sooner Safer Happier our centerpiece. You will see some examples of how we are trying to do that, but that's our guiding philosophy. We are trying to deliver better value sooner, safer, happier. We also wanted to maximize our leverage with what we have heavily invested in, which is our cloud with Microsoft. We are a strategic partner with Microsoft, and with all the innovations Microsoft brings there, we wanted to ensure we are maximizing this with these three changes.

So what happened next? All of this is good. However, there is a problem. We are a company which has been in existence for 113 years. We are not FAANGs. On the other hand, we are also not a one-app startup. This is what both of us call the middle-class problem. We belong to the enterprise space, the middle class. We are not Google, Amazon, or the others, with the scale, complexity, engineering talent, and money of that group. And also not the lesser risk that comes with doing one thing. We are not a startup trying to exploit it; the associated risks are different. There is a very strong and glorious legacy, a brand name, trust in the market which the firm represents. On the other hand, we see the promise of the glorious future: what continuous innovation, technology, and digital will bring to the firm.

How do you deal with this tension? The tension is not just of methods and technology, but we see it as a generational gap. It's extremely difficult to bridge this generational gap. Some of our colleagues are extremely knowledgeable. Some have actually seen the evolution of how audit works and how tax works; they've been in this industry for 40 years. You want to bring them along. Then there are newer colleagues coming out of college, joining us, and seeing how digital helps them deliver better. How do you bridge this tension between these two groups, the practices of older generation and newer generation? You want to maximize the potential that exists in both. This is definitely an area where choices, trade-offs, and learning start to come in.

So what we did was: okay, we will not make technology our pursuit. We went in with the strategy which I call sustainable business agility. This is what I was after, and this is what we as a firm were after. Our pursuit was to achieve sustainable business agility. Nothing new as a term, but three very important words. It's agility, but within the business, not technology and not agile methods in IT. And second, that lasts, that can sustain changes that will come through the cycle. That's a very important word, a language we have started to speak very heavily within the firm.

This should address all aspects: risk management, how we respond to requirements coming from the market, how well we align with our global strategy. As I mentioned, we are not an independent firm sitting somewhere; we are part of a global network. Finally, at the end of it, the business is there to be financially viable. How do you ensure that is being taken care of?

In order to do that, we also want to ensure we stay true to the other three traits which are part of our identity. That formed our key levers to work with. The three levers on which we work: how are we going to organize ourselves to deliver this promise? How are we going to structure ourselves, what kinds of methods are we going to use, what kinds of interactions are we going to do, the classical governance mechanisms, talent, what kind of talent we'll need, how training will be done. Second, the ways of working: a combination of Lean, Agile, DevOps, and other methods, and how we're going to use that. Finally, how are we going to intentionally design our systems and use technology so that it can help us fulfill the promise. Our work is essentially on these three dimensions. At the intersection of the three, there's not linearity. You don't do one, then another. The efforts go across all three, and then we start to see a change.

However, before we go into any more detail, the first thing we wanted to challenge was that we don't get affected by Conway's Law and let our HR and organization structure decide how we are going to design our systems. That's the first problem we tackled. Marcelo, maybe you want to walk us through that, and then we'll come back.

Marcelo Ancelmo

Yep. As Dinkar mentioned, Conway's Law is a fact for all of us. We know that it happens, it will happen, and it is happening right now. What you can see right now is how our firm is structured, how our firm does business, how KPMG Switzerland delivers value to clients, and how we have a lot of teams supporting those client-facing functions inside KPMG Switzerland.

We are basing ourselves on well-grounded sources of knowledge. We made a small twist on how we wanted to structure DBT in order to deliver the value that was expected from us. We have our client-facing teams, our business support services teams, our corporate services teams, and we structured them as Stream-Aligned Teams. We created a Service Delivery Platform team that can deliver all the infrastructure and services required by those Stream-Aligned Teams to do their business.

In order to enable those Stream-Aligned Teams, we created different teams that provide the cross-cutting services used by them: things like enterprise content management, identity and access management, workflow automation. Every single piece of software technology that is common and required by these Stream-Aligned Teams. To support and enable all of those different things to stand out and deliver, we created an Enabling Services team providing all the engineering foundations, all the good practices, all the training, and all the knowledge required for them to deliver.

We followed the inverse Conway maneuver to enable collaboration, modularity, and agility, driven by design and architecture and inspired by Domain-Driven Design.

Dinkar Gupta

This is very important to us because mostly when we do team designs, we go within a particular area and try to design teams in small. We actually dared to do it at an organization level. Our business is where the value gets delivered, so Stream-Aligned Teams become quite interesting there. However, that's not the start, because individually within each of these portfolios -- the four major segments -- you will see different types of teams getting organized.

To give an example, at the platform level, the Service Delivery Platform has an internal enabling team, a center of enablement, which supports the entire delivery of work that happens through the Stream-Aligned Teams within the platform. However, at an organizational level, our value streams towards our clients and towards us as employees are delivered through the business services portfolio that we see in front of us. This is ingrained in our systems now. It is reflected in our technology, in the way it is organized in our DevOps systems, in our budgeting process, and this is extremely central to how we are organized and operating now.

Marcelo Ancelmo

To help us with the communication and the interaction between the teams, we also adopted the Team API approach. Based on the Team Topologies template, our teams describe what they own, what services they provide, how other teams should interact with them, and how expectations are managed. This gives the ecosystem an explicit interface instead of relying on people knowing who to call.

We also looked at the talent portfolio. We needed to rebalance capabilities across thinkers, doers, and watchers. Every discipline matters. The objective was not only to add more people, but to make sure the capabilities that design, build, and observe the services are in a healthy balance.

As part of this restructuring, or this new way of seeing the recomposition required to properly deliver our products, we worked with the concept of a Multi-Disciplinary Team. This is essentially a cross-functional group of people: people with more experience on the business side, people with more experience on the technology side, but a cohesive unit focused on product, quality, user experience, and the product experience delivered by what they are doing. This group of people, our product triangle as we call it internally, is autonomous, is responsible for everything related to a product or service, and is accountable for all of those dimensions: quality, experience, and value.

Dinkar Gupta

Exactly. This is a term we use within the company: freedom in a frame. The framework provides the guidance for these teams to exert autonomy. However, that autonomy is not unbounded. It needs to be aligned so that the overall system benefits and the overall firm benefits.

Marcelo Ancelmo

This is where we bring the concept of the information center and Better Value Sooner Safer Happier. The idea is inspired a bit by the Agile Manifesto. We know there are some things we need to stop doing, and at the same time we need to leverage the important things that are required to deliver the value, the experience, and the quality that are needed for our products and services.

We had to focus on some aspects first: engineering over tools, really building the engineering mindset into our community inside DBT, and at the same time reducing, acknowledging, and reducing technical debt.

Dinkar Gupta

It's that balance between supporting the business outcomes that start going in, but also improving the maturity of our engineering organization. That's again a trade-off. Our traits inspire us to balance these priorities: at certain times prioritizing business outcome delivery more, and on the other hand ensuring our maturity. The framework of BVSSH gives us more or less the guidance when we have to make these choices, instead of going all around the place and asking what should we do. This is extremely central to us. Of course we are informed by OKRs as a framework, but again, this is used for our teams to inspire ambitions, more like setting aspirational SLOs. OKR is more in that direction: something you aspire to achieve, not your performance appraisal. That's extremely important. This framework is essentially our operating rhythm. This is what we operate with when it comes to Agile, DevOps, and Lean within our company.

Marcelo Ancelmo

It is our operationalized DevOps system. It is our operating system inside DBT. I think we are running out of time, so maybe we focus on a few things, platform services.

We started building infrastructure as a service that would bring to all of our teams the required services they would need from an infrastructure perspective: VDIs, networking, cloud services, or on-prem services, in a way that is completely transparent and agnostic to them. A Stream-Aligned Team can easily connect to the Platform Services team via their Team API and request whatever they need in order to deliver the value they need to do.

Dinkar Gupta

Exactly. We are at the start of the journey. However, the platform is heavily focused around automation. Slowly over the next few years, we'll see significant reduction in how it is served right now, and we are moving completely to an API-based interface in front of our platform. There are well-defined service streams, and each service is offered as managed interfaces that the other teams will use so they can automate their platform consumption and also self-serve whenever there is a need.

This is a journey where we have given ourselves up to three years to reach a certain stage, and we are at the early stage of this journey. But the intent is very clear: the platform is going to be a managed product within the company. Just like you saw the MDT triangle, we have a team owning the platform: a product manager, an engineering manager, and an architect responsible for our platform services and the team with them. However, there are certain things we were a little careful of, because as a firm you need to take care of things like data migration. People forget when moving to cloud. You don't just move virtual machines; you need to take care of data. There are a few things we had to consider, but in the interest of time we'll have to refer to it later and we'll be happy to have a chat around that.

Marcelo Ancelmo

The other aspect that adopting this DBT lifestyle allowed us to do is that we are now able to have conversations with all the main stakeholders -- other teams being stakeholders, our EXCOM being our stakeholders, Dinkar and Markus, our COO -- based on data. We can show them: this is the number of debts that we have; these are technical debts that we have; this is the number of risks that have been raised; this is the amount of risks that have been integrated; this is the amount of features that have been delivered since our last conversation. We are heavily focused on important metrics, DORA metrics, flow metrics. We have dashboards that show all the work flowing from the value streams. We can pinpoint at any point in time what is happening, why it's happening, and which actions are required to move from them.

The other point that is important is that as we focus on the platform services heavily, we could enable the teams to operationalize their delivery. Focus on postmortems, focus on preparing proper operational practices that they can use internally or expose externally: how things are working, why they are done that way, and what architectural design grounded those decisions.

When we talk about architecture, we also adopted a very lean, structured, grounded-on-reality approach to architecture. We have the architecture team, the enterprise architecture and solution architecture team. For them, we are working based on advisory. We have an advisory board that helps all architects to deliver value. We have a technology repository where they can find the information they need. We have some lean ways of documenting, so every decision generates an architectural decision record that is sounded with our advisory board. That way we want disciplined, agile, lean architectural practices.

And learning. Everything that we do is grounded on learning, on sharing information, sharing knowledge across the firm. Communities of practice: we started with the architecture community of practice. We have a lot of engagement there. It was followed by an agile community of practice, which leads us to a community of practice. Just two or three weeks ago, someone approached me and said, Marcelo, I want to start a development-oriented community of practice. Can you help me with that? Now we have four communities of practice that help us share knowledge and share learning across the whole DBT landscape.

We have an internal social media presence as well. We have a technology platform that enables us to share knowledge with the whole KPMG Switzerland firm. We do architectural katas, we do katas into all communities of practice. We have mentoring programs where Dinkar can help younger or more senior members of our firm to deliver value and to learn. There is also one particular passion that comes from Dinkar.

Dinkar Gupta

That's called Tune In. It's something I was a little passionate about. I started it when we came in. It's an explicit timeout for learning within office hours. Every Friday from 11:30 to 12:15, I read a book on a Teams channel, and whoever is interested joins in and listens. They tune into a reading session. This helps them. I don't need their time on weekends or evenings to read. I don't force them to read. If you're interested, come, we'll read together; I'll read it for you. I started, and there were only six people who joined. Right now I'm talking about 40 to 50, and it's increasing. This is not just IT folks: HR, legal, data privacy officers, colleagues from other countries. This is gaining traction and it's something I'm really happy about. We really look forward to having things as simple as that: storytelling as a powerful way to learn.

With that, I know we are out of time, but quickly I'll try to give you the gist of what we have learned. All of this is good, but one thing we observed, and I think it's also clear in the sessions over the last two days, is you need to be clear on what kind of impact you are seeking. If you're looking at transformation recomposition, you need to figure out to what extent you want to go, because the levers vary and the body is the same. Your organization is the same, but how deep you want to dig into that depends on your objective and what kind of change you want to bring in.

Can you influence just by practices? I'll start using Azure DevOps, I'll use a certain way to do Lean, I'll use flow metrics: all of that is fine, certain practices to deliver. But we need to be careful. Those practices are informed by how our systems are designed and how our technology is shaped. That in turn is shaped by our organizational context: how budgeting happens in your company, who takes decisions, what kind of culture is there. At the end of it, the very core is what kind of belief system is there in the company. Depending on the extent of change you want to bring in, you may have to take it way deeper than just implementing agile practices or implementing Domain-Driven Design as a design method. Be very careful. There are different levers, and that means the time it takes to achieve outcomes also varies. It's very critical.

Some learnings we wanted to share so that we can reflect together. The first one: it's not about dev and ops. There is a much larger set of people who work for a company. There is HR, finance, and other people. Even within the so-called IT, there are other things to be done other than coding, testing, and development. There is asset management, compliance, sourcing, procurement, many things. You can generate value for your firm by following DevOps and SRE principles in any area. We saw earlier that SRE can be applied to learning. You can apply the same principles to get value generation in any area. Don't forget those. For a company to be successful, these are very important.

Second, pay very, very close attention to the learning anxieties and cognitive load on your colleagues. There is a big risk: you are burning them out. We experienced this firsthand. Guilty, in some cases. I found I was running too fast. As a leader of the pack, I had to take care of this. Be very careful. Change can become a burden. These are people, and that's the message. Be ready to modulate your pace. Not everybody runs at the same speed you want to run -- not can run, but want to run. Once you start to get signals, be ready to modulate your pace. Be humble. You can only run as fast as the rest of the organization. It's a team game. It's not an individual win.

Very important for us, and this is where the Flow Framework comes in: make technical debt and operational risk a first and very explicit priority. Not just in the team talks, but when I present to my EXCOM, when I present to my senior colleagues in partnership, I talk about this stuff. If it is not talked about, nobody cares for it. Make this part of your language.

You can give people autonomy, you can take autonomy, but if it is uncontrolled you are going to result in unmanageable complexity. Do not undervalue governance. It's very important, especially in enterprise context. There are significant implications of not doing governance right.

Last but not least: language, that is leadership. Change the language if you want to change the culture. If you really want to change the culture, our only takeaway for the last year is start speaking a different language. Things start to change there. You can change your practices and everything, but if your language doesn't reflect the intent, the aspiration, what you want to do -- that's why I said Turn the Ship Around. The whole simple message on that book was: I'm not asking for permission; I intend to do this. Do you see an issue with that? That fundamental change in the language is very critical.

More than anything else, two important things. Deliver on your commitments. Delivery changes everything. And please, please, please be patient. Patience and perseverance. Please stay with this.

We are already way out of our time, but I cannot leave without saying this. If you're willing to dare, if you dare to do and you want to be someone who is to go and conquer the world, absolutely you have all the IT Revolution books in your pocket. Benefit from it. But there are three things we've found over the last one year which are extremely critical if you really want to succeed. First of all, embrace cultural change. If you cannot deal with culture, go back, rest everything, and wait. Start working with this. You need to embrace the diverse culture that exists in your company. That's something you may want in your back pocket.

Second, be very clear: it's easy to learn new things. Letting go of the past and unlearning is the toughest part. Have that in your back pocket.

Last but not least, if you're only after efficiency, fine. You can do work downstream in your local space, in your area. But if you're really looking for effectiveness, go upstream. Start looking for what's causing what I'm dealing with. Do not keep running and putting out fires. Start looking at what is causing fire, and that's where you need to leave it. Acknowledge your organization and go upstream, sometimes even outside your organization. That's going to come in very handy.

With that, that's what we are looking for. Two very specific things, other than the connection. As I said earlier, it's not about just DevOps and SRE stuff. We are both hardcore engineers for many years now. But we realize there are a lot of companies, and we are in that, where there are some things which we call not entirely a dev shop. Not everything is coded here and built here. We would love to see experiences: how DevOps is getting applied where not everything is coded here. And second, product orientation in a service industry is something that we would like to seek feedback on.

With that, thank you very much. It was just a start for us. We do promise to come back, and hopefully we'll make it a successful journey to share that with you coming through. Thank you very much.