Working in Squads is Inefficient

I used to work for a startup.

Initially, when building the company, they built a bunch of services for the different parts of the company. In total, they were around sixteen services to support the different concerns in the company.

Each of the products had its own team, responsible for the code belonging to the product.

The company grew from startup to scale-up. In the process, the products grew and grew.

The company hired and hired, till teams grew to >10 engineers. It became inefficient. So, within the team, we defined “squads”. They were smaller teams that were responsible for a part of the bigger system.

Naturally, it didn’t work.

All squads were maintaining a single system, but the codebase, runnables, and database were still shared. Given all these shared components, information still had to flow everywhere. The transition to squads had just turned us into a poorly communicating team rather than a more efficient vehicle.

When those pain points started showing, many fires emerged. More bugs made their way to production. Many meetings were held to discuss architecture, but none of the proposed changes significantly improved the process.

In the end, the company took the long route by breaking down the system. Massive architectural changes were made, and refactoring efforts to break down the old system still persist to this day.

So, whenever I hear about “squads”, I consider it an anti-pattern.

You should not break down a team without breaking down the domain.

The more teams depend on each other, the more inefficient the company gets. The more hierarchical a company gets, the greater the communication overhead.

Defining proper boundaries to systems can fix this issue

It may be a painful sacrifice at first, but will pay off big-time later on.

If you notice that more and more of your workday is spent on things besides the actual work, bring it up and make things happen!