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 across years, changing commercial priorities, agencies, freelancers, and eventually an internal development team. Each period left decisions which made sense under its own pressure. Their combined cost appeared in the next change.
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.
That is different from one difficult project. The same system repeatedly extended a small change’s lead time, test surface, and failure risk. Specialist services could move quickly until they reached the shared dependency. The work graph was telling us that nominal ownership did not describe where experience and review time were most valuable.
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 the working environment mattered too. “Ship the smallest thing, learn, and improve it later” is not inherently reckless. Companies survive by selling, acquiring customers, and responding to opportunities. A six-month technical freeze can be more dangerous than carrying known debt.
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.
Technical leadership owns part of that system. It must say which shortcuts are recoverable, which paths need review, and where a quick delivery consumes more future capacity than the business intends to spend. If those rules live only in the CTO’s head, a developer optimizing for today’s request cannot 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 built familiarity with the contracts around the critical paths.
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.
The least restrictive mechanism which manages the observed risk is usually the right one.
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.
That does not make services the permanent correct shape. A modular monolith would become credible if enough services disappeared, scaling profiles converged, and independent release stopped buying anything. The network has a cost every day, so the boundary must keep earning it.
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.
What the case changed for me is the meaning of 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 writes the boundary down 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.