Boundwork: A Team Structure For When Specialization Fails

If you ask the fish why they’re in the ocean, the answer you'll probably get is: “what ocean?”

I’ve watched the same organizational failure repeat for more than a decade across startups, banks and consultancies, and every time the people inside it name the problem as something else. They call it process, or alignment, or a communication issue that one more meeting is supposed to fix.

The standard response is to restructure. Add a layer, hire specialists/contractors, then hire coordinators to coordinate the specialists and coordinators to coordinate the coordinators 🤯. Restructuring the same shape and expecting a different outcome might as well be the definition of insanity, and I haven’t seen it work anywhere.

I call the alternative Boundwork. I made the word up (cause why not?), from boundary and work, because the whole word is intentional. A boundary that carries work is structure, but one that only carries messages is overhead with a job title.

Boundwork runs at 3 levels: how an organization structures itself, how teams operate, and how individuals build. The 3 hold each other up, so if you skip one you’ve weakened the other 2.

Specialization is the root of all evil, that's the provocation and here's the rationale.

Let’s say a company hires a frontend developer, a backend developer, a QA engineer, a business analyst, a project manager and a scrum master. 6 people now coordinate to ship 1 feature, and every boundary between them adds a wait plus a chance for the message to change shape on the way through.

Each of those hires are defensible on their own. A hire looks like an improvement when you look at the hire in isolation, and the cost only shows up in the space between the hires.

3 forces compound in that situation:

Developer communication overhead grows with every person added to the chain. Fred Brooks did the math in The Mythical Man-Month and it hasn’t aged. A group of 10 carries 45 possible channels between them, and most of what travels through those channels is coordination rather than work. Adding the 11th person adds 10 new channels, not 1.

The Peter Principle takes the best builder on a team and promotes them into a coordination role they never trained for. The team loses the person who understood the system and gains an untested manager who now sits between that system and everyone who has to change it.

The Chinese Whispers effect degrades the message at every layer it crosses. A customer describes a pain point to a sales rep, the rep summarizes it for a product manager, the manager writes a ticket, and a developer reads that ticket 3 weeks later without ever hearing the customer say a word. By the time the code ships the original problem is unrecognizable, and the team that shipped it has no way to find out.

Stack those 3 on top of each other and you get the ordinary experience of a large company. Expensive people working hard while the thing the customer asked for arrives late and wrong.

Removing the layers that exist only to carry messages costs less than teaching those layers to carry messages better.

Let me repeat that again:

Removing the layers that exist only to carry messages costs less than teaching those layers to carry messages better.

Bounded contexts tell you which layers are important. Domain-Driven Design uses the term for the boundary inside which a model, its rules and its vocabulary stay consistent (Martin Fowler has the short definition). A company doesn’t have 1 domain. Sales, Payments, Compliance and Marketing speak different languages and change for different reasons, and the only thing they truly share is the business. Line up the structure with those boundaries and the handoffs now carry real work.

The same split repeats 1 level down, inside a sub-domain. A tax software company doesn’t have a team that does tax. It has Company Tax Return, Individual Tax Return and Fringe Benefits Tax, and each one changes on a different schedule for a different reason, so one team owns one of them end to end, including the part where it breaks at 2AM.

However, the challenge here is that each company domain has a different boundary. You can't apply the same patterns everywhere. However, you can apply the principles to discover.

Here’s the test I use: ask who owns the reporting dashboard or the infrastructure.

If the answer is a reporting team or devops team, the company has built a group whose only job is to sit between other teams and their own data, and that’s the layering problem wearing a new hat. Each team builds the reports/infrastructure for the context it owns and integrates them into the shared dashboard/infrastructure team. The dashboard/infra is an integration surface, not a product with an owner.

Not every handoff is worth removing, though.

A payments team that files with a regulator has a boundary that exists in law, and it’s not worth to fight the boundaries that carry a real obligation.

Mob Programming and Pair Programming look wasteful on a spreadsheet, 4 salaries pointed at 1 keyboard. They feel slow for about a week, and I won’t pretend otherwise. The return shows up around week 3, when the defect rate drops and the knowledge transfer meeting stops being necessary, because by then there’s nothing left to transfer since they're working. Together!

2 developers on the same code removes the boundary between the person who wrote it and the person who reviews it. Put 3 or 4 in a mob and the boundary between the team that built the thing and the team that inherits it a year later goes with it.

Group work also cuts group thinking, which sounds backwards until you watch it happen. A developer working alone builds what they already believe, and they don’t find out otherwise until someone else reads the code. A pair argues about the assumption while the code is still cheap to change, and a mob pulls in the person who sat with a customer last week and knows the assumption is wrong.

That all while focus on ONE task at a time, from beginning to conclusion.

And programmers are already built for this. Making logical connections across systems is the gene of the job, so pairing extends that pattern matching across people instead of locking it inside 1 head.

Working together avoids meetings.

Event-Driven Design is where the boundaries get enforced in code. When the Payments context publishes an event and the Compliance context subscribes to it, neither side needs to know how the other stores anything, and neither one’s schema is the other’s business.

Coupling between contexts drops and duplication is justifiable. Cohesion inside each one rises, things that change together remain together. That’s Domain-Driven Design at the level where it either holds or falls apart, and events are the mechanism that makes it hold.

Event-Driven Design is all about Low Coupling and High Cohesion. In my experience 9 out of 10 engineers can't explain what that means.

Collective ownership matters as much down here. When 1 person understands the architecture the bus factor is 1, and every decision that person made turns into tribal knowledge on the day they leave. Mobbing spreads the architecture across the team while it’s being built, which costs less than reconstructing it from git history afterwards.

The Peter Principle arrives at this level too. It takes the developer who designed the event system, promotes them out of the codebase, and turns the system into a black box for the people who now maintain it. In the cases I watched up close, the question of whether they wanted to stop building didn’t come up. The org chart had 1 direction to offer, however, so up they went.

A promotion that separates someone from the work that made them valuable is a demotion the company has not priced.

In the spirit of the Agile Manifesto and the Software Craftsmanship Manifesto, these are the 10 values that hold Boundwork together, and they carry the same caveat those 2 carry: while there is value in the items on the right, I value the items on the left more.

Company values over team values over individual values. A team that tunes for its own numbers can ship fast and still break the contract with the team next door, making the whole company lose.

Solving problems over applying recipes. A recipe holds until the ingredients change. However, a team that understands the problem underneath can adapt where a team that memorized the steps can’t.

Quality over quantity. 10 features with bugs cost more than 3 features that work, and the difference lands in support tickets, in morale, and in the customers who leave without saying why. You are not praised for the bugs you didn't create, so the incentives must be aligned.

Impact over income. If you create an impact the income follows.

Mentoring over managing. A manager tracks progress and get the blame but a mentor builds capability and foster ownership.

Forecast over estimation. Estimation asks how long a task will take and gets a guess back, rarely accurate. Forecasting takes the throughput a team already has and answers when the work will probably land, which is information a company can plan around instead of a promise somebody has to waste time to defend in a meeting.

Fundamentals over implementations. React will be replaced but HTTP will not, so I’d spend the learning hours on the layer that outlives the framework of the year.

Products over projects. A project ends with a handoff, and the handoff is where ownership goes to die. A product stays with the team that built it and never finishes, so they build expertise.

Knowledge over tooling. A developer who understands distributed systems can debug any message queue. A developer who memorized RabbitMQ commands hits a wall at Kafka.

Lean approaches over big bang. Ship a small piece with the means to learn from it before committing the rest, because the cost of being wrong drops with the batch size.

What this does not cover.

Boundwork says nothing about hiring, salaries or performance reviews, and it won’t pick a tech stack. Those depend on context I can’t see from here. What it does name is the structure behind the pain: too much specialization, a message that degrades at every layer it crosses, and promotions handed to people who weren’t asked.

These patterns repeat because they are invisible from the inside. The fish who can't see the ocean.

Boundwork asks 1 question: How many of the layers between your customers and your developers carry real work, and how many are there to pass the message along?

Blogging buzzword-building aside, maybe this should just be called …

… Teamwork 🤷🏼‍♀️

If you liked this, you might like readplace.com, built for exactly this kind of reading.

Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or by replying to this post.