Build Allies, Not Headcount
Engineering is a partnership, not a transaction. The companies that move fastest are the ones whose engineers actually understand the business.
TL;DR
- Engineering is a partnership, not a line item. Treating it as a pure transaction means you never build momentum
- Domain knowledge is the real asset, not because competitors will steal it, but because it’s what lets you move fast
- Rotating contractors resets the clock. You pay for onboarding repeatedly and never compound your investment
- AI makes domain expertise more valuable, not less. The job is translating business reality into precise language, and that requires deep understanding
- Invest in engineers who care about your problems. They’ll solve things you haven’t even thought to ask for
There’s a pattern I’ve seen play out at multiple companies, and it usually starts the same way.
Leadership looks at the engineering budget and sees a cost center. They see salaries, contractor rates, tool subscriptions. They do the math and decide they can get the same output for less by bringing in a new team, outsourcing a chunk of work, or cycling contractors on shorter engagements.
On a spreadsheet, it makes sense. In practice, it’s one of the most expensive decisions a company can make.
The Hidden Cost of “Fresh Eyes”
When you bring in a new engineering team, you’re not just swapping one group of developers for another. You’re throwing away months, sometimes years, of accumulated understanding.
I’m not talking about code. Code can be read, documented, handed off. I’m talking about the thousand small decisions that don’t live in any document. Why the data model works this way. Which edge cases actually matter. What the customer really means when they say “it’s broken.” How the business actually operates versus how the org chart says it operates.
That knowledge takes time to build. And every time you reset the team, you reset the clock.
The usual justification is “fresh perspective.” And sure, new eyes catch things. But there’s a difference between bringing in fresh perspective and starting from zero. The companies that move fastest don’t cycle through engineers. They keep the ones who know the terrain and give them room to run.
Domain Knowledge Is the Multiplier
Eric Evans wrote about this decades ago in Domain-Driven Design: the most effective software teams develop a shared language with the business, what he called a “ubiquitous language.” When engineers and stakeholders use the same words to describe the same things, ambiguity drops. Decisions get faster. The code itself becomes a more accurate model of reality.
This isn’t abstract theory. Look at Stripe. Their API isn’t just well-engineered. It’s an accurate model of how payments actually work. That didn’t happen because they hired fast coders. It happened because their engineers understood payments deeply enough to translate that complexity into something clean and usable. Patrick Collison has talked about this: Stripe hires for curiosity about the problem space, not just technical skill.
Or look at Shopify. Tobi Lütke built a company where engineers understand merchants’ problems at a granular level. That understanding is why Shopify can ship features that actually match how commerce works, not how a product manager imagines it works from three levels of abstraction away.
The pattern is consistent: the companies that build the best software are the ones whose engineers understand the domain.
The Transaction Trap
When leadership treats engineering purely as a transaction (“we need X features built, here’s the budget, go”) something subtle breaks.
Engineers in that environment optimize for what’s asked. They build what’s specified. They ship and move on. And on the surface, everything looks fine. Features get delivered. Deadlines get met (mostly).
But nobody is connecting the dots. Nobody is saying, “Hey, I’ve been looking at how customers actually use this, and I think we’re solving the wrong problem.” Nobody is refactoring the data model because they can see where the business is heading. Nobody is building the thing you didn’t know you needed.
That kind of initiative only comes from engineers who understand your world well enough to see the gaps. And it only happens when they feel invested in the outcome. When they’re allies, not vendors.
Why This Matters More in the Age of AI
Here’s where it gets counterintuitive.
AI has made it faster and cheaper to produce code. A competent developer with modern tools can build in days what used to take weeks. So you’d think domain knowledge matters less. Just describe what you want and let the tools generate it.
The opposite is true.
When the bottleneck shifts away from writing code, it shifts toward knowing what to build and describing it precisely. That’s a domain knowledge problem. An engineer’s job increasingly looks like this: understand the business deeply enough to describe it in exact terms, then translate that description into working systems.
If you fill that role with people who don’t understand your business, people who are just taking tickets and pushing code, you get exactly what you’d expect. Technically functional software that misses the point. Features that work in isolation but don’t compose into something coherent. A codebase that nobody on the team can explain the “why” behind.
You can hire the best prompt engineers in the world, and they’ll produce impressive-looking output. But if they don’t understand your domain, they’re just generating code that reflects their best guess at what you mean. And “best guess” compounding over months is how you end up with a system that needs to be rewritten.
What the Best Companies Do
The organizations I’ve seen get this right share a few traits:
They treat engineering as a long-term investment. Not a cost to be minimized, but a capability to be developed. They retain engineers and give them time to go deep on the domain.
They build shared understanding. Engineers sit in on customer calls. They understand the business model. They can explain why a feature matters, not just what it does.
They give engineers space to lead. The best improvements I’ve shipped in my career weren’t on any roadmap. They came from understanding a problem well enough to see a better solution, and being trusted enough to pursue it.
They value continuity. Amazon’s two-pizza teams work in part because each team owns a domain end-to-end, for years. That continuity compounds. The team that’s been running a service for three years doesn’t just maintain it better. They build it better, because they understand every decision that led to the current state.
Building Allies
The word I keep coming back to is allies.
An ally understands your problems without you having to explain them from scratch every time. An ally notices issues before they become crises. An ally pushes back when they think you’re heading in the wrong direction, not because they’re being difficult, but because they care about the outcome.
That’s what a good engineering partnership looks like. Not a service provider you call when you need something built. Not a line item you optimize quarterly. A team that’s invested in your success because they understand what success actually looks like.
You can’t buy that on a per-project basis. You build it over time, by investing in people who invest in understanding your world.
David Kerr is the founder of Kerrberry Systems. He builds custom software for businesses that want a partner, not a vendor. Find him on LinkedIn or GitHub.