A company wants customers to reschedule a maintenance appointment without calling an operator. The change sounds small, but it needs work from the website, scheduling, customer-records and notifications teams. Each has a separate backlog. The request waits in four queues even though nobody refuses to help.
Adding more services will not necessarily change that journey. First, ask why one customer action requires these particular handoffs. Some dependencies may be necessary. Others may reflect an arrangement that once suited the departments but has become expensive for the product.
Communication is more than an organisation chart
In “How Do Committees Invent?”, Melvin Conway connects the structure of a designed system with the organisation's communication structure. Reporting lines reveal only part of that structure. Two teams with different managers may make decisions together daily; colleagues in one department may communicate entirely through tickets.
This is a useful lens, not a formula for predicting every software component from the staffing plan. Existing data, security requirements, product constraints and accumulated code matter too. Renaming a department does not remove them.
For rescheduling, identify who understands the whole journey, who can change its rules and who can release the result. If these are different people with conflicting priorities, a shared meeting will not necessarily resolve the problem.
Find out what each handoff costs
Trace several completed changes from the initial request to actual customer use. Separate time spent working from time spent waiting. Where was the requirement clarified? Where did work wait for a specialist? Where did a finished change wait for a coordinated release?
Not every approval is waste. A new way of handling personal data needs an informed decision. That differs from seeking permission again for a previously agreed class of change. In the latter case, an accessible, verifiable rule may be more useful than another meeting with the same people.
Check decision rights as well. A team may understand the work but lack authority to change a contract, a data model or a release process. Adding a developer will not remove that queue. Someone must decide which decisions can be delegated and within what limits.
Avoid turning this map into a ranking of slow departments. A shared specialist team may be handling incompatible priorities from several products. Moving its waiting time outside the measured stage improves the report, not the customer's delivery date.
Organise for an outcome without making every team build everything
In this example, a durable team could own the appointment journey: the interface, relevant rules and tests. Scheduling expertise participates directly, and a routine release no longer requires a separate project in every technical layer. Deliberately choosing team interactions to support the desired architecture is often called the inverse Conway manoeuvre.
DORA describes loose coupling through practical capabilities: teams can change, test and release their work without constant coordination with neighbours. Counting services does not establish that capability. Clear modules in one application can help too.
The appointment team need not build its own email infrastructure, identity system and database operations. It can consume common capabilities through an internal platform. Useful autonomy is the ability to deliver a product change within understood boundaries, not an obligation to master every technology the company uses.
The boundary must also make technical sense. While several teams directly update the same tables, their independent plans will collide in data. Agree on ownership of rules and interaction contracts. Module boundaries may be sufficient; deploying each part on a separate server is another decision.
Old dependencies survive a new reporting line
People can move under one manager before knowledge, access and operational responsibility move with them. If the new team is declared autonomous while only a former colleague can perform important operations, the dependency has become less visible rather than less real.
Plan the transition explicitly: who receives incidents, maintains the previous interface, fixes defects and accepts responsibility? A shared release during transition can be reasonable. Indefinite coordination for every ordinary change means the intended independence has not yet arrived.
Splitting too far has a cost of its own. If a customer journey repeatedly crosses new boundaries, teams add negotiation, data exchange and recovery work. Bringing tightly related responsibilities together may help more than creating additional services.
Scarce expertise does not multiply during a reorganisation either. A specialist might collaborate temporarily, train the team or provide a clearly defined shared capability. The aim is to reduce permanent manual dependence, not conceal the same person behind another ticket queue.
Test the hypothesis with the next real change
Start with one flow rather than rearranging the whole company. For appointments, record which decisions the team can now make and which dependencies remain. Then follow the next actual release, including support after launch.
Compare waiting time, required handoffs, rework and the ability to resolve failures. The number of chat messages is not a useful target by itself: a good conversation may prevent a defect. Ask whether neighbours must participate in every routine change.
If delivery improves only because a director personally expedites every request, the arrangement is not yet working on its own. If the team can release within agreed boundaries, consumers understand the contract and customers can reschedule successfully, there is evidence for expanding the approach. That is a more useful result than making the architecture diagram resemble the organisation chart.