How Conway's Law Shapes Software Development Decisions

Compare the software boundary with the decision path#

Use Conway's Law before you scope. If the architecture you are proposing depends on communication paths the client does not actually have, delivery risk is likely already present, even if the backlog looks tidy.

Conway’s Law describes how a system’s structure reflects the communication structure of the organization designing it. Melvin Conway’s own account traces the idea to his 1968 publication. For software delivery, compare the interfaces you need to build with the people who must agree on their meaning. A reporting line alone does not tell you who actually designs or approves an interface.

Use the article in three steps:

Diagnose the client first#

Ask how a real change moves from request to release, and note who must talk to whom for that to happen. Your checkpoint is simple: can you name the owners, reviewers, and blockers around the boundary you are about to build? If ownership is vague or approvals are shared across several groups, do not bury that uncertainty in a generic buffer. Call it out in scope, because unclear communication lines can show up as interface ambiguity and integration friction.

Tighten your own business-of-one#

As a solo developer, use the same mapping exercise to find lost context between your own tools and the client’s decisions. This is an analogy for workflow improvement, rather than evidence that one person’s folder structure determines the software architecture. Trace a recent job and simplify repeated copying, unclear approval and conflicting versions.

Reshape communication on purpose when needed#

The Inverse Conway Maneuver means shaping team and communication boundaries to support a desired architecture. Thoughtworks described it in its 2014–2015 Radar entry. A freelancer can propose a contained ownership or interface change to the client’s decision makers; changing reporting lines requires their authority and a supported transition plan.

If you manage several specialists, How to Manage a Global Team of Freelancers is a useful companion on the people side.

Start with one change similar to the work you are estimating. Reconstruct its technical dependencies and actual decision path so discovery addresses the unknowns that could change cost or delivery.

Map a recent change before committing to its dependencies#

Investigate the communication dependencies that could change your estimate. If an owner or interface is unknown, state the assumption and propose bounded discovery for that dependency; independent work can proceed when its own inputs are clear.

Ask the client for one recent change and trace it from request to release. Use the owner map, approval path, signoff trail and dependency log to distinguish known commitments from unresolved dependencies. They are practical project records, not four documents mandated by Conway’s Law.

Owner map: confirm accountable people, not team labels#

Ask who can approve requirements, who can approve or reject changes, and who signs off release for this scope. If ownership is shared, rotating, or disputed, log it as an open assumption.

Approval path: verify decision records, not verbal process#

Confirm how the relevant change was proposed, reviewed and decided. A ticket, release record or explicit approval message can show the path. If the team works informally, confirm the responsible person and record the current agreement for this scope.

Signoff trail: confirm a real release decision exists#

Identify who can accept or release the affected work and which additional reviews the engagement requires. A named client acceptance owner may be enough for a small delivery; a regulated production change may require several distinct approvals.

Dependency log: name each dependency and owner before promising interfaces#

List teams, vendors, components, repos, environments, and data owners that can block delivery. For each item, include a technical identifier and an accountable contact.

If evidence is missing, scope uncertainty directly#

Use concrete proposal language: “The integration estimate assumes the payments team owns the refund API, provides its contract and test access, and names a release approver. The first discovery task is to confirm those inputs. If the contract changes, we will revise the integration estimate before implementing that dependency.” Apply the client’s actual security and release requirements to the affected work.

Record which missing fact could change implementation, price or release. A small client may confirm a decision in a shared ticket; it need not reproduce a large company’s approval process.

Example: a refund change crosses three ownership boundaries#

Suppose a client asks you to add partial refunds. The checkout team owns the user interface, the payments team owns the refund API, and finance owns the accounting export. The last change waited three days because each group expected another to decide what “refund complete” meant. Creating another microservice would leave that disagreement intact.

A contained pilot could put the partial-refund workflow under one delivery owner while retaining the payments and finance teams’ specialist responsibilities. They jointly settle the interface meaning, record sample requests/events and decide which changes need renewed review. The freelancer estimates the UI and integration work after that agreement, listing any unresolved settlement behavior as a discovery task.

For the next two comparable changes, record waiting time for decisions, reopened interface questions and defect/reconciliation results. Fewer handoffs help only if the required knowledge and checks still reach the design. If one owner becomes overloaded or errors increase, adjust the responsibility split rather than treating the pilot as proof that centralization always works.

Part 2: Treat your solo workflow like a small system#

For solo work, keep the current scope, client decisions and release status easy to find. This improves coordination with collaborators and clients; it does not make workflow hygiene a literal architectural law.

Step 1: Audit one real job end to end#

Pick one recent project and trace it from intake to release. For each stage, capture only these four entities, then apply the matching action:

Work from a single source of truth. Include a status legend, a current-version marker, a named contact path, and a clear pending vs final flag. A practical legend is: Proposed, In Progress, Resolved, Complete. Checkpoint: from one record, can you see what is current, who decides, and whether the work is actually done?

Step 2: Separate automation from manual approval#

Use automation to enforce consistency, and keep human review for judgment calls.

If you use code-owner rules, make sure each owner is a real, reachable reviewer, not a placeholder.

Step 3: Run a repeatable governance cadence#

Use intake, pre-build, pre-release and closeout as practical checkpoints where they fit the engagement. Confirm the current scope, decisions made, unresolved dependencies and actual delivery result. Use existing project records rather than creating a second approval bureaucracy.

If handoffs keep multiplying, use How Gall's Law Helps Independent Professionals Build Systems That Last as a companion lens before adding more process.

Test an ownership change that supports the architecture#

Use this when your intended design keeps failing at handoffs, escalations, or approval bottlenecks. If communication structure is shaping the system, change communication and ownership boundaries first, then ask teams to deliver the architecture.

Run this as a focused workshop on one product area, one service boundary, or one request-to-release path that already shows friction.

Step 1: Set the target architecture in one sentence#

Set the target architecture in one sentence. State the boundary you want, what stays outside it, and who should be able to ship inside it without waiting on other teams.

Use one recent delayed or failed change as the anchor example so the discussion stays evidence-based.

Step 2: Name the org pattern blocking that target#

Name the org pattern blocking that target. Diagnose delivery friction, not just the org chart: interdependent teams, coordination problems, repeated escalation, slow pace, high feature costs, approval drag, or handoff delay.

Map the request-to-release path and mark team touches, decisions and waiting time. Check whether the delay comes from communication boundaries, missing skills, excessive workload or a technical dependency. A delay alone does not prove that a reorganization is needed.

Step 3: Move one ownership boundary to reduce cross-team negotiations#

Test one boundary change, not a full redesign. Move one ownership boundary so routine design decisions need fewer cross-team negotiations.

Team Topologies distinguishes stream-aligned, enabling, complicated-subsystem and platform teams, with collaboration, service consumption and facilitation as interaction modes. For this pilot, name the responsibilities and interaction on each side of the boundary. Labels alone do not create the skills, capacity or interface agreement needed to make it work.

Step 4: Define success signals before rollout#

Define success signals before rollout. Replace vague goals with observable signals: fewer escalations, fewer teams per normal change, less waiting between handoffs, and fewer costly feature requests caused by boundary confusion.

Capture a simple before-state in workshop notes so later decisions are based on measured friction, not memory.

Phased rollout with guardrails#

With the client’s authorization, pilot one boundary for a defined delivery period. Name the routine decision owner, the exceptions needing specialist review and where decisions are recorded. Preserve required security, legal and operational review; direct communication can continue without becoming a competing source of approval. Narrow or reverse the pilot if handoff delay worsens, incidents increase or responsibility becomes unclear.

If your target state also requires cleaner service boundaries, read A Guide to Microservices Architecture for SaaS Applications. If the change depends on clearer cross-team operating rhythms, use How to Manage a Global Team of Freelancers as the companion playbook.

Choose a change you can observe#

You do not need a grand redesign to act on this. You need three concrete moves, in order: diagnose coordination risk from one real change, fix one blockage in your own delivery path, and test one ownership adjustment where decisions keep bouncing.

Before you start, trace one recent change from request to release and gather the records that show how decisions moved. If that path is hard to reconstruct, treat the gap as discovery work instead of assuming the boundary is already clear.

Diagnose client risk from a real change#

Take one recent feature, bug fix, or integration change and trace it from request to release. Write down who asked for it, who owned the boundary, and which teams had to coordinate for it to land. Then compare that path to the module or product area that changed.

Name the routine decision owner and necessary handoffs. When those remain uncertain, qualify the affected estimate and resolve them through discovery. An incomplete org chart or missing historical ticket does not by itself prevent all useful implementation.

Fix your own delivery path before you prescribe theirs#

Run the same test on yourself. Follow one job from inbound request to shipped work and mark every pause caused by split notes, inboxes, approvals, or unclear ownership. If your proposal lives in one place, client comments in another, and release decisions in chat, your delivery will reflect that fragmentation.

Your verification point is whether one view of the work shows the current owner and the next decision. If you cannot tell what is blocked without searching across tools and messages, you likely have a hidden queue. Fix that before you recommend process changes to anyone else.

Choose a structural change you can monitor#

When the same boundary causes repeated negotiation, propose one clear owner for that area first. If the issue is wider, use the Inverse Conway Maneuver deliberately: define the target architecture, analyze the current structure, and ask for a restructuring plan that includes a timeline and a communication strategy. Then implement in phases and monitor it, rather than changing everything at once.

If your evidence points to one recurring coordination problem, a smaller move is often easier to test first. If the mismatch appears across several boundaries and leadership is prepared for phased change, a broader reorg may be justified.

Bring one recent change record to the next scoping discussion. Name the affected interface and decision owner, separate assumptions from confirmed inputs, and propose one improvement with a review date. The microservices architecture guide is useful when that discussion also involves deployment and service boundaries.

The CI/CD guide covers automated delivery checks and release workflows when those are part of the boundary you are improving.