From Code to Business Impact: How I Prioritize Technical Work and Measure Its Value
When an application slows down, an experienced developer doesn’t start rewriting it blindly. They first measure where exactly the problem occurs. And almost always, it turns out to be somewhere completely different from where they initially expected.
Yet when it comes to our task lists, we often do the opposite. Instead of looking for the actual bottleneck, we pick up tasks that merely seem important or those that people are asking for most loudly. As a result, the team celebrates the number of completed tasks, even though that number alone tells the business very little. Especially today, when the market measures the actual return on every decision rather than simply the amount of code written.
My name is Oleksii Talapov, and I’m a Developer Team Lead at Boosta, an IT holding company. I’ve spent years working as a developer before moving into a team lead role, but I still write code every day, so I approach business challenges from an engineer’s perspective. In this article, I’ll share the engineering habits that help me decide what to work on first and honestly assess the value that work brings to the company.
What AI Has Changed
Recently, there’s been a lot of talk across the industry about accelerating software development, and AI has genuinely made writing code significantly faster. Tasks that used to take an entire day can now often be completed in a few hours. But software development hasn’t suddenly started delivering twice as much value to the business.
The reason is that writing code has never been the only difficult part of our work. First, we need to understand exactly what problem we’re solving and choose the right approach. After deployment, we need to verify that everything works and evaluate whether it actually delivered the expected result. When one part of the process speeds up, the others become even more important. After all, the entire process depends on human decisions about what to do now, what to postpone, and what should actually count as success.
That’s why I now value two things in developers more than coding speed alone. The first is the ability to ask the right question before writing any code. The second is the habit of honestly answering that question after deployment. A completed task becomes a result for me only when we can see exactly what it changed for the business. However, engineers don’t develop this perspective overnight.
Four Levels of Engineering “Done”
You can learn a lot about an engineer from what they consider to be “done.” I’ve seen this understanding evolve among the people I’ve worked with, and it almost always goes through the same four stages:
1. The code does what the specification asks for.
At this level, the question “Why are we doing this?” doesn’t seem to be part of your responsibility.
2. It’s done “properly” and built for the future.
Next comes the stage where “done” means that everything has been implemented elegantly. Developers start introducing solutions for the future that might eventually be needed. Most of them never will be, but everyone who joins the team later will still have to maintain them.
3. The system is stable and under control.
Eventually, “done” means that the system doesn’t break because monitoring and failure alerts are in place. This is usually when engineers realize that the most dangerous problems aren’t necessarily the ones that cause visible failures. Sometimes things simply work incorrectly in the background while all the dashboards remain green.
4. A business metric has changed.
Finally, “done” means that something has actually changed in the business. Not everyone reaches this stage because it requires accepting that having code in production doesn’t prove anything by itself.
I’ve always wanted to understand why I was doing what I was doing. I think that’s why the phrase “This is impossible” never stopped me. Almost every time, what it really meant was “It’s impossible to do it the way we originally planned.”
Before releases, we kept running into the same situation: changes made by different developers conflicted with each other, and releases were blocked until someone manually sorted everything out. When the idea of delegating merge conflict resolution to AI came up, the team’s concerns were entirely justified. The model didn’t know the context of the tasks included in the release, and if it made a mistake, someone’s work could be silently lost. So I had one non-negotiable requirement from the start: AI must never make decisions blindly.
Then I became curious about what was actually conflicting. I sat down and investigated. It turned out that in most cases, the correct resolution could be determined:
- Two developers had edited adjacent lines.
- Someone had already introduced the same change.
- One version simply contained all the changes from the other.
There were relatively few genuinely ambiguous cases where two developers had changed the same logic in different ways. Those required actual human judgment. Everything else was simply consuming time.
So I built a tool that resolves conflicts automatically, but only when it can justify its decision. After merging, it verifies that no lines from either side have been lost and that the code still works. Whenever there’s uncertainty, it stops, shows whose changes are conflicting, and waits for a human decision.
Over two months, the tool handled almost 50 merges. Developers are now involved only when their input is genuinely necessary, and releases no longer get stuck because of merge conflicts.
Coming back to what the business actually needs, there’s almost always a workable solution. But for the team to focus on things that truly change the business, we first need to prioritize correctly.
How I Decide What to Work on First
Any prioritization process ultimately comes down to deciding where the team will spend its time. And the same principles we use to identify why an application is slowing down apply here.
The main road.
An application has certain paths through which most of its work flows. Businesses have a similar path: the one through which money flows, from the moment someone discovers a product to the moment they perform the action the product exists for.
Fixing a bug on a page visited by half of all users and fixing the same bug on a page opened once a week may require roughly the same amount of development effort. But from the business perspective, these are completely different tasks.
That’s why my first question is whether a task lies on the main business path. Only after that do I consider its complexity.
The ceiling of improvement.
Amdahl’s Law is useful here. It states that speeding up a part of a system that accounts for 10% of its execution time can improve overall performance by a maximum of 10%.
A good everyday example is a supermarket where the queue starts at the entrance. Having the fastest checkout inside won’t help because it only speeds up the payment stage.
The same applies to product features. If only 5% of customers use a new feature, even a perfect implementation can improve the overall result by no more than 5%.
These tasks are still worth doing, but you should understand their potential ceiling in advance and compare it with the time you’re prepared to invest.
Don’t build things prematurely.
Developers know the phrase “Premature optimization is the root of all evil.” It reminds us not to complicate things that aren’t causing problems yet.
The same applies to features built “for the future.” Additional complexity appears immediately, while the expected benefit may never materialize.
That’s why, during planning, I often ask what would happen if we implemented something three months later. If nothing critical would happen, the task can safely wait. In the meantime, we’ll learn much more about whether it’s actually needed.
Small things multiplied by frequency.
An inconvenience that costs two minutes might seem insignificant. But when it happens 30 times a day to five people, it adds up to five hours every day and more than 100 hours a month.
These tasks are easy to overlook because each individual occurrence seems minor. But once you calculate their frequency, the picture becomes obvious.
We had a similar issue with building stylesheets and scripts — files automatically generated by the system from developers’ code. Every time, it seemed like a matter of just a few minutes: rebuild, fix something, and move on.
But when we actually measured it, the picture changed completely. Over six months, these files had been modified almost 900 times, and in around 300 cases the team had to manually investigate why changes made by different developers weren’t compatible. On top of that, there was the recurring problem of someone forgetting to rebuild the files and having everything get out of sync again.
The fix took one day to implement. Now the system builds these files automatically during deployment, and developers no longer have to touch them. The conflicts are gone, and nobody needs to monitor the process anymore.
The 10-minute rule.
Some small tasks come up in the middle of the day when someone notices something on staging or requests a minor change. Discussing each one at length often costs more than simply doing it.
That’s why I follow a simple rule: if a task takes up to 10 minutes, we do it immediately. If it takes longer, we create a ticket and add it to the shared backlog.
This helps eliminate most discussions before they even begin.
This approach works well for prioritizing product changes. However, there’s always another category of tasks in the backlog that can be much harder to justify: technical tasks.
How to Prioritize Technical Tasks Alongside Business Tasks
Updates, technical debt, security, and infrastructure are rarely requested directly by the business. Yet they determine how quickly and reliably the team can deliver everything else.
To avoid turning this into a never-ending battle between engineers and managers, I translate technical tasks into the language of money and risk.
Technical debt as a tax.
Technical debt makes every new change in a difficult part of the system slightly more expensive than it could be.
So the main question is: how much extra time are we paying on every sprint?
It’s worth paying down technical debt only where it lies on the main business path or where we’re paying this “tax” most frequently.
The cheapest way to do it is often not through a massive standalone refactoring project, but alongside a new feature that already touches the same module.
Updates and security as the cost of risk.
Here, I immediately calculate what happens if we don’t do the work and how much downtime or data loss could cost the business.
When a technical task is described in terms of its business consequences, it doesn’t need to be defended separately. It naturally becomes part of the shared backlog alongside product tasks.
But before taking a task from the queue and starting work, it’s important to understand how expensive a mistake in its implementation could be.
Reversible and Irreversible Decisions
All work-related decisions fall into two categories. Some are like doors you can walk through in either direction. Others close permanently behind you.
Most decisions we make belong to the first category: how to structure internal code, which tool to use, or what text to put on a button. If you get something wrong, you can always go back and do it differently.
In these cases, moving too slowly costs more than making a mistake, so decisions should be made quickly.
The second category is smaller, but much more expensive. These are decisions about how millions of records are stored, which page URLs search engines have already indexed, or the format in which the system exchanges data with partners.
Such mistakes can take months to fix. Sometimes, teams simply end up living with them for years.
When we integrated MCP into our CMS, we had several ideas about how it should work. Initially, the plan seemed logical: store content blocks as files directly on the server and use version history to roll back changes.
But this was exactly where I decided to stop and reconsider. This decision would affect everything else:
- How we would roll back mistakes.
- What would happen during every deployment.
- Whether we would need separate infrastructure.
- Whether AI would even be able to access its own changes.
Reworking this later, once a significant amount of content had accumulated, could take months.
Get Oleksii Talapov’s stories in your inbox
Join Medium for free to get updates from this writer.
So we decided to store everything in the database, with versioning and one-click rollback. No additional servers and no DevOps involvement required.
The first stage went live in production in less than a month. And when we started planning how AI could manage the design of entire websites, it turned out that the necessary foundation was already in place.
Before making decisions like these, I take a step back, even when we’re in a hurry. An engineer’s job is to recognize when a door only opens one way and make sure everyone understands it.
It’s also better to come prepared with alternatives: what we’ll gain from each option, what it will cost us, and which one I’d personally choose.
The business makes the final decision, but it should do so with its eyes open.
Today, AI makes more decisions reversible because prototypes and hypothesis tests can be built in an hour and easily discarded if they don’t work.
But AI can also take us through doors that close behind us just as quickly.
So the cheaper experiments become, the more carefully I examine decisions that aren’t experiments. And once a decision has been made and the task implemented, one thing remains: honestly checking whether it delivered the expected impact.
How to Measure the Impact of Development
A system that can’t be observed from the inside is impossible to maintain. That’s why engineers record everything important in advance.
The same logic applies to business. If we haven’t measured anything beforehand, the question “What did this work actually achieve?” turns into a clash of opinions after deployment.
Measure Before You Start
No developer would say “It’s faster now” without first measuring the baseline.
Yet in business, this happens all the time. A team launches a feature, sees a metric going up, and immediately claims victory, even though the metric was already growing before the release.
That’s why I define the target metric and record its current value before starting work.
If we can’t do that, it’s a signal that we don’t fully understand what we’re trying to change.
Results, Not Effort
The number of completed tasks, lines of code, or hours worked shows how much effort was invested. These metrics are useful for planning.
But different numbers answer the question “What did development actually achieve?”: how many more customers we gained, how much faster the team became, or how many problems disappeared.
Measuring the Impact of Technical Work
The impact of technical tasks is rarely visible directly in sales. But it is clearly reflected in other metrics:
- How long it takes to go from an idea to deployment.
- How often updates break something.
- How quickly we fix those problems.
- How much manual work the team has to do.
For the business, all these metrics indicate two things: how quickly the company can respond to changes and what level of risk it operates with.
Growth and Fluctuations
Some results, such as changes in organic search traffic, take weeks or even months to materialize. They’re also affected by seasonality and competitors.
That’s why I agree in advance on when we’ll evaluate the result and what level of deviation we’ll consider meaningful.
Otherwise, it’s easy to declare victory too early or abandon a good change simply because it hasn’t had enough time to produce results.
Verify the Analytics Itself
Analytics can also fail silently.
Some data stops coming through, a chart drops slightly below where it should be, and nobody notices.
That’s why, before starting every new task, I ask whether we’ll actually be able to see its results. If not, it’s better to acknowledge that before we begin rather than after deployment.
We also cross-check key numbers against independent sources.
For example, we compare registrations recorded in analytics with contact records in our email marketing system.
This once proved particularly useful. After optimizing website performance, our analytics started showing almost twice as few registrations.
Nothing had gone down, there were no errors, and the chart looked like an ordinary fluctuation.
If we’d relied on that chart alone, we could easily have concluded that conversion had dropped and started “fixing” something that was actually working.
Cross-checking revealed that registrations hadn’t disappeared. Some of them had simply stopped reaching analytics.
These are exactly the kinds of discrepancies that are most dangerous: you won’t notice them until you compare the data with another source.
What Can’t Be Measured
Some work eliminates risks that haven’t materialized yet, while other work produces benefits that accumulate slowly.
For these tasks, I don’t invent artificial metrics. Instead, I explain things directly: here’s the risk, here’s what it could cost, and here’s why it’s worth addressing now.
An honest “we can’t measure this” builds more trust than an attractive but questionable chart.
Revisit After Deployment
A few weeks after deployment, it’s useful to revisit the task and compare what we expected with what we actually achieved, without looking for someone to blame.
In my experience, the tasks that teach us the most are often the ones that didn’t work as expected.
However, no prioritization or measurement system will be useful if it only makes sense within the development team.
Communication: Fixing the Interface Between Development and Business
In complex systems, most problems occur at the boundaries between components.
Each component can work perfectly on its own, but if they don’t understand each other correctly, the entire system breaks.
The same thing happens between development and business. If priorities and measurements aren’t communicated clearly, the business might as well assume the work never happened.
Here are the practices I believe help establish the most effective communication:
Ask “Why?” before starting.
This isn’t about questioning the task itself. It’s about making sure the result actually works. These conversations often lead to simpler solutions.
Make sure you’ve understood correctly.
A simple “Am I right in understanding that…?” saves more time than any documentation.
Talk about consequences.
Instead of saying “We need to redesign the data structure,” explain that otherwise every change in this area will cost twice as much a year from now.
Communicate bad news as early as possible.
A problem reported on the first day can be planned around calmly. The same problem reported one day before the deadline becomes a crisis.
Offer alternatives instead of simply saying no.
We can implement everything in two weeks, deliver a partial solution in three days, or spend one day testing the hypothesis first.
The business chooses, while the engineer explains the cost of each option and honestly recommends the one they’d choose themselves.
Document decisions.
Six months from now, nobody will remember why we made a particular choice. A few sentences explaining the reasoning can save weeks of repeated discussions.
Listen.
Developers don’t see the entire picture. There may be agreements with partners, business plans, or other constraints they’re unaware of.
That’s why it’s important to understand the context before starting an argument.
All these simple habits help remove the barriers between development and business and keep everyone focused on the same outcome.
Final Thoughts
When I became a team lead, I thought I’d have to learn a new language: the language of business.
But in reality, I already knew most of it. I’d simply been using it to talk about code.
Finding bottlenecks, understanding the ceiling of improvement, avoiding premature work, distinguishing reversible decisions from irreversible ones, and measuring before and after — these are all things I’ve been doing with web applications for years.
Now I apply the same principles to the task backlog.
AI has changed more than just the speed of development. Many things we used to postpone because they were too expensive or even considered “impossible” can now simply be tried.
For example, we can quickly explore an unfamiliar part of a system, test an idea against real data, or compare several approaches instead of choosing blindly.
There are now far more possibilities. But deciding which of them actually matter to the business is still our responsibility.
What about you? How do you decide what to work on first, and how do you know whether your work has delivered results?
Share your thoughts in the comments. I’d be happy to discuss them.
