How we achieved diamond level of product engineering maturity using a customer-centric approach

It's no secret that the key objective of any business product is profit. But does the entire success of a product depend on business features?

I am the head of the competence center for the development of platform solutions and infrastructure for small business systems at Rosbank. The main goal of our team is to ensure stable and continuous operation of services. In other words, our team does not make business deliveries. Instead, we focus on technical things: organizing work with technical debt, monitoring, customer and service support, continuous delivery of these same services, testing practices, etc.

The team includes leaders of all competencies available in business teams (who actually make these very business features), developers focused on service features, as well as specialists who cannot be attributed to any one team – in general, working on everyone. These include Dev-Ops engineers, specialists involved in writing automated tests, customer support and other narrow-profile areas of responsibility, covering a wide range of needs of business teams. While business teams work according to Scrum, platform teams (to which we belong) work according to the kanban principle and concentrate mainly on long-term deliveries that will bring benefits “not right now, but sometime later.”

And here the most interesting part begins: how can a person who is not knowledgeable in technical things and does not understand the value of technical debt show why we are needed at all and why technical debt is important? And in this aspect, I am specifically addressing the business line. Undoubtedly, there are things that lie on the surface. Take the same CI/CD. It is needed to quickly bring the functionality into testing and then into production. Everything is very clear.

What's next?

“You’ve done CI/CD, what else are you doing that’s so useful? What is the value of your team?”

While still working as a DevOps engineer in a newly created RBS team for small businesses (we will only talk about this system in what follows), on which the Scrum development approach was tested for the first time, where we had to both build a CI/CD pipeline from scratch and do other engineering things , I started to wonder:

“There’s a Scrum team, it’s doing something there, I’ve uploaded it to production, and what happens then?”

And then, of course, there are some bugs. Application errors appear that need to be monitored. The first dissatisfied reviews and incidents arise. And here we come to the most interesting part. Developers, engineers, and administrators tend to focus primarily on technical things. In most cases, they don’t care that someone out there is experiencing difficulties with the service, how many people there are, or how they feel.

“There is a bug, I’ll fix it when I have time”

Let me make a reservation right away: my development path in IT began with customer support, and I have sufficient experience in understanding how the client feels, even if I only see a request. Therefore, the tasks assigned to me were initially seen as broader than just being done. You also need to monitor the delivered services, but simply monitoring is not enough. This needs to be done as efficiently and conveniently as possible so that “client pain” is as short as possible and occurs as rarely as possible. This is how our own monitoring product began to develop (but I will talk about this in another article), the main essence of which is quick and convenient notification of problems and their visualization on dashboards.

Step by step, following the expansion of business teams and the emergence of new business products, a vision emerged of what was missing to polish the “customer-oriented engineer”, if not to the ideal, then to a high level. Ultimately, a separate service team was formed, which is designed to ensure this same quality. Our services went through a difficult path from monolith to microservices, and we had enough practice behind us to understand where to move next.

And now the time has come to answer the question: what is the value of a technical team from a business point of view? If from the point of view of business features everything is transparent – there is delivery, it brings money – then why do we need all this technical debt, autotests, monitoring and all this?

The platform team is comparable to invisible front fighters. Its essence is to retain current customers (ideally, so that current customers recommend the application and bring new ones) due to stability and high speed of operation and other engineering approaches to the operation of services. These tasks are precisely solved by well-written autotests, closing security holes, using new technological approaches to back-end\front-end services, developing monitoring, architecture and support approaches to closing incidents.

The main task of the client-oriented engineer was to clearly obtain answers to the following questions:

1. Identify Focuses — what do we need to do as a team first of all to ensure that the client experiences “less pain” when using the product? What will be the parenting goal?

2. What task will we perform??

3. What will it give us? accomplishing this task according to the parenting goals?

When changing the thinking of the technical team to a customer-oriented one and answering the question “How would I like this to work when using the service? What annoys me about the current implementation?» interesting ideas were born, new approaches to the development, delivery and support of the product were formed. An important role in understanding where and how to move was also played by SUS surveys (questionnaire with pre-prepared issue tags) and a schedule Pain Index.

Pain Index (ITSD) is part of the analytical system within the bank, showing the dynamics of the level of client pain and the availability of critical service functionality depending on the growth of the client base, time of day, holidays, etc. in comparison with the same previous similar period.

I’ll say right away: we didn’t always know what was happening with teams in neighboring directions, what approaches they used, but we resorted to this information in really difficult situations, saving our time.

As of today, the bank has started a stream “Engineering pumping“, the essence of which is to help implement centralized standards for the development and reliability of systems. This level of maturity is formed from a certain set of best practices in the following areas:

• Dev-Ops

• SRE

• QA

• Development

• Analytics

• Architecture

Each practice has its own weight, and from their implementation the corresponding level of engineering maturity is calculated, of which there are 6: start, bronze, silver, gold, platinum, diamond. The level of engineering maturity is formed by the ratio of completed sub-practices in each practice:

The calculation is made in general numerical terms:

For each sub-practice within a specific engineering practice (Dev, DevOps, SRE, QA, etc), an incremental value (increment) is calculated:

Increment = “subpractice weight” divide by “the sum of the weights of all sub-practices within the calculated practice” multiply by “subpractice value (0 or 1)”

After calculating the scores, we found that our application had the highest level of engineering maturity not only of all the teams surveyed, but also on a gradation scale (92.8 points).

What's the result?

The value of a tech team, of course, doesn't come from just doing a bunch of cool high-tech tasks or practices. It is precisely because of the change in thinking to customer-oriented and attention to user experience that correct technical debt and tasks.

They may not always be interesting from a technical point of view, they can be routine, long, even exhausting, but this is precisely what constitutes the team's main contribution to customer centricity from a business point of view.

“Profit depends not only on business deliveries”

By postponing the wishes and complaints of current clients about the operation of services, you increase the risk of stagnation due to the constant carousel of old clients leaving and attracting new ones in their place. Avoiding this very risk of stagnation, retention of loyalty/NPS level and there is the value of technical debtas well as sound engineering decisions and practices.