We had a small team, so every service was officially owned by everyone. In practice, a developer could finish five hours of work in a specialist application and then spend three weeks integrating and testing it against the legacy API.
The delay was not a queue in front of another team. There was no other team. It came from a system which had evolved through changing commercial priorities, agencies, freelancers, and eventually an internal development team. Plenty of individual decisions made sense when they were made. Their combined cost still landed on the next person trying to change anything.
Shared ownership was not the problem. Treating every part of the system as equally safe to change was. A small team still needs to put its most relevant experience where mistakes are expensive, without turning today’s assignment into permanent territory.
Ordinary work revealed the real boundaries
We did not need an organization chart to find the boundaries. Repeated changes showed them.
Service-point work often crossed the legacy API, a postal lookup service, and a location service. Billing usually stayed inside its specialist service, but often crossed the API because the API supplied the initial data. The API was the recurring integration and postponement point in both paths.
One difficult project would not have proved much. This was the same system repeatedly extending a small change’s lead time, test surface, and failure risk. Specialist services moved quickly until they reached the shared dependency. That recurring path told us where experience and review time mattered, whatever the ownership diagram said.
Repository boundaries alone would not have proved this. Three repositories can still share a release, writable data, or one person who understands the contract. One repository can contain modules changed safely by different people. The evidence was the repeated path a change had to travel and the operational consequence when it went wrong.
Fast delivery is not a character flaw
The architecture was the larger problem, but it was not the whole problem. “Ship the smallest thing, learn, and improve it later” is not inherently reckless. Companies exist to sell things, acquire customers, and respond to opportunities. You cannot freeze delivery for six months every time the code is unpleasant, and sometimes carrying known debt is the less dangerous choice.
The tactic fails when the system makes “later” implausible. In this API, a shortcut could sit beneath another customer integration before the repair was scheduled. The next urgent request then inherited both the old constraint and the new debt. The useful unit of analysis was the delivery system: its incentives, feedback delay, repair capacity, and review paths.
I was the CTO, so this was partly mine. I could have pushed back harder at times, but you have to pick your fights. You decide which risk is manageable, which shortcut can actually be repaired, and which change is likely to blow up badly enough that it needs a firm no.
That last category is difficult to explain before the failure exists. An engineer can see the current growth curve and know what six more months will do to a brittle path. To someone spending the day in sales meetings, that can sound like expensive speculation. Sometimes the best available evidence is not convincing enough, the business takes the risk, and the failure finally makes the cost visible. That is ordinary company life, not proof that one side is stupid or malicious.
Technical leadership still has to translate the risk. We needed to say which shortcuts were recoverable, which paths needed review, and where a quick delivery consumed more future capacity than the business intended to spend. If those rules lived only in my head, a developer optimizing for today’s request could not apply them.
The useful questions became:
- Does this path repeatedly turn small changes into long integrations?
- Are failures concentrated around the same contracts and data flows?
- Which shortcuts have a credible repair window and owner?
- Can review expose the expensive choice before production has to?
Those questions keep the discussion on work, evidence, and consequence.
Put experience where the consequence is highest
We changed work assignments, ownership in progress, and review authority. Business-critical services received more stable senior involvement and review. Lower-risk areas allowed more independent delivery while people learned the contracts around the critical paths. Experience counted; title and years served did not make every change equally safe.
The assignment followed operational consequence. The same team member could need close review in one service and be the strongest available owner in another. The boundary followed the work and demonstrated familiarity, not a permanent rank.
The change still had a cost. Autonomy narrowed in some paths. Knowledge became more concentrated. A boundary which makes today’s service safer can make tomorrow’s staffing more fragile if it does not create a route for someone else to learn.
During the period I observed, delivery became faster, reliability improved, bugs fell, and operating cost went down. I did not observe a compensating operational or financial downside. That does not prove tighter control is always better. It means the risk distribution fit this system better at that time.
Shared ownership should mean the team shares responsibility for the result. It does not require every person to make every high-consequence change alone.
A boundary needs a route through it
An assignment becomes destiny when “not yet” quietly turns into “never.” The answer is not to remove every constraint. It is to make the path across it observable.
For a business-critical service, that path can be concrete:
- explain the service’s failure and data contracts;
- make a bounded change with an experienced reviewer;
- diagnose a real test or incident trace rather than completing a tour;
- review another change and identify its operational risks; and
- own a change through deployment and observation with backup available.
Completing those steps does not award permanent seniority. It produces evidence that the constraint can be loosened. A later change in the system, team, or failure profile can tighten it again.
Pairing is enough when the gap is familiarity. Mandatory review may be enough when implementation judgement is sound but the service is unfamiliar. A temporary working group may be better when one change crosses several specialties. Stable ownership is useful when repeated work and operational consequence justify it.
Use the least restrictive mechanism that manages the risk you can actually show. Anything heavier needs to earn its cost.
Service boundaries answered a separate pressure
We also considered keeping the system as a Laravel modular monolith. That would have avoided network boundaries and made local refactoring easier. We rejected it because the existing application was already struggling with the traffic it carried, and the specialist workloads had sharply different scaling needs. Tracking cost roughly twelve times as much to run as postal lookup.
Putting both into one scaling unit would make the cheaper workload pay for the expensive one. Keeping them separate allowed capacity and failure work to follow the workload. Binary deployment also became simpler for us than the symlink and zero-downtime release machinery around the Laravel application.
Services are not the permanently correct shape either. A modular monolith would become credible if enough services disappeared, scaling profiles converged, and independent release stopped buying anything. The network costs us every day, so the boundary has to keep earning its place.
Team structure should be held to the same standard. If the risky system becomes easy to change, contracts become observable, and familiarity spreads, narrow ownership should relax. If one specialist remains the only safe route through the code, the boundary has reduced immediate incidents while preserving a different operational risk.
Ownership is an allocation, not an identity
The company and people in this account are deliberately anonymous. The numbers and outcomes are my recollection of the case, not a claim that repository topology can prove team behaviour or morale.
The case changed what I mean by shared ownership. Everyone can be responsible for service quality while work is still assigned according to familiarity, consequence, and the learning path available. A small team does this every day whether it admits it or not.
The boundary is doing useful work when it protects a dangerous path, helps the company keep delivering, and teaches another person how to cross it. It has become destiny when it protects territory instead of the system.