5 things we're keeping in mind working in squads

How many times have you iterated on your work organization? At Slite, here's our brief history:

• From 0-6 people we worked in 1-week sprints
• From 6-10 we worked in 2-week sprints
• From 10-14 we started working in 2-week squads made up of engineers and product designers
• From 14-🤷 we're now working in 5-week squad cycles, inspired by Basecamp's model

What first triggered us to work in squads? Our second product designer, Rob, and two developers, Charley and Guillaume, joined us. If you're also a growing team, you know the dilemma: more manpower, more dysfunctions. To list a few: flawed decision-making processes, a top-down approach to building the product, not enough or irrelevant feedback.

So, we decided to work in 3-4 people squads of 5 weeks to:

• Give everyone more responsibility: each squad makes and drives product decisions
• Improve our decision-making process: squads make calls and follow through with them
• And plenty of other reasons we'll happily share in a later article :)

That was 5 weeks ago so we're currently nearing the end of our first squad cycle. It got us thinking about the five foundations of teamwork: how have we applied them in this cycle? Where can we improve? Here are some thoughts 🤓

#1: Trust

Shopify CEO, Tobias Lütke, introduced the idea of "the trust battery", also mentioned in Basecamp's book, Calm. It's the idea that at any point in a team, people's trust batteries are more or less charged. In our case, at the beginning of each cycle, each squad member's trust battery is half-charged. Unintuitive techniques charge it: be vulnerable and speak the truth when things aren't working as expected; ask for clarifications for vague specs or unknown states of development; do regular check-ups within squads synchronously or asynchronously.

One of the squads' goals was to release the mobile app but the timeline was tight. Thanks to honest communication and trust, all the squad members dropped what they were doing to help release the mobile app on time. At the end of a squad cycle, trust batteries should be charged 100%.

#2: Feedback

Feedback should be delivered directly, punctually and honestly. It should also be given by a limited group of people. It's counter-intuitive but the more people give feedback, the less productive it becomes. Squads reduce the feedback loop, encouraging rapid prototyping and quick product iterations. In this way, feedback can be given along the way and mistakes can be diluted and less hard to admit.

Squad members aren't just accountable for delivering features and feedback shouldn't be limited to the product. Team members can help each other grow through 1:1s and honest communication (which relates back to Trust 👆).

When received, feedback is a powerful tool for improving ourselves and our work.

#3: Commitment

1/ Each person is dedicated to a squad, and committed to it by default. The squad's flow is dependent on this commitment. For example, I was part of the squad working on our editor but I'm also in the middle of hiring for two positions. The flow broke because I was half in, half out. We should stay within our squads, remain focused on our squad goals, and help members if they're stuck - right until the end of cycle.

2/ As Jeff Bezos said: "Learn to disagree and commit". When things aren't moving forward because of a disagreement, trust the person in charge (for example: the product designer). Express disagreement constructively, and then move on by committing to the squad's decision.

#4: High standards

Having high standards is different to asking for perfection. A good way to achieve high standards is by making things that are simple, well designed and well thought out. Remove the clunky parts. Get rid of options. Focus on doing excellent work.

The size of squads make this possible. Everyone is responsible for the quality of a feature. All members are encouraged to speak out: developers can review designs, designers can challenge marketing decisions, product can question tech decisions. It becomes easier for everyone to set new standards.

#4: Results

Attention to results is the most important part of squads. If goals can be reached early in the cycle, why not release that small improvement sooner rather than later? Is there a shortcut we can take now, and pay back later because a Cycle lasts for a whole 5 weeks?

Reporting these results encourages everyone to stay in line: squads send status updates to the entire team 3 times a week. For the next cycle, we're going to put in place mid-term cycle reviews to realign and refine goals.

Let's focus on squad foundation for better team foundations

These 5 foundations are widely known and almost obvious. It's one thing to implement them in a small, five-person team. It's a whole other story when your team grows. They become a little bit more complex to work on as each new employee joins the team, it can be disorienting.  

In the last 5 weeks, we've found it more productive to work on these principles at the squad-level. The good news is that we've seen it affect the team as a whole.

Thanks for reading! Are you working in squads? What are your squad foundations? We're curious!