Why Tooling Engineers Think Differently

“Sometimes There’s No Clean Solution There’s only the solution that actually works.”

Interview with Krzysztof Romanowski, Head of Development Productivity at VirtusLab

Software engineering loves process, structure, best practices, and architectural purity. Tooling engineering often lives somewhere else entirely - in edge cases, uncomfortable tradeoffs, and systems that only work because somebody deeply understands how they break. We sat down with Krzysztof Romanowski to talk about why tooling engineers often think very differently from the rest of the industry.

From the outside, tooling engineering can look very similar to regular development. Why do you think it’s actually so different?

From a distance, it can look almost identical to regular software development. Similar technologies, similar-looking problems, even similar programming languages. But in reality, the work is fundamentally different.

In most software teams, the domain is something external -  finance, automotive, healthcare, logistics, marketing. Developers build software for someone else’s world. In tooling, the domain is software engineering itself. You build software that exists purely to help people build software better. And what makes tooling unique is that the users and the developers are often the same persona.

In traditional software development, you usually have different people involved: developers, testers, business analysts, product owners, and often several other roles along the way. Entire processes exist because the people building the system don’t fully understand the people using it.

In tooling, that separation mostly disappears. The person building the system already understands the problem because they live inside that environment every day. That changes everything. Suddenly, one person can often do work that would normally require multiple roles and layers of process.

What changes when developers already deeply understand the domain they're building for?

A lot of modern software processes were created as a kind of medicine - a way to compensate for the fact that developers usually don’t fully understand the business domain they’re building for. But if the “disease” isn’t there, you don’t always need the medicine.

And that’s actually difficult for many people. A lot of developers become so used to process, ceremonies, KPIs, and organizational structures that when those things disappear, they feel like they’re somehow not delivering value anymore, even if the impact of their work is enormous.

So tooling development is much more domain-heavy than people assume?

Much more. People often think tooling is simple because, at the end of the day, it’s “just code manipulating code.” It sounds deterministic. Predictable. But the reality is the exact opposite.

There’s a reason one of the most famous compiler books is informally called the Dragon Book. Compiler engineering is notoriously difficult. And compilers are sometimes the simplest part of tooling. A compiler only answers one question: “Here’s my code, turn it into machine instructions.”

Tooling operates on a much bigger level. It deals with workflows, integrations, IDEs, build systems, distributed environments, developer behavior, scalability, debugging, automation, infrastructure, and dozens of constantly changing parameters. The number of moving parts is enormous. And expectations are brutal because developers assume their tools should always work. IDEs should always respond instantly. Builds should always succeed. Integrations should always behave correctly regardless of configuration, scale, or environment.

Meanwhile, the ecosystem underneath is incredibly complicated.

Why do you think tooling is still underestimated?

Because software engineering still isn’t really a mature industry. If you look at manufacturing, factories invest massive amounts of effort into optimizing production systems and tooling. Everyone understands that if your production process is inefficient, you lose.

Software engineering is still surprisingly craft-oriented. It’s closer to craftsmanship than industrial production. Some people just grab random tools and start building. Others spend half their lives optimizing their environments and workflows. We’re somewhere in the middle of that transition.

I sometimes joke that software engineering is probably the only “serious” industry where the word magic is still considered a perfectly valid technical explanation. 

“How does this work? Oh, it happens automagically.” And everyone just accepts that.

What are the biggest challenges for people working in your team?

One of the hardest things is understanding what “good enough” actually means. A lot of developers naturally gravitate toward one of two extremes. Either they build quick throwaway solutions with very low quality standards, or they try to create perfectly architected systems that satisfy every best practice imaginable. Tooling lives somewhere in between.

Internally, I often think about it through the Pareto principle. That idea that roughly 20% of the effort produces 80% of the outcome. In tooling, you constantly aim for that “correct” 20%. Not random shortcuts. The right shortcuts.

Because nobody has infinite time or resources to build perfect systems, but at the same time, tooling cannot be disposable. These systems often become foundational infrastructure for entire engineering organizations. And it gets even harder because tooling developers usually don’t fully control the environment they operate in. You integrate with external tools, unstable APIs, undocumented behavior, legacy systems, weird edge cases.

It’s not that we don’t know how to build “elegant” systems. It’s that reality constantly forces you into strange compromises, hacks, and workarounds. Sometimes there simply isn’t a clean solution. There’s only the solution that actually works.

So what kind of skills does that require?

Honestly, a lot of it comes down to well-developed common sense. That sounds simple, but it’s actually incredibly difficult. You constantly need to evaluate context: how often this will change, how often it will run, what happens if it fails, how much risk is acceptable, and what the real impact will be. Tooling engineers have to think about the entire ecosystem all the time, not just their individual task. 

And I think one thing many people struggle with is fear. People often treat programming rules, best practices, and architectural patterns as if they were unbreakable laws of physics. But many of those things are more like paper walls. Sometimes the solution is simply pushing through them. You need people who aren’t afraid to go outside standard patterns when reality demands it, while still understanding the consequences of those decisions.

That’s where ownership becomes critical. You can’t really succeed in tooling if you only think about your isolated task. You have to think about the wider system, the users, the integrations, the side effects, the operational impact. Otherwise you eventually break something important without even realizing it.

That combination of ownership, responsibility, and willingness to act is something what we call a Radical Agency.

Do you have specific practices inside the team to support this kind of thinking?

Not really in a formal sense. Tooling teams tend to attract a lot of neurodivergent people, so creating one universal process that works for everyone is actually very difficult. Something that helps three people might make two others deeply uncomfortable.

What matters much more is psychological safety. I want people to feel completely safe asking questions, discussing “weird” ideas, or proposing unconventional solutions without fear of being punished or ridiculed for it.

We also try to build a kind of fascination around unusual solutions. That’s a dangerous thing if pushed too far, because people can start inventing complexity just for the sake of being clever. But I also want people to understand that sometimes “weird” solutions are perfectly valid  because reality itself is “weird”.

A lot of good brainstorming also comes from shared frustration, honestly. Teams bond over difficult systems and complicated problems, and that naturally creates collaborative problem-solving. Sometimes an entire team needs to collectively understand a problem before one person can move forward with a solution.

You use the term “Radical Agency” to describe the mindset needed in tooling engineering. What does it actually mean to you?

I like that term because it combines two things that are both extremely important. The first is agency. This natural drive toward action and execution. Some people are incredibly goal-oriented. They just push forward no matter what. 

But pure agency can also become dangerous. People with very high agency can turn into what I sometimes call “glass cannons.” If they’re pointed in the right direction, they can achieve incredible things. If they lock onto the wrong objective, they can create massive problems. That’s why the “radical” part matters so much to me. It comes partly from the book Radical Candor, which had a huge influence on me. The core idea is that honesty only works properly when it’s paired with genuine care for other people.

And I think the same applies to engineering. You need the drive to push forward and solve difficult problems, but at the same time you need awareness of the bigger picture - the people around you, the project, the long-term consequences, the tradeoffs. That balance is incredibly important in tooling.

Sometimes you absolutely need to push aggressively toward a solution because timing matters. But at the same time, you need enough awareness to stop yourself when necessary and rethink the direction. That combination - strong execution combined with broader awareness and responsibility is probably the single most important thing I look for in tooling engineers.

What actually motivates people to stay in this kind of work long-term?

I think a lot of people in tooling are motivated by the fact that the work feels very real. There’s less corporate theater. Less process for the sake of process. Less political overhead. The domain stays deeply technical all the time.

Even “boring” tasks can usually be approached in interesting ways. If you enjoy debugging difficult systems, solving non-trivial problems, understanding how things work under the hood, or building unusual solutions, tooling gives you a constant stream of that kind of challenge. And once many people enter tooling, they honestly don’t want to go back. I understand that very well because I’m exactly the same.

There’s something deeply satisfying about taking a complicated technical problem and finding a way through it. Even when the work is difficult, the domain itself stays close to engineering, close to technology, and close to the kind of problem-solving that makes people want to keep doing this.