Initial thoughts
1. Nobody wants a bugs-only job
2. A fix team does not know the recent code
3. A fix team cannot change the architecture
4. A fix team has an interest in treating the symptom
5. Sharing practices is not required, and often forgotten
6. The authors do not see the consequences of their actions
7. A fix team cannot reduce features for a bug overflow
Wrapping up
Further reading

"You build it, you run it" answers who holds the pager. The team that wrote the code writes the correction. Do not constitute a team whose only job is other people's bugs.

Initial thoughts

Lately I have experienced the damage of separating the teams that build from the teams that fix bugs in production.

The damage reaches quality and speed. It also reaches people. The fun is gone. Some want to leave. Others stay and disengage in silence.

I have worked among development teams for twenty years, and for the last few years at Zenika, where that work has more impact. My concern for efficiency and engagement has kept growing. I had still never seen so clear a case for integrated teams.

That was the moment to research the arguments for "you build it, you fix it."

1. Nobody wants a bugs-only job

Nobody wants a bugs-only job. The seat is staffed with people who did not want it. A dedicated maintenance team is not a fun job: it creates nothing, and it cleans up what others wrote.

They also do not hold the domain deeply enough for a lasting fix. The work is spread across every slice, so mastery of any one slice never forms. Coordination with every other team becomes the job. The patch that fits the ticket is the patch they can ship.

We have sat next to that seat. It was staffed with people who had asked to leave it. That is an anecdote, not the frame. The frame is the chapters below: what the seat cannot do, and what the authors lose when it exists.

2. A fix team does not know the recent code

A fix team does not know the recent code. The bug is in code written lately, not in a stable piece from years ago. The people who wrote that change know which call fails, which flag was a compromise, and which name lies. The fix team starts from the ticket. The ticket is a sentence. The cause is usually a conversation that never left the room where the recent change was written.

Two teams on one fix is the cost of not knowing that recent change. It is not a second principle. The handoff is a meeting, a wrong guess, and a patch that treats what the ticket could see. The team that wrote the change could have named the cause in the time the fix team spent learning the map.

That knowledge is not a document we forgot to write. It is the set of decisions that were reasonable on the day the code was written, and that only make sense to the people who were in the room. Sending the bug away throws that set out with the ticket.

3. A fix team cannot change the architecture

A fix team cannot change the architecture. It has neither the time nor the expertise. The queue asks for the next ticket, not for a redesign. The expertise is not reading the code. It is knowing the decisions behind its shape: which constraint forced it, which trade-off was accepted, which part was meant to move. The fix team did not take those decisions, and it does not know them as well as the people who did.

Access is not the missing piece; they have the repository. They land the smallest change that closes the ticket. The workaround stays. The next feature is built on it, and the workaround becomes the system, because it is what the code now does.

The design change does not leave the team that will write the next change in that slice. That slice has no hand-off for any purpose, including the bug. The hand-off is not a missing permission. It is a patch the owners will not keep, because they are not the ones who wrote it, and they are the ones still extending the code.

4. A fix team has an interest in treating the symptom

A fix team has an interest in treating the symptom. The team is counted on tickets closed. A patch on the symptom closes the ticket today. Looking for the cause takes longer, and it closes nothing more.

The cause is worth more. Removing it fixes the similar bugs that share it, and it stops the bleeding for the months ahead. For a team counted on tickets, that is a worse score: fewer bugs next month means fewer tickets to close.

Chapter 1 is who will take the job. This chapter is what the job rewards once they have taken it.

5. Sharing practices is not required, and often forgotten

Sharing practices with the build teams is not required of a fix team, and it is often forgotten. The build teams write most of the code. They coordinate on its quality: shared conventions, review habits, the failure one team named and the others now avoid. That coordination is how the codebase keeps one shape.

Nothing in the fix seat makes it part of the job. The ticket can close without it. Patches land under other rules, and what the fix team learned about how the code breaks never reaches the teams that write the next change.

6. The authors do not see the consequences of their actions

The authors do not see the consequences of their actions. The bug goes to another queue. The failure, the user who met it, the hours spent finding it: none of it reaches the people whose change caused it. The loop back to the authors breaks.

Whoever writes the patch meets the assumption that did not survive contact with production. If those people are not the authors, the authors keep the same habits, and the next change repeats the same limit.

Responsibility diffuses too. Someone else is now paid to meet the bugs, so the authors produce more of them.

7. A fix team cannot reduce features for a bug overflow

A fix team cannot reduce features for a bug overflow. It does not write the features. An integrated team can put the bugs first when they arrive faster than it closes them. The consequence is fewer new features until the overflow drops. A fix team has no such lever: the features keep shipping, and the overflow stays in the other queue.

The order inside the integrated team is that priority made visible. Production first, then the debt that will become the next production incident, then features. A second queue does not add capacity. It hides the overflow, and the team that writes the features never slows down.

That slowdown is what makes the authors care for the log and the exception. A bad log is a line that does not say what failed. A swallowed exception is an error caught and discarded, so the failure has no trace. If the next overflow comes out of their own feature capacity, they stop shipping those. If a fix team will meet them, the authors never do, and the next feature repeats the same silence.

This reason dies in maintenance. There are no features left to reduce, so a bug overflow no longer slows a roadmap. The case then rests on the other six chapters. Maintenance is that limit. It is not a separate argument, and it is not a phase in which a bugs-only team suddenly becomes the right organ.

Wrapping up

The summary is the contrast between a dedicated run team and the team that keeps what it ships.

Dimension	Dedicated run team	You build it, you fix it
Operational philosophy	Strict functional specialization, a Taylorist split	End-to-end responsibility for the whole life of the system
Symmetry of consequences	None: the authors never suffer the impact of their errors	Total: the developer handles the alert and the fix
Speed of feedback	Delayed (days, weeks), through ticket and support queues	Immediate (seconds, minutes), through direct telemetry and on-call
Architectural incentives	Superficial delivery speed, and technical debt pushed later	Design aimed at resilience, testability, and self-healing
Nature of the fixes	Quick patches, and more side effects	Root causes removed by the people who know the domain
How supervision is run	Too many alerts, notification fatigue, false positives ignored	Noise cut without mercy, granular observability aimed at the service objective
Mean time to recovery	High: context is lost, and someone must reconstruct the path	Very short: the developer knows the execution path intimately
Impact on people	Frustration, loss of responsibility, and high turnover on the run team	Pride of ownership, empathy for the user, a culture that learns