HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Conway in Tech Management's Law

Learn about Conway in this comprehensive Tech Management tutorial. Architecture mimics communication.

⚡ Total XP: 0|💻 management XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.

🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.

1The organizational structure

'Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.' If you have a separate Frontend team, Backend team, and Database team, your software will naturally become a 3-tier monolith, and every feature will require 3 teams to talk to each other (slow). Cross-functional Feature Teams break Conway's Law.

2Step-by-Step Breakdown

The Limit. Scrum works beautifully for a team of 10. But what if you are building the software for an autonomous car, and you need 500 developers? Standard Scrum breaks down.

Nexus Framework. Created by Ken Schwaber (co-creator of Scrum). Nexus is a framework for 3 to 9 Scrum Teams working on a SINGLE Product Backlog to build an Integrated Increment.

Nexus Integration Team. Nexus adds a new accountability: The Nexus Integration Team. Their sole job is to resolve cross-team dependencies and ensure the code actually integrates cleanly.

LeSS (Large-Scale Scrum). LeSS is another scaling framework. Its core principle is 'Scrum is Scrum'. It applies the principles of Scrum to multiple teams without adding heavy bureaucracy.

Knowledge Check. In the Nexus scaling framework, if 5 Scrum teams are working on the same product, how many Product Owners and Product Backlogs should there be?

→Five Product Owners and Five Backlogs
→One Product Owner and One Product Backlog

SAFe (Scaled Agile Framework). SAFe is massive. It is highly structured and very popular in giant corporations (like Banks or Defense). It introduces 'Agile Release Trains' and 'Program Increments'.

The SAFe Debate. Many Agile purists argue that SAFe is not actually Agile, because it introduces too many managers, rigid structures, and upfront planning, reverting back to Waterfall habits.

Dependencies. The biggest problem in scaling is dependencies (Team A needs Team B to finish the API). The best way to scale is to organize teams around complete 'Features', not technical layers.

Spotify Model. You may hear of 'Squads, Tribes, Chapters, and Guilds'. This was Spotify's engineering culture. Spotify themselves say it was a matrix organization that they eventually moved away from.

Summary. The best way to scale Scrum is to avoid scaling it if possible. Keep teams independent.

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Organizing teams around technical layers instead of features

Wrong: Feature X needs the Frontend Team, then the Backend Team, then the DB Team to each finish their piece in sequence.

Right: One Feature Team with frontend, backend, and DB skills delivers Feature X end-to-end.

The Solution //

Component teams (a Frontend team, a Backend team, a Database team) force every feature to cross multiple teams, creating slow handoffs — a direct result of Conway's Law. Cross-functional Feature Teams that own a slice of the product end-to-end scale much better.

The Error //

Giving each team its own Product Backlog when scaling

Wrong: Team A has its own backlog, Team B has its own backlog, both feeding the same product.

Right: One shared Product Backlog, ordered by one Product Owner, that all teams pull from.

The Solution //

In Nexus and LeSS, multiple teams working on one product still share a SINGLE Product Backlog and Product Owner. Splitting it into separate backlogs per team reintroduces silos and makes cross-team prioritization impossible.