How I work
From problem to production.
Good software engineering is not just about writing code that works. For me, it starts with understanding the problem, making deliberate technical decisions, building the right solution, and staying involved long enough to see what happens in production.
As a Staff Software Engineer and Tech Lead, I work across that entire journey — from the first questions about a problem to the architecture, the implementation, the product and, ultimately, production.
Problem
Understand the problem before choosing the solution.
In practice
A business-critical application needed to keep updating information as the product evolved. But entering and changing that data had become increasingly complex for the teams responsible for maintaining it.
The problem wasn't just an application that had gone stale. Its data model — and how it had evolved — hadn't kept pace with the product's changes, so tasks that should have been simple required more and more engineering involvement.
For years, that complexity meant IT ended up owning a task that belonged to other teams. We used a major product change as the opportunity to rethink the system: we redesigned the data model to make it more adaptable, and let the teams themselves maintain the information without depending on IT.
The best technical solution usually starts by understanding where the problem really is.
Architecture
Design for the constraints that actually matter.
In practice
The system needed to adapt to frequent product changes without every change forcing a modification to the application's structure.
I redesigned the data model to separate the product's definitions from the system's core structure, using a more flexible composition that allowed adding or changing elements without breaking existing data or historical records.
This also changed who could work with the system. Development teams could maintain the information directly, without every update depending on IT stepping in.
The important question wasn't how much I could optimise the architecture, but how much I could simplify change.
Architecture shouldn't optimise for the system we have today, but for the way we already know it's going to change.
Code
Stay close enough to the code to lead effectively.
I don't need to write every line of a system to lead its engineering. But I do need to understand the implementation well enough to challenge decisions, investigate difficult problems and contribute when the problem demands it.
In practice
The engineering standards I introduced — strict TypeScript, code quality with SonarQube, security scanning with Aikido, testing requirements, structured review practices and automated deployments — came out of problems I encountered while building, not from a list of best practices.
They were adopted across the organisation because each one solved something the team had already experienced.
Technical leadership is not something that happens above the code. It happens alongside it.
Product
Build what matters, not what looks best on a diagram.
In practice
Modernising a store's backend could have meant rewriting it from scratch. It wasn't.
I migrated it progressively to a serverless architecture, keeping compatibility with the existing system, with no downtime and without requiring a coordinated release.
The alternative was technically appealing: a new system, cleaner and designed from scratch. But it also meant taking on all the risk of switching, in one go, a system the business still needed to keep using. A rewrite would have been cleaner to design, and far more expensive if we got it wrong.
The decision was to prioritise evolution over replacement: improve the architecture without turning the modernisation into a project that had to finish before it could start delivering value.
The elegant version of a system is worth very little if the business has to stop while you build it.
Good engineering isn't about maximising the technical quality of an isolated solution. It's about finding the balance between quality, product value, delivery speed and the ability to evolve afterwards.
You don't always need to build the ideal system. You need to build the right next step.
Production
The real system starts when users arrive.
In practice
An application that used to go down during sales campaigns — we migrated it to a new cloud platform.
The change eliminated the capacity problem: the application went on to absorb traffic spikes of up to 10× without degrading.
Years later, we had to modernise the application. We redesigned it to run on a serverless architecture, cutting both infrastructure costs and the effort needed to maintain it.
The experience from the first migration also shaped how we approached the second: this time we designed the change around zero downtime and full backward compatibility, because we already knew where the real risk was.
The risky part of a migration is rarely the new system. It's the transition.
Production gives you information that development cannot: real traffic, real failures, real costs and real user behaviour.
That's why I consider infrastructure, observability, delivery and ongoing evolution part of engineering — not something that happens after the code is finished.
Value
The value isn't in someone liking an idea. It's in what it solves.
An idea can sound good. A feature can make sense on paper. But if it doesn't deliver something to the user or the business, building it is simply spending time on something that doesn't matter.
Before building something, I try to answer two questions:
- —What value does the user get?
- —What value do we get?
If we can't answer those clearly, we probably don't have a feature worth building yet.
In practice
Many of the most important decisions aren't about how to implement a feature, but whether it's worth implementing at all.
When a new proposal comes up, I try to understand what problem it solves, for whom, and what value it brings as a product or business.
Sometimes we know what we want to achieve and think of a feature as the means to get there. In that case, the question is what we're asking of the user to get it: information, time, attention or effort — and what they get in return.
Other times we start from the opposite direction: we believe a feature could be useful to users. Then the question is different: what problem does it actually solve? How many users have that problem? And is it significant enough to justify the cost of building it, maintaining it and getting people to use it?
Either way, the question is the same: what value does it bring?
That's why some features never get built — not because they're technically hard, and not because the idea is bad, but because we haven't yet found a value proposition clear enough.
Building less can also be a product decision.
The loop
Engineering is a cycle.
I don't see these as isolated stages or a linear process. Production changes our understanding of the problem. New requirements challenge the architecture. The code reveals assumptions. Users change what we thought the product needed.
So the cycle starts again.
Technical leadership
Being a Tech Lead doesn't mean having all the answers. It means helping the team make better technical decisions.
Sometimes that means designing an architecture. Sometimes it means challenging an assumption, simplifying an over-engineered solution, investigating a difficult problem, writing a critical piece of code, or helping another engineer find a better approach.
The role changes depending on the problem. The responsibility doesn't:
Keep the technology moving in the right direction while helping the people around it succeed.
I want to stay close to technology while taking broader responsibility for the systems and products we build.
01
Enough distance to see the whole system.
02
Enough proximity to understand the code.
03
Enough responsibility to care about what happens in production.
Contact
Let's talk.
Open to conversations about architecture, platforms and teams. The fastest way to reach me is LinkedIn.
