"If one door closes, you find another way in. Persistence is one of the most important skills in tooling."
Interview with Karol Skóra, Developer Tooling Engineer at VirtusLab
Depending on the team and project, developers may work from well-defined requirements or help shape solutions from the ground up. In developer tooling, the latter tends to happen particularly often.
We spoke with Karol Skóra about what surprised him most after moving from backend development into tooling and why communication may be just as important as technical expertise.
You moved from backend engineering into tooling relatively recently. What was the biggest adjustment?
One thing that stood out to me is that tooling projects often come with a broader scope and less predefined structure.
While many software teams work with clearly defined tickets and requirements, tooling engagements often start with higher-level goals that still need to be validated and refined.
A large part of the job is understanding what the client is actually trying to achieve, identifying gaps in the original assumptions, and sometimes proposing a completely different approach.
So the role is much more than writing code?
Definitely. If I simply implemented every specification exactly as it was written, many projects wouldn't work correctly. Clients expect us to bring our own expertise, ask difficult questions, and validate their assumptions before we start building.
That's why communication becomes such an important part of the job. You're not just implementing requirements. You're helping shape them.
What's the most challenging part of working with a client?
Persistence. One of the most important lessons I learned is that ownership doesn't stop when you send a message and wait for a reply. . The people we work with are often highly experienced engineers balancing multiple priorities and responsibilities. Communication doesn't always happen on the timeline we'd prefer, so it's important to keep the momentum going and make sure important topics don't get lost.
What does ownership mean in practice?
For me, ownership means taking responsibility for the entire outcome, not just the code. You're expected to drive the project from the initial idea all the way to production. You can't simply say, "I was waiting for someone to answer me." The expectation is that you'll find a way to move things forward.
That's been one of the biggest differences compared to some of the product and backend projects I've worked on.
Can you give an example of a problem that turned out to be much more complicated than expected?
One project looked like a relatively straightforward integration. After digging into the client's internal tooling, it became clear that some important constraints had been overlooked in the original specification. To solve the problem, I had to understand an entire system from end to end and eventually propose a workaround that wasn't part of the original design.
What was initially estimated as roughly one month of work ended up taking almost four months because the real complexity only became visible after we started investigating.
Another example is my recent project involving an integration test migration. What started as a seemingly simple script quickly turned into a multi-stage migration process. After analyzing the scope, we realized the original approach wouldn't scale. Entirely on our own initiative, we designed a complex algorithm to select and batch projects based on custom rules, making the whole transition easier to execute and review. Without any guidance from the client, we had to identify the bottlenecks and completely re-engineer the strategy. Sticking to the original plan would have been the easy way out, but it would have taken significantly longer and carried a much higher risk of failure.
Ultimately, these examples show that a sense of extreme ownership is essential in almost every project. You could easily stick to a rigid plan, ignore the big picture, and just stay in your lane - but that rarely drives real value. Given the complex nature of our work, we have to constantly scan the landscape and proactively propose better solutions. Without that proactive mindset, it’s hard to even get a project off the ground, let alone make it a success.
What keeps the job interesting?
The fact that the problems are rarely standard. I enjoy having ownership over a project and being responsible for finding the solution rather than simply implementing someone else's idea.
The work often requires going deep into unfamiliar systems, understanding how they operate, and finding creative ways to solve problems. I personally enjoy that level of exploration and ownership.
You mentioned initiative several times. How important is it in tooling?
It's critical. Recently, I worked on a project that generated huge amounts of output for engineers to analyze manually. It wasn't part of my original assignment, but it was something that bothered me.
I spent some time experimenting with AI and built a prototype that automatically analyzed the results and generated concise reports for developers. What started as a small side initiative eventually attracted interest from the client and became something worth pursuing further.
That kind of proactive thinking is very valuable in tooling. If something doesn't work well, the expectation is not to accept it but to improve it.
What kind of people thrive in this environment?
People who are proactive, communicative, and comfortable with ambiguity. Technical skills matter, of course, but communication is often underestimated. You need to be willing to ask questions, challenge assumptions, and keep conversations moving.
Most importantly, you need to be comfortable working on problems that don't come with ready-made answers although that's certainly true in many other engineering roles as well.
Internally, we often refer to a trait that is particularly important for developers working on tooling as “radical agency.” What does that concept mean to you?
For me, it comes down to ownership, initiative, and communication. It means taking responsibility for a problem and driving it forward until it's solved. The saying "It always seems impossible until it's done" is often proven true in tooling. That's exactly what successful tooling engineers do every day.
