Published March 27, 2022
by Doug Klugh

Spread the Wealth

Avoid this anti-pattern by promoting collective code ownership to ensure knowledge is shared across the team and that everyone has the context they need to make good decisions.  Every team member has equal ownership and accountability for the entire code base.  Promote Separation of Concerns by building small, independent teams with individual code repositories and dedicated product backlogs.  Conway's Law shows that independent teams build services with independent concerns.

Creating silos greatly inhibits our ability to achieve separation of concerns — which, of course, makes our software more complex and more difficult to understand, maintain, extend, scale, test, secure, etc., etc., etc.  Too many organizations ignore this industry best practice, then wonder why they end up with rigid, monolithic solutions with slow delivery and poor structural quality.  Mel Conway figured this out over 50 years ago, yet many leaders fail to apply this best practice to this day.

Every leading authority on Agile, DevOps, and software engineering will tell you that small, co-located teams deliver faster and with higher quality than large teams.  Whether you establish a team of 5 members, 7 ± 2 members, or use Amazon’s 2-pizza rule, it is safe to say the ideal team size is < 10 team members.  Yet many organizations insist on building teams twice that size or even larger.

Even when scaling Agile for large projects, you should still scale through small, independent teams.  The best way to build large things is to build a lot of little things well.  That was always the premise behind Agile — to build small, high-quality slices of software delivered frequently — or in the terms of DevOps, delivered continuously.

Following the success of Agile throughout the global IT community, DevOps extends those principles by not only encouraging cross-functional teams, but promoting teams of software, quality, operations, and security engineers.  Optimizing team productivity requires having the expertise to design, implement, test, and deploy high-quality solutions without having to rely on outside resources.

This also facilitates the team's ability to Shift Left — to plan, design, and implement secure solutions — where defects and security risks are discovered with enough time to fix them prior to release.

Team silos have long been recognized as an anti-pattern that inhibits both speed to market and product quality.  There are good reasons why DevOps removes the development, operations, and Infosec silos.  Transforming silos into small, independent teams enables those cross-discipline team members to work side-by-side while collaborating on common goals — instead of working against each other, which is common for those types of specialized teams.  There are countless lessons learned from Lean, Agile, and DevOps teams delivering software products across numerous industries and a multitude of companies.  All we have to do now is apply those lessons learned.

Your approach to software development should always depend on your objective.  If your goal is to churn out crappy software fast, then by all means, build silos — they will serve you well.  I dare say that most (non-tech) companies focus almost entirely on the behavioral quality of software and all but ignore the structural qualities.  Sadly, most software “professionals” give little attention to enhancing those "abilities" of software:  maintainability, extensibility, portability, testability, etc.  The result is short-term speed while sacrificing long-term delivery.  Technical Debt catches up with every team.  The trick is recognizing the smells and anti-patterns that spotlight the lack of engineering practices.  And team silos is but one of many.

Separation of Concerns (SoC) is a design principle that promotes modularity by separating all but those parts of a system that are closely related and require direct interaction.  All other parts of the system should be designed and built independently, while having little to no knowledge of other parts of the system or the system as a whole.  This can be achieved by encapsulating cohesive information and/or logic into isolated layers, made of reusable and independently deployable components, containing cohesively bound classes which serve single actors, that are composed of small, single-purpose functions.  SoC is very effective in building flexible, highly adaptive software systems and can be further achieved through a variety of engineering principles.