Article 11: Multiple Projects. Multiple Teams. Multiple Failures...

Let me be honest about how this series actually started.

Not with a framework. Not with a plan. With a team and a hype cycle.

The first project. I started with a full team. Everyone excited. AI agents everywhere. Features flying out. The speed was intoxicating and for a few weeks it felt like we had found something genuinely new.

Then I watched the hype run the project.

The Real Series Arc: Project by Project

Project 1: The Hype Era

Full team. AI agents everywhere. Speed that felt like a superpower. Decisions in chat sessions nobody else could find. Features built in parallel that contradicted each other. Standups turning into archaeology. Took the project back.

The Transition: Building the System

Slowed things down. Started writing things down. Step sequence. Task files. Handoffs. Registers. The methodology built from wreckage, one rule at a time, each one earned from something that broke without it.

Multiple Projects: Testing and Refining

The system applied across projects of different sizes, different teams, different domains. Each project added a lesson. Each failure refined a rule. The methodology stopped being reactive and started being intentional.

This Series: The Condensed Record

10 articles. Everything learned. Not theory: the cost of learning without the system, and what it gave back when the system finally held.

What Breaks When a Team Vibe Codes.

One developer vibe coding creates fragmented context. [1] Two developers creates contradictory context. Three creates compounding contradictions that nobody can untangle without stopping the entire project.

Lost Decisions

Every developer has their own session history. Every session made its own assumptions. None of it written down. None of it visible to anyone who wasn't in that chat.

Contradictory Builds

Developer A builds against one assumption. Developer B builds against a different one. Both are technically correct. Together they are broken.

Archaeology Standups

Meetings that spend their time reconstructing what was built, by whom, against what brief, instead of deciding what to build next.

Unreliable Onboarding

New developer asks questions for two weeks. The answers depend on who they ask and what that person remembers. The onboarding is as fragmented as the project.

What the System Gives a Team.

A new developer joins. In most projects they ask questions for two weeks. They interrupt the people who built things. They make cautious early contributions because they don't want to break something they don't understand.

With this system, they read five documents in order.

The constitution tells them what the platform is and cannot be. The current state tells them where the product is right now. The step sequence tells them everything planned and built. The context handoff tells them where the last session stopped. The task file tells them exactly what is being built today.

In one afternoon they know more about the project than someone who has been asking questions for two weeks. [3] The system onboards without the team having to stop.

Parallel Tracks: The Hardest Thing to Coordinate.

When one developer is building a feature and another is fixing bugs and a third is working on infrastructure, parallel tracks create the same cross-layer breakage problem as parallel sessions. Except now it is between people, not just between chat windows.

The system handles this because every track runs through the step sequence. Every piece of work has a step ID. Every step ID has a task file with scope boundary and cross-layer dependencies documented explicitly. The information that could cause a collision is visible before the collision happens.

This is not coordination by meeting. This is coordination by document. [2] Meetings are synchronous, interruptive, and leave no record. Documents are asynchronous, non-interruptive, and leave a permanent record that any agent can read.

Who Owns What on a Team.

Ownership: Clean Lines, Non-Negotiable Boundaries

Architect

Owns every design decision, every scope boundary, every go-ahead. Nobody else gives go-ahead. Single point of accountability for what gets built and why.

Sole authority

Planning

Any developer can run a planning session. But the task file output is reviewed and locked by the architect before any coding begins. Planning is collaborative. Go-ahead is not.

Shared carefully

Coding

Owned by whoever is executing that step. They run the session, update documentation, write the context handoff. The handoff is their accountability, the record of what they built and what the next person needs.

Step executor

Step Sequence

Shared truth. Nobody updates it without reflecting a real status change. Nobody adds a step without architect approval. The sequence is the project's heartbeat. Its integrity is everyone's responsibility.

Shared truth

What Scales. What Doesn't.

✅ Scales to any team size

→ The five-layer document system
→ More eyes on step sequence = fewer gaps
→ More handoffs = richer context not thinner
→ Onboarding without interrupting the team
→ Parallel tracks coordinated by document

❌ Does not scale

→ Verbal decisions never written down
→ Work built outside the step sequence
→ Sessions closed without handoffs
→ Go-ahead given by anyone other than architect
→ Memory as the coordination mechanism

The Retrospective Across All the Projects.

If I could go back to the first project, the one that started with a full team and a hype cycle and no system, I would do one thing differently.

Not a different tool. Not a different team. Not a different deadline.

What I Would Do From Day One

Constitution first. Step sequence second. Task file for the first feature before the first session opened. Context handoff before the first session closed.

The speed would have been the same. The output would have been the same. The breakages would not have happened. The contradictions would not have accumulated. The archaeology standups would not have been necessary.

The methodology does not slow the work down. It makes the work that gets done actually count. Across multiple projects. Across multiple team sizes. Across multiple failure modes that each added a rule to the list. One methodology. Finally held.

Research & Further Reading

[1] Brooks, F.P., The Mythical Man-Month, Addison-Wesley, 1995: Communication overhead increases combinatorially with team size. In AI-assisted teams, this compounds: each developer adds their own sessions, each with different context. Shared documentation replaces exponentially growing communication channels with a single source of truth. Book
[2] Forsgren, Humble & Kim, Accelerate, IT Revolution Press, 2018: The highest-performing software organizations use asynchronous, document-based information flow rather than synchronous meetings as their coordination mechanism. Documentation-based coordination scales; meeting-based coordination doesn't. Book
[3] Rigby et al., "Quantifying and Mitigating Turnover-Induced Knowledge Loss", ICSE 2016: Demonstrated that structured knowledge artifacts (code reviews, decision records) are the most effective mitigation for onboarding and knowledge-loss risk, more effective than designated human successors alone. Academic Paper

Multiple Projects. Multiple Teams. Multiple Failures. One Methodology That Finally Held. Here's How It Scales.