Managing Squads Effectively

Problem

At the beginning of 2020, our team was very small. We were all focused on the same work, drawing from the same Jira backlog, and running the same sprints as a whole. While we were able to function, we noticed that some team members were getting lost in what other people were doing.

My team had the potential to be distracted as more individuals joined the team — my back-end engineers didn’t necessarily need to know what my front-end engineers were doing at all times, and we found that separating them into separate squads focused the conversation around specific topics and KPIs.

After restructuring, we enjoyed an agile workflow where we were more focused, productive, and collaborative across departmental lines that were now much more clearly defined. One downside, however, was that some individuals were losing touch with coworkers who they no longer interacted with daily.

Actions taken

Giving each squad its own assigned focus and the dedicated space that it needed became my priority. Each squad had its own individual stand-up daily. Their sprints were all planned individually, with managers aligning their goals with the objectives of the company as a whole. Each squad had a clearly-defined purpose, so nobody had any questions about what they should be doing at any given time. The separate Slack channels that each team used and Google groups that controlled team calendar events. We integrated this model into our onboarding process, as well, laying a clear track for every new team member to follow. Scaling naturally and collaborating effectively became a part of our infrastructure from the beginning.

To encourage coworkers separated by these lines to remain in touch with one another, I instated channels that allowed individuals to access each other across the official squad boundaries used during our working hours. These look like Slack channels and GitHub teams for front-end/back-end specialties. We’ve also planned social events, happy hours, hackathons, and, most importantly, a dedicated stand-up every Monday that included the entire digital team at once. This “round table” was key, as it got everybody on the same page for all of our projects and goals on that given week. Team members were able to touch base outside of their immediate squads, ready to re-group and continue as before. Each group retained its “personality” while maintaining its connection with the ones adjacent. This made for a more cohesive, consistent experience for our clients.

Establishing KPIs for each group was another way that we tried to show our team members how they were making an impact on the company overall. Each squad had its own set of KPIs, supplemented by company-wide KPIs that illustrated the objectives that we all shared. Individuals were encouraged to develop their own KPIs, with the support of their manager, to ladder up to their squad/department KPIs.

Lessons learned

• Communication between my team members became much deeper as the topics at hand narrowed and became more focused. The connections that they shared were enhanced by the camaraderie that everybody felt within each squad.
• Product managers, each overseeing a now much more manageable team, were able to refine their scopes of interest. This newfound sense of clarity allowed them to draw upon one another’s experiences utilizing this model, improving the ways that they managed the squads that they were responsible for.
• Our reports became much more connected to what they were doing for the company as a whole. Sometimes, as an engineer, you write the code and ship it off with little feedback on how it impacts the customer or the business. Connecting them to the results that their work has contributed to can often be a source of positive morale. Now, I try to make the vision for the team very clear. Continual check-ins reduce diversion and drive everybody forward.