7 Hidden Incentives that Force Your Team to Rewrite Everything

Engineering Culture & Strategy

7 Hidden Incentives that Force Your Team to Rewrite Everything

Why the most talented creators are often incentivized to destroy what already works.

How many of you actually plan to be at this company when the new system becomes the old system?

I asked this question during a livestream yesterday. I moderate a channel for software architects. The chat went silent. Then someone typed a joke. Then the chat moved on to talk about Rust. People do not like this question. It makes them feel cold.

I feel cold right now because I just ate a pint of double-chocolate ice cream too fast. My brain feels like it has a spike in it. Brain freeze is a literal physical pain. It makes it hard to think about technical debt.

Order Engine

// The Whiteboard Deck Strategy

Sam’s whiteboard: Three markers, two systems, and one inevitable budget approval.

We are at an offsite. The room is in a hotel. The hotel is near the airport. The air conditioner makes a humming noise. Sam is at the whiteboard. Sam is a principal engineer. Sam has been at the company for . Sam is very good at drawing. Sam uses three colors of markers. Red is for the current system. Green is for the new system. Blue is for the data flow.

Sam draws the red system. The red system is a mess of circles. The circles have lines crossing each other. It looks like a ball of yarn. Sam calls this the Monolith. Sam says the Monolith is the reason we are slow. Sam says the Monolith is the reason the developers are unhappy. Everyone in the room nods. They all hate the Monolith. They have to work in the Monolith every day.

The Lure of the Green Boxes

Then Sam draws the green system. The green system is beautiful. It has neat boxes. The boxes have clear names. One box is “User Service”. One box is “Order Engine”. One box is “Payment Gateway”. There are no crossing lines.

The green system is the rewrite. Sam says the rewrite will take . Sam says we will build it in parallel. We will have a cutover weekend in .

Nobody asks about the blue marker. Sam uses the blue marker to draw a small rectangle. The rectangle is in the corner. It has no label. Sam says this is the legacy bridge. We will use the bridge during the transition. Sam moves on. The room stays focused on the green boxes. Someone takes a photo of the whiteboard. This photo will go into the board deck. The board will see the green boxes. The board will approve the budget.

1. The Promotion Document

An engineer needs to show impact. Maintenance does not show impact. If an engineer fixes ten bugs, the system stays the same. The system just works. Nobody notices when a system just works. If an engineer replaces the system, the engineer has a story. The story has a beginning. The story has a middle. The story has a launch.

The engineer writes a document for the promotion committee. The document says the engineer led a transformation. It says the engineer chose a modern stack. It says the engineer retired a legacy system. This document leads to a higher level. It leads to more money.

A rewrite is a career-legible artifact. Maintaining a fifteen-year-old engine is not a career-legible artifact. The engineer is sincere. The engineer wants the company to succeed. But the engineer also wants a promotion. The rewrite is the fastest path to the promotion.

2. The Conference Talk

Engineers go to conferences. They want to speak at conferences. Nobody gives a talk about how they kept a Java app running. People give talks about how they migrated to a distributed architecture. They talk about the new tools. They talk about the scale. They talk about the lessons they learned during the greenfield phase.

The rewrite provides the material for the talk. The talk provides the status in the industry. If the rewrite fails in three years, it does not matter. The talk is already on YouTube. The engineer has already moved to a new job. The new job paid more because of the talk. The incentive is to start things. The incentive is not to finish things.

The incentive is to start things. The incentive is not to finish things.

3. The Parallel Build Fallacy

The plan always involves a parallel build. The team will keep the old system alive. A separate team will build the new system. This is a mistake. The business does not stop. The business needs new features. The old system gets the new features because the old system is where the revenue lives.

Initial Plan

18 Months

Reality

30+ Months (The Loop)

The gap between the “Greenfield” dream and the “Legacy” reality never closes.

The new system must then also get the new features. The new system is always chasing the old system. The gap never closes. The plan becomes a plan. The senior engineers get bored. They leave. New engineers arrive. The new engineers look at the half-finished rewrite. They say the rewrite is a mess. They suggest a new rewrite. I have seen this happen four times in one company. It is a loop.

4. The Invisible Middle

Institutions love beginnings. They love the ribbon cutting. They love the kickoff meeting. They love the launch day. These are visible events. Maintenance is the invisible middle. Maintenance is the work that happens between the launch and the retirement.

There is a process to this decay. It starts with a small change. An engineer is in a hurry. The engineer adds an “if” statement. The engineer does not update the documentation. The engineer leaves the company. The next engineer sees the “if” statement. The next engineer does not understand the “if” statement. The next engineer adds a second “if” statement to protect the first one. This is how the Monolith is born.

We overinvest in the start. We underinvest in the middle. We do not reward the engineer who keeps the documentation current. We do not reward the engineer who simplifies the code without adding features. We reward the person who draws the green boxes on the whiteboard.

5. The Knowledge Gap

Sam has been here . Sam does not know why the system works the way it does. Sam sees a piece of code that looks strange. Sam thinks the code is bad. Sam does not know that the code handles a specific tax law in Brazil. Sam does not know that the code prevents a race condition that happened in .

When Sam draws the green boxes, Sam leaves out the strange code. Sam thinks the new system will be simpler. The new system will be simpler because it is missing the edge cases. The edge cases are the business. When the rewrite reaches 90% completion, the team finds the edge cases. They realize the new system needs to be just as complex as the old system. The green boxes start to look like the red ball of yarn.

6. The Board Deck

The board of directors wants to see innovation. They want to hear about AI. They want to hear about cloud-native strategies. They do not want to hear about refactoring a database schema. Refactoring is expensive and boring. A rewrite is an investment.

The CTO shows the whiteboard photo to the board. The board sees progress. They see a future where the company is a tech leader. The rewrite is a signal. It tells the market that the company is moving forward. This is why the plan is never costed with the reality of turnover. The plan assumes Sam will stay. The plan assumes the team will stay. But the team knows that the reward is in the creation.

7. The Maintenance Story

We need a better story for maintenance. We need to value the people who sustain the engine. The engine is what pays the bills. The engine is what allows the company to buy the ice cream that gave me this brain freeze.

Some companies understand this. They do not look for the exit. They look for the lift. They find ways to make the current system better. They do not build parallel systems that never launch. They put people inside the team to fix the mess from the inside.

The “Pod” Model

Limestone Digital does this work. They do not sell a rewrite. They sell a pod that joins your team. The pod works in your repository. They work in your legacy code. They use AI to understand the code that Sam wants to delete.

15%

Productivity lift found within the first .

Performance metrics in legacy systems

They do not wait for a cutover weekend in . They ship code on Tuesday.

The process of fixing a system is harder than the process of drawing a new one. It requires patience. It requires a memory of why things were built. When I moderate the streams, I see the difference. The engineers who stay are the ones who understand the logic of the system. The engineers who leave are the ones who only want to draw the boxes.

Sam finished the drawing. Sam sat down. The room applauded. The photo was taken. I looked at the unlabelled rectangle in the corner. That rectangle is where the actual work lives. That rectangle is the bridge between the dream and the reality. Sam will be gone before the bridge is finished. The next engineer will look at Sam’s green boxes and call them legacy.

The cycle will continue. We will buy more whiteboards. We will buy more markers. We will keep building new stadiums next to crumbling bridges. We do this because we forgot how to value the person who paints the bridge. We forgot how to reward the person who stays in the room on a Tuesday in .

I need to stop eating ice cream so fast. I need to focus on the red yarn. The yarn is where the truth is. The yarn is what we have to live with when the offsite is over and the markers are dry.

Sam is already looking at a job post for a startup. The startup needs someone to design a new architecture. Sam is the right person for the job. Sam is a creator. We have plenty of creators. We need more people who know how to keep the engine running. We need to change the story. The story should be about the work that lasts, not just the work that starts.