Creating the Ultimate Office Space for Our Growing Team

When an engineer leaves a software team, the visible cost is a vacancy. The expensive cost is invisible: the context that leaves with them, and the months the rest of the team spends rebuilding it.

We've seen this play out across client projects for years. This post covers what walks out the door when someone leaves, how to think about the real cost, and a simple framework for making better decisions when it happens, whether you work with us or not.

The short version

• Turnover costs capacity for weeks. It costs context for months.
• Context is specific and nameable: decision history, business constraints, platform knowledge, and working agreements.
• The reflex to replace the exact profile that left is often the most expensive option. Sometimes the answer is already on your team.
• You can evaluate any software partner on continuity with four questions. We include our own answers below.

What does a software team lose when someone leaves?

A software team loses two things when someone leaves: capacity and context. Capacity is visible and replaceable. Context is neither.

Context sounds abstract, so let's make it concrete. It comes in four forms:

A new hire can match the departed engineer's skills on day one. The four things above take months to rebuild, and while they're being rebuilt, the whole team pays: meetings run longer, settled decisions get relitigated, and senior people spend their time explaining instead of building.

What is the cost of developer turnover?

The cost of developer turnover is the ramp-up period multiplied across the team, not the recruiting fee. The math works like this:

The replacement operates below full productivity for months while they absorb the four types of context above. During that same period, the existing team diverts hours to onboarding, re-explaining, and reviewing more carefully than usual. So the cost is one person's ramp-up plus a productivity tax on everyone around them, at exactly the moment the project needed continuity.

This is why turnover gets underestimated. On the day someone resigns, it looks like an operational issue: fill the seat, keep moving. The bill arrives over the following two quarters, itemized as slower delivery, longer meetings, and decisions that used to be obvious.

Why replacing the exact profile is often the wrong reflex

The first thought is to backfill with an identical hire. Sometimes that's right. But the skill that is left with that person may be easier to replace than the context they gained: the client relationship, the platform history, and the judgment behind past decisions.

Someone already on the team may be able to learn a specific skill faster than a new specialist can learn the client, the platform, and the history behind the work. For a real example and four questions to ask before starting a search, see “Why adding people doesn't always fix a struggling team.”

How to evaluate a software partner on continuity

If you work with an external team, their turnover becomes your turnover. Four questions tell you most of what you need to know, and any serious partner should answer them with numbers:

What's your team retention rate? Ours has averaged 96% in recent years. Whatever the number, ask how it's measured and over what period.

How do you know people want to stay? Retention tells you what happened. An engagement measure tells you what's coming. Our eNPS (employee Net Promoter Score) is +83.

How do you spread context across the team? One person holding all the context is a risk with a name: bus factor. Ask how knowledge gets documented and shared, so continuity doesn't depend on any single individual.

Do you prepare capacity before it's needed? On some projects, we bring people up to speed on the business and the platform before there's an immediate need. When the project needs more capacity, nobody starts from zero.

These questions work on any vendor, including us. That's the point.

AI has changed what Product Managers can do.

A PM can now go from an idea to working software in hours. They can build a flow, put it in front of a customer, learn from it, change it, and test again without waiting for every iteration to go through Engineering.

That creates an opportunity for product teams. It also creates a new challenge.

Just because a PM can build something doesn’t mean that thing is ready to become production software.

If we don’t rethink how Product and Engineering work together, faster prototyping can become more code for Engineering to untangle, more unclear ownership, and more pressure to turn experiments into production features.

The answer is to separate exploration from construction.

PMs and engineers are solving different problems

During product discovery, the PM is trying to answer: Should we build this?

That means testing assumptions, changing direction quickly, throwing things away, and getting something real enough in front of a customer to learn from it.

Engineering is solving a different problem: How do we build this correctly?

That means thinking about architecture, security, maintainability, performance, edge cases, and everything else required for software that has to live in production.

Both need AI. But they don’t need the same working conditions.

Exploration benefits from speed, autonomy, and low friction. Construction needs stronger guarantees and guardrails. Trying to optimize the same environment for both creates tension.

So instead of asking how PMs can safely contribute code to the production codebase, there’s a more useful question: What if PMs had their own space to build and validate ideas?

Give PMs a safe place to explore

A PM working with an AI coding agent can build functional versions of new ideas. Not a Figma screen. Not a ticket describing what something might do.

Working software that can be used to test the product experience. The important part is that this environment is separate from production.

That boundary gives the PM freedom to experiment without requiring the same controls we’d expect from production software. The environment can be designed so experiments can’t affect the live product or access things they shouldn’t.

Now the PM’s workflow can look more like:

Idea → build → test with users → learn → iterate

Engineering doesn’t need to be pulled into every cycle.  Engineering still matters. It  gets brought in once Product has stronger evidence about what’s worth building.

The prototype shouldn’t be the handoff

This is where things can go wrong.

If a PM spends two days building something with AI and then gives the repository to Engineering saying, “It mostly works, can you finish it?”, we haven’t improved the product development process. We may have just moved the mess downstream.

The prototype should help answer product questions. It shouldn’t make technical decisions on Engineering’s behalf.

What Engineering needs from exploration is intent.

• What does the feature need to do?
• How should it behave?
• What did we learn from customers?
• What happens in the important edge cases?
• How will we know when the production version works as intended?

That becomes the handoff.

At Kaizen, we’ve been exploring a model where the bridge between the two cycles is a behavioral specification and a test plan, supported by the working prototype as a reference. The implementation itself stays behind.

What crosses into construction is the spec: a behavioral description, a test plan, and a link to the prototype as reference. The prototype itself stays where it was built.

In simple terms:

Product owns the what. Engineering owns the how.

That distinction matters even more now that AI makes it so easy for both sides to generate code.

What the workflow could look like

A PM starts with a product hypothesis. Instead of immediately turning it into a backlog item, they use AI to build enough of the experience to test it. They put it in front of users. They discover that part of the original idea was wrong. So they change it. They test again.

Once the problem and desired behavior are clear enough, the PM closes the exploration cycle with a clear specification and acceptance criteria.

Engineering then starts from that understanding, not from the PM’s experimental code only. They decide how the feature fits into the architecture, how it should be implemented, what needs to be verified, and how it reaches production.

The result is two parallel forms of autonomy:

• PMs don’t need Engineering for every experiment.
• Engineers don’t inherit implementation decisions from every experiment.

More autonomy doesn’t have to mean less ownership.

AI can make discovery faster

A lot of the conversation around AI in software teams is still about developer productivity. How much faster can we write code? How much implementation can an agent take on?

Those questions matter. But for Product, there may be an even bigger opportunity upstream. AI can shorten the distance between having an idea and learning whether that idea is any good.

That changes what PMs can bring to an engineering team. Instead of: “We think customers want this.” They can increasingly say: “We tested this behavior with customers. Here’s what worked, what didn’t, and exactly what we now need the product to do.”

That’s a much better starting point for building production software.

If you have a prototype and want to take the idea into production, we can help you determine what needs to happen next.