Is In-House Developer Experience a Competitive Edge or a Costly Distraction?
Interview with Tomasz Orzechowski, Chief Operating Officer at VirtusLab
As developer experience (DX) becomes a competitive advantage, many organizations are investing in internal platforms and tooling. However, building and maintaining DX capabilities in-house is costly and complex. This raises a key question: when should organizations manage developer productivity internally, and when is it more effective to engage external partners?
Where do you most often see organizations struggle when trying to 'own' developer productivity?
Tomasz: Time. Tech leaders understand the benefits of DX, but their teams are shipping against quarterly deadlines. Experimenting with new tools and processes "in the meantime" rarely works. And the gap between a small team experiment and rolling it out across the whole organization is massive. One example: we cut build times at a tier-1 investment bank from 1 hour to under 10 minutes and reduced the number of required tests by 70%. Results like that are absolutely achievable, but not when DX is a side project owned by people who already have a full backlog.
Is building everything in-house sometimes more about perceived control than real efficiency?
Tomasz: Over the last 15 years, I've had the privilege of working with the biggest organizations and speaking with their leaders. I've practically never seen a CTO who prioritizes "control" over common goals. These people are the smartest beasts!!! who dragged IT systems through decades, assuring business continuity. People are usually surprised when they learn these organizations run hundreds, sometimes thousands of connected systems built over the years. From the outside, it might look like these leaders reject new tools because they want to keep power within the group. But these decisions are based on experience and a quick risk assessment: can this vendor with a new dev tool truly understand the complexity of our systems and actually help?
At what point does building developer experience capabilities in-house stop being efficient and start becoming a liability?
Tomasz: The moment your best engineers spend more time fighting tooling than building features, and there's no one dedicated to changing that. That's the tipping point. What usually happens next is worse: internal teams build quick workarounds to unblock themselves, and those workarounds become permanent. Now they maintain two problems: the original tooling issue and the patch on top of it. Best results come when an external DX team works alongside internal champions who know the codebase, the team, and the politics.
What are the strongest signals that a company should bring in an external DX provider instead of continuing to build internally?
Tomasz: Simple rule: if the backlog is full and the business requires a certain level of system availability, it's obvious where the priorities lie for the internal team. For us, the focus is always on the client's dev team efficiency.
Do companies underestimate the long-term cost of maintaining internal DX tooling compared to working with a provider?
Tomasz: 100%, they underestimate this. We observe that our clients, whom we have consulted and supported for years, have DX teams that are sometimes 5% the size of the whole IT department, a mix of internal engineers and external experts. 5% might sound like a big number, especially for organizations with thousands of software engineers. But increasing overall engineering efficiency can pay it back quickly. Plus, great DX plays a huge role in team satisfaction and retention. A good practice is to tie DX engagements to efficiency outcomes rather than hours. If the numbers don't move, no one should pay for it.
How is working with a DX or platform engineering provider fundamentally different from traditional software outsourcing?
Tomasz: I love talking about DX consulting because it's orthogonal to software engineering. It's not an alternative to in-house software engineers. We have one goal: to make their lives easier. What makes VirtusLab different from most players in this space is that we actually build the tools. We maintain compilers, IDEs, and build systems. Most DX providers either measure developer productivity or provide strategy advice. We do both, and we write the code that makes it real. We start most client engagements with DX advisory or custom dev tools development. And once we deliver great results, we have the best VirtusLab ambassadors inside the client's organization.
Why do some collaborations around developer experience fail, even when the technology itself is solid?
Tomasz: People underestimate the complexity of bigger IT systems. It's very easy to get trapped by magic promises, especially now when automation is topic number one. Building a dev tool that runs great in a greenfield environment is a relatively easy task today. Connecting the same tool into an enterprise legacy codebase is a different story. Think of it this way: there are plenty of shiny cars that look amazing in the showroom. But if you need someone to drive you coast to coast on Route 66, you want a muscle car with a driver who's done the trip before, not a pretty thing that breaks down halfway through the Mojave. We've debugged enterprise build systems at 2am enough times to know that magic solutions don't exist.
Where do you typically see the highest ROI from involving an external DX partner?
Tomasz: Two areas. Build times, where tools like Bazel in monorepo setups cut them dramatically. And simplifying codebase architecture to reduce tangled dependencies. This is more relevant now than ever. Monorepos are making a strong comeback because agentic AI needs full codebase context to work effectively. AI agents in a monorepo can navigate across services, understand shared patterns, and make cross-cutting changes in a single pull request. But setting this up right requires deep, specialized DX knowledge. Most product teams don't have time to build that expertise. That's where an external DX partner delivers real value.
Do you see a future where developer experience becomes a mostly externalized capability, similar to cloud infrastructure?
Tomasz: It's possible. For some of our clients, after years of cooperation and solid results, we provide complete DX care across their organizations. One long-term goal: let their teams focus on business, not tooling. We've earned that trust over 15 years working with top retail, banking, automotive, logistics, and social media companies. We don't talk about it much. We just keep showing up and delivering, often in the shadows.
