Why working in squads is so good for developers

Two squads with developers all rowing in the same direction (the people giving directions at the front of the boats are probably the product managers, but we’re not sure) — By Currier & Ives, 1869, public domain

Good team structure can be the key difference between happy and miserable developers. We rarely work alone, which means engaging, efficient interactions are essential.

Developers’ jobs can usually be split in two categories:

1. Working on small short-term projects - as a contractor, freelancer or an employee in an agency.
2. Building an entire product for the long term - as an employee in a startup, or in the product team of a bigger corporation.

(Disclaimer: there are some contractors and freelancers that like to engage with companies to work on long-term projects for an extended period of time. Those would fall in the second category in the context of this article.)

No situation is better than the other. At the end of the day, people doing these jobs are still developers, and choosing one over the other is mostly a matter of opportunities and preferences.

But the two are radically different, and at the extremes, they could almost be considered two different jobs.

I’ve worked in both situations, and have developed over time a clear preference for building a product for the long term, as part of a product team.

Nowadays, being a developer in this type of environment often involves working in squads - a team organisation I really enjoy.

What are squads?

Squads are just teams of people really, but with some peculiarities that make them a bit special (otherwise, we would just call them teams, right?). They’re most often found in companies that embrace agile-like software development methodologies.

The concept of squads is popularly thought of as coming out of Spotify’s engineering culture, but the description I offer here may differ a bit from that. It’s based on my own understanding and experience, which is probably a bit more hands-on than the original definition.

First, squads are cross-functional teams, meaning they’re not composed solely of the same profiles but rather unite people with different jobs, responsibilities and backgrounds. In general, you have a mix of product managers, designers and developers.

For example, at Spendesk our recipe for a good squad is:

• 1 product manager
• 1 product designer
• 4 to 6 developers

Squads have a dedicated scope they own and are responsible for. To execute the company’s product vision, they define and prioritise projects that need to be delivered, with the help of the overall product team.

Day to day, they work as independent teams with their own planning and objectives. They drive their own project discoveries, design, architecture, development and QA by themselves.

While this organisation is optimized for autonomy, squads often need to collaborate. When the time comes to integrate projects, for example, they can also seek help from other functional teams when in need of specific expertise they don’t hold.

What makes squads so great for developers?

Working in squads brings many benefits and advantages from an organisational standpoint. Most importantly, they foster autonomy and knowledge sharing, which reduces silos and brings a sense of ownership to everyone involved.

Organisational benefits usually make management and leadership happy, but squads also contribute to making individuals happy, and especially developers.

Among the main benefits for developers are:

• Ownership: by being involved early in the decision process, developers tend to be more proud of what they produce because they own it. They own it because they build it from the ground up, they‘re involved in the initial product discovery, and they shape the entire design and architecture of it.
• Freedom of choice: developers have the responsibility of providing a technical solution to a product need. Squads being oriented towards bringing product value, they don’t focus on implementation details. Which means developers in a squad are free to choose whichever architecture, design or technology they see fit for the job, as long as it fulfils the product needs. At Spendesk, they can even decide how to organise their JIRA board, which I think would give chills to any so-called Scrum Master (that’s probably why we didn’t hire any).
• Domain expertise: to build the models and design that would best fit a product feature, developers need to understand the domain in which they operate. Because squads are focused on a specific scope of the product and involve everyone end to end in the feature lifecycle, their members develop a strong understanding of the domains covered by that scope. For developers it means becoming more knowledgeable, not only about technical aspects but also business-specific ones. Which is a great way to stay curious and expand your skillset.
• Richer interactions: by being cross-functional and small, squads allow for more frequent and deeper interactions with people in different jobs. Keeping designers in a room and developers in another rarely ends well. And strong boundaries between functions makes people unaware of the challenges other faces and doesn’t foster empathy. In squads, people work closely together so they better understand each other and develop stronger relationships. A happy team is a team that produces good work, which is why at Spendesk we keep a very close look at employees’ happiness.

Spendesk’s Anaïs Pieropan explained how working with designers has made her a stronger developer.

Another interesting aspect of squads is that they’re rarely set in stone. Depending on how the company and its product vision evolve, new squads will be created or removed regularly, which gives opportunities for developers and other squad members to switch to a completely different area of the product if they want to.

This creates a good balance between working on something over a long period of time, and getting bored of working on the same thing for too long.

Are you ready to join a squad?

We didn’t touch on all types of organisations developers could evolve in, but as we’ve seen in the introduction of this article, there are two categories — and only one of them involves working in squads.

Squads are just one way to structure teams. They’re not a silver bullet and they’re definitely not the best fit for every developer, every company and every project.

But overall, I believe it’s an organisation that empowers developers that are curious about product aspects to strive. This is what caught me.

If this sounds interesting to you, make sure to check out our current openings!