Technical debt in development processes

Recently Andrey Rebrov shared in fb with his readers his speech about “Techdolg in development processes”. With his permission, as part of writing YC alumni books, I publish here his synopsis.

Hello everyone, I’ve been in development since 2008. Since 2013, I have been creating technical debt at startup ScentBird (YC S15), where I am the co-founder and CTO. I am also a technical consultant (helping CTOs) to several startups in the space and gaming industries.

We have 40 people in the company in Engineering, Product Engineering – 55, the total number of employees is 160 people.

Technical debt – previously written code that slows down the development of new product features and, as a result, slows down business development.

Where does technical debt come from?

  • It all starts with the words: “Let’s make an MVP (MLP) as soon as possible.” When the task is to “cut corners” to start faster. In startups, this happens all the time, even here after 8 years.
  • Then there is COBOL and FORTRAN.
  • Each company carries with it not only technical debt in the form of a code, but also in the form of engineering practices (“This is how it is with us”).
  • Outsourcing and outstaffing. Many outsourcing companies have accumulated a number of “internal libraries”. If the libraries do not have an official support, this is a potential problem.

There is no commercially successful project without technical debt. Because there is always a compromise between quality and timing. Here you can recall the words of Reed Hoffman (founder of LinkedIn): “If you are not ashamed of your

the first

version of the product, your product entered the market too late. “

At our company, we came up with the following solution for dealing with technical debt.

It is important to properly balance technical debt tasks with other development tasks. For a team, in an amicable way, it shouldn’t make much difference whether they are working on a business feature or on a technical debt.

For large technical debt tasks, we have introduced a “technical brief”.

For any task for more than a week, we start to make a technical brief. This is a two-page document that explains what problem we are solving, not just playing with technology (R&D).

It is very important to describe what will be the success criteria for this task. “Let’s rewrite” is not appropriate.

What are we going to change? How far will we go with our changes?

For example, at the beginning of this year we implemented Kafka while we had RabbitMQ. We did this specifically for the tasks of the data engineering team, which deals with our analytics, sends events to external systems for sending letters, push notifications, external analytics. They compared everything and Kafka was the best fit. It is not your favorite technology that needs to be brought in, but the technology that solves the problem.

In the document, we indicate the teams that will participate in the project, and the teams that need to be informed that a change has occurred.

With such a brief, you can already come to the product owner or decision maker.

RACI Matrix

  • Responsible
  • Accountable
  • Consulted
  • Informed

Who is responsible, who works with his hands, who makes decisions, with whom you need to communicate on the topic of another task, who should simply be informed.

After these steps, it is impossible for someone to say: “But I was not informed.”

A very cool artifact. I strongly advise everyone who is in engineering management, it helps a lot to dot the i’s.

Once you have a brief, you can achieve a “single roadmap”.

Single roadmap

A couple of years ago, we had the following situation: we were just learning how to properly manage a product, properly manage development, and we had several roadmaps. Product managers – about features, Development – front-end, back-end, SRE, QA automation. Naturally, there were questions of “docking”, who does, who makes decisions.

A single roadmap shows the whole situation – what we do, in what order, where human resources are directed.

Our roadmap has projects of different sizes: strategic initiatives (large activities with several departments for maximum subscribers, revenue, etc.), there are infrastructure projects (warehouse, external ERP integration).

This allows you to see how a small task (about technical debt) advances a strategic task. It also makes it easier to sell technical debt.

The team lead comes to the CEO:

Ability to communicate with business in the language of business, and not in the language of development (as much as you would not like it)


Find out that where you came from is where you wanted to go. Does the product perform better? Has it become more stable? Is it possible to scale now? Sometimes it is very difficult to calculate.

We are now migrating from SpringBoot to Micronaut to make it easier to run service binding on developer machines and to speed up local compilation. The ultimate goal is to improve developer productivity. It is difficult to measure the effectiveness of developers. It is difficult to measure the level of developers’ satisfaction, but it is possible, this is “subtle matter”. You can measure how much memory is used, startup time. We agree on measurable metrics and measure them.

The next stage is a presentation to the team and business. It can be a big circle. In our subproject on the transition to another payment system, we had regular presentations to the business: what is happening now, have we solved the problems, how stable the new platform is. “Look, our lead time has decreased and that’s great.”

a presentation to a team has a different meaning – it is primarily an exchange of experience, knowledge and a solution to the very problem about the bus factor – after switching to a new technology, it is necessary for as many people as possible to know how to use it correctly within our company.

The next point is very important to celebrate.
Very often we are in a stream, doing one task after another, and suddenly we realize that we do not feel satisfaction from our work: yes, we do cool projects, we solve interesting problems, we have an interesting team, but … there is no feeling of joy. It is important when we close the next task on technical debt to gather the developers for a cup of tea and discuss how it came out, what experience they got and what to do next. It is important to remember this. Success must be celebrated.


– How to synchronize the team roadmaps?

I cannot say that we have reached perfection, we have a third approach to how to do roadmaps, most likely not the last. In September, we, as management, determined where we were going as a company. The selected directions began to form into product briefs, they begin to describe: the goal, how it will work, etc. In parallel, I’m working with tech leads and team leads: look where the company wants to come next year, what we need from a development point of view, how much technical debt to remove, and where to invest in our platform in advance so that our platform will allow us to come to the right point. And that’s how technical briefs come in. When both those and those briefs are ready, we come together – we turn the briefs into more accurate and understandable projects from the point of view of practical problem solving. We use Story Mapping – when separate individual tasks appear from the description of processes and flow.

Next year we will be expanding into a new region for us. We understand that for this we need to implement Tenants in databases, reconsider how we do infrastructure, things with data management, GDPR. We talked about functional scenarios, about users, and there are still things related to the system, let’s talk about them and describe them. Tasks from the technical brief begin to appear.

After that, we have all the tasks on the board, we start planning in phases and put them in the backlog. As part of this storymap, we are planning to enter a new region, for us this task is related to the main website, mobile applications, warehouse management system, payment gateway. This is where team synchronization takes place: which team and how much of the tasks will be performed.

When the storymaps are ready, when we have an understanding of what we are going to do and when it is theoretically over (we use rough estimates at this stage), after that the tasks fall on the roadmap, we use color coding, we have a Swimlane for entering a new region, further within it, tasks of different teams and their start date are highlighted in different colors. Every quarter we make a meeting and review our roadmap. We are using this approach now, let’s see what we think in the first quarter of next year.

– What is the difference from OKRs?
OKRs will be on our product engineering team. We are not a technical business (we are not Docker), technologies are auxiliary for us, we have a lot of additional departments: operating systems with a warehouse, business development, design. It is very difficult to introduce a single ORK for the entire company.

Similar Posts

Leave a Reply Cancel reply