Host Intro (Gene Kim)

All right. Last year in Amsterdam, we had a fantastic experience report from Ramina Druta. She is a senior cloud and security research engineer at Visma, one of Europe's largest providers of business-critical cloud software.

After the conference, I got to meet so many of the other technology leaders there, and I was delighted to learn how they were using concepts from the book Wiring the Winning Organization, which came out last November, to think about how they can enable technologists to do their work easily and well.

I was delighted when Mili Orucevic, Chief Software Quality Engineer, and Alin Iacob, their Cloud Architect, said that they were willing to share their grand journey that they have been on since 2015 to enable greatness in their organization and to better serve their customers. So I am delighted that up next is Mili and Alin.

Mili Orucevic

As Gene mentioned, we are going to talk about how we are actually wiring winning organizations in Visma at scale. We have gone through a lot of transformations in Visma, both culture to engineering to security and organization. Although we might not have used the concepts of slowification, amplification, and simplification back then, we are definitely doing that.

Let us introduce ourselves. My name is Mili. I am the Chief Software Quality Engineer, and together with me, who will co-present, is Alin Iacob, who is a Cloud Architect specializing both in AWS and GCP. As you will learn along the way, we work with all of the different companies that are part of the Visma Group to modernize their products and services by applying these modern software engineering practices.

First of all, who is actually Visma? I think most of you might recognize Visma from cycling, sports, or Netflix. You might also have seen the show there for the Tour de France follow-ups. Besides winning the three grand tours last year, Giro d'Italia, Tour de France, and Vuelta a Espana, we are not only focusing on cycling as a main sponsor. We are actually a software company building software that is shaping the future of society.

We develop and deliver business-critical software to small and medium-sized businesses, large enterprises, and the public sector, all across Europe and also in Latin America. If you are in the Nordics, you might be using one or more Visma software products from basically when you are born and throughout your life. That is why we want to make the software we create seamlessly integrated into daily life. It always needs to work. It always needs to be there when you need it, and you do not need to feel that it is there.

In the Visma Group, we are over 180 entrepreneurial companies. You can imagine the different tech stacks that all these companies have and all the challenges that leads to. We have over 15,000 employees serving close to 2 million customers. Throughout our systems, we have over 11 million payslips and 23 million invoices every month. It is critical that our services are up and running and that they are there when needed. Otherwise, no one else will get their payslips, and that will be a problem for society.

Let's turn the clock back to 2015, when one of our biggest transformation journeys began. Back then, we realized that we needed to change the ways that we worked in order to keep pace with everything happening around us. We were scattered in different silos. You could have a development team, a test team, and an operations team working in different silos, throwing things back and forth between them.

Most of our software was hosted in local data centers, where the possibility of rapidly scaling was limited. Sometimes you needed to order an entire rack or create tickets to get a new server, and that took a lot of time. Our deployment frequency was around five to six times a year.

As Visma grows both organically and by acquisitions, we saw a problem. When we wanted to integrate with ten new companies that were acquired, or ten new services that we acquired, it was really slow. So we sat down and tried to figure out: how do we want to work? The world was not only changing fast; it was accelerating. Disruption was more likely than ever. Technology made it possible for anyone to spin up a service from their room and suddenly become a competitor, and we also wanted to utilize that technology. Knowledge was increasingly democratized. We had more and stronger competitors, and customers were more demanding. Lately, we have seen the disruption AI has brought, but luckily, when that came out last year or a couple of years ago, we were ready for that.

What did we actually do? First, our development speed was really slow, basically six times a year on average. We needed to increase our ability to deliver changes to customers and users much more frequently, so we focused on a number of technical capabilities that we wanted all teams to have.

Second, we needed to streamline the teams and how we were working to get rid of bureaucratic handovers and silos. We needed to empower all teams creating software to be cross-functional, to have full ownership, and to be fully responsible for what they were doing. From idea to production was in their hands.

Third, we needed to utilize the latest technology, in this case the cloud hyperscalers that were becoming available. Top management in Visma realized this early on, and we had full support to do so.

This led from six deployments a year to 42 deployments a month on average: almost a hundred times as much, 506 times a year if you want. On average, service delivery teams are delivering this much.

We were clear that this is the way we want to develop software. We coined this into something we call the Visma Cloud Delivery Model: how all Visma teams should follow the Visma way of developing, delivering, and operating cloud services. The model describes how you should organize, how you should work, and what technical capabilities you should have in order to build a successful cloud service.

This is the journey and the end state we wanted to achieve, although it has been developing throughout the years. As Gene mentioned, Romina and our security director Espen have presented the security side at this conference last year and two years before. Today we will focus on the engineering practices and the architecture and technology program that both Alin and I are part of.

I would like to dive into how we help Visma teams move from the unknown zone to the winning zone. Alin, will you share what the unknown zone actually is?

Alin Iacob

The unknown zone is characterized by uncertainty, risks, and technical debt may be hidden. Opportunities might be missed. Sometimes we see internal misalignment or confusion around decisions concerning the architecture or technology stack. Important capabilities and practices might be missing.

In the big picture, when helping teams navigate from the unknown zone to the winning zone, the first step is to create visibility into the current state, bringing the hidden stuff into the light. Then we look at what is important for the business: which aspects need to be improved the most? Is it delivering features to stay competitive and improve time to market, or stabilizing the product to improve customer retention? We want to identify and prioritize work that impacts those business aspects that need to be improved the most. That makes technical investments more efficient.

Part of what we do in Visma to help teams move from the unknown zone to the winning zone is embedded in the Visma Architecture and Technology Program. With this program, we take a holistic approach to software engineering, focusing on multiple pillars that support a successful software-as-a-service. That includes aspects like architecture, integrations, and continuous delivery.

We offer Visma companies a collection of services and assessments, attempting to solidify each of these pillars while paying attention to cross-cutting concerns like automation, cost, security, and monitoring. The assessments make up a quality standard, if you will, and we invite Visma teams to adhere to this quality standard. It is a framework that supports the prioritization of non-functional aspects of developing and operating software, like performance, maintainability, or scalability.

The nice part is that we build these standards and quality standards together through Visma Talks, internal events with guests like Gene himself, Vint Cerf, Scott Hanselman, and many others. There are guilds dedicated to cloud vendors, to AI, and to testing. There are research and collaboration groups. These provide a platform for employees to learn from each other, share knowledge and experiences, and lead to a culture of continuous learning and collaboration. They also help break down silos, build relationships, and create a sense of community within the organization beyond regular team boundaries.

With each assessment, we take a step back, slowing down but building trust using validated and up-to-date checklists, trying to answer the question: what risks exist? Are there any missing capabilities and methodologies that are known to be predictive of success?

The way we work is that we focus on what and less on how. We think giving teams the freedom to choose the how supports an important principle: ownership. That allows for creativity and innovation in achieving desired outcomes.

Looking back in 2023, we performed around 300 reviews with these assessments and identified more than a thousand risks and improvements. When I say we, today you see only two faces, Mili and myself, but we are actually a team of five. Shout out to Morten, Cristian, and Andreas. I think we make a great team.

Back to findings: they are prioritized based on impact. A good example is when evaluating a product with an SLA of 99.8%, having single points of failure is a good candidate for critical follow-up priority. On the other side, a product in maintenance not having the capability to use feature toggling is a candidate for lower priority.

These findings become part of the team's backlog, and sometimes the findings can be overwhelming. A good starting point for teams is the question: what are we trying to achieve? We do not just solve technical problems; primarily, we solve business problems. Now that we have gained good visibility into what could potentially be holding us back, it is easier to build a strategy.

The findings are amplified. They are made visible in an internal tool called the Architecture and Technology Index, where maturity tiers are introduced to reflect different levels of engineering effectiveness and adherence to best practices. Each team can select a target maturity tier. After working with the assessments, the current maturity tier is computed. This shows how far away the team is from the winning zone. In the end, the Visma index simplifies communication with stakeholders and management.

Other signals that we amplify come from product analytics. More and more teams started to use that, and we are looking for how end users use our products. This helps product development teams make more informed decisions, iterate, and integrate this feedback.

We are also amplifying signals from engineering performance: the SDOP metrics. Our internal framework used to measure teams' engineering performance also shows maturity levels and helps teams benchmark against themselves, against the Visma average, and against the industry. We follow the DORA reports every year, and that is our guiding light in a way. If the quality of code delivered to customers is decreasing, that would be visible through metrics like change failure rate or availability.

There is a trend line at the bottom of the screenshot starting back in 2020. It represents deployment frequency combined across the almost 150 teams reporting data about their engineering performance, and the trend is positive, going up.

A testimony from Jacob Nielsen, Director of Engineering at e-conomic, a company in Denmark, uses the engineering performance metrics to gain visibility and also as a strategic tool to guide their investments.

We also want to amplify the positive and inspiring signals. We interviewed Jacob last month, exploring key strategies and cultural aspects driving continuous improvement in their organization. We learned that engineering performance is discussed regularly with their board. They are equipped with a healthy mindset, generating good results, as we have observed when analyzing their data over the past few years. Their delivery lead time is now four times faster, and their deployment frequency has more than doubled.

We are analyzing much more data in Visma, right, Mili?

Mili Orucevic

Yes, definitely. We are lucky and privileged to be able to dig into this data because we have a lot of companies sharing data within Visma that we can access. We can replay some of the studies that we read about, whether from DORA or other industries, with our own data. Here we look at everything from financial data to engineering data, innovation maturity of the teams, product NPS, and so on.

One thing we wanted to highlight from research we have done for some years is that teams and companies that deploy more often also increase their annual recurring revenue over four times as fast as the ones at the bottom. This has also been shown as part of the McKinsey & Company survey on their Developer Velocity Index, where top 25% companies and teams grow revenue five times as much, with very similar numbers to what we produce in Visma.

The last of the three pillars that Gene has mentioned in his book, besides covering slowification and amplification, is simplification. There are a lot of things we do when it comes to simplification. We want to highlight three things, with the red thread being reducing cognitive load for the development teams.

One thing is the assessments that Alin mentioned. Teams do not need to start from scratch and think about how to manage technical debt, whether their public cloud infrastructure is in good shape, or how to improve continuous delivery. These are covered by the assessments.

The same goes for cloud. Not all teams are on cloud. Based on years of experience, we created a public cloud onboarding structure, dividing this huge task into smaller, manageable tasks that teams can use as part of their strategy.

For platform engineering, all the tools that we think should be used by most teams are centralized, and everyone in Visma can benefit from that. One platform we created is called My Tools, where a developer or any role in the organization can select the tools they need access to and get those tools in a matter of seconds. Previously, you needed to ask someone to approve something and it took a lot of time. Today, you get it when you need it. This contributes to a much smoother experience for development teams.

We have talked a lot about how the teams and our organization benefit, but the last point we wanted to highlight before rounding off is how end users benefit from all of this.

First, all the services we make are ISO certified and ISAE 3402 Type II certified, all those that are part of the VCDM. With regular interactions with customers and users, we try to meet their needs and continuously improve. We want to make the changes that customers and users need and want as soon as possible. Rather than doing this five times a year, we want to do it many times a day.

We also know that all the services you use should always be available when you need them. We try to aim toward 100% uptime, and we are aware that it is not possible, or in many cases very difficult, to achieve. But we try to do what we can to achieve that. We try to predict and simulate incidents so teams are ready when an incident happens in production and know what to do. We try to increase load and performance to see how a service will operate under different load.

One hugely important and critical thing is security, which we did not have time to cover today. It has already been covered in two other talks that you can watch from the library, and I encourage you to do so. Thinking about security from day one is super important. We have many layers of security through the security program that everyone needs to do and look into. I think we have one of the highest security levels in the industry in our segments.

Transparency is important. When something goes wrong, and we know it will, we are open about it. We try to share postmortem stories, learnings from what we have done previously, and with different communities, how we are doing things, as we are doing here today.

Twenty minutes is too little to cover everything in detail, so I encourage you to read more about our journey. With that, I would say thank you to all of you and encourage you to connect with both me and Alin on LinkedIn and in the Slack channels here. I hope you had some questions. We did not manage to keep an eye on it while presenting, but thank you so much, and a shout out to all the watch parties. It looks really awesome.

Host Closing (Gene Kim)

Fantastic. Thank you, Mili and Alin. By the way, that stat on faster ARR growth is mind-blowing. I am going to be asking for citations, and you will be hearing from me. Thank you so much.