Most people turning to squads are doing so because their current systems of cross-team collaboration aren’t doing what they need them to do. Multidisciplinary squads address many of the common issues that come about when people from different teams need to work together. This includes everything from a lack of organization to passive participation of specific teams. But squads aren’t inherently free from challenges.
Here’s how to address a few common less-than-ideal situations you may encounter in your squad — split between communication and procedural issues.
The entire purpose of a squad is to unite colleagues with different skill sets and strengths. While this kind of diversity allows you to approach challenges from many different angles, it can also create a few challenges in and of itself. One of these is the potential for communication issues.
Different communication styles
Are your developers very blunt, while your marketers tend to dance around negative feedback? Do your salespeople dominate the conversation while your IT team is more introverted? Do some colleagues prefer a structured chat while other participants would rather a freeflow brainstorm? All of these different approaches to communication have the potential to create conflict.
To combat this, your squad lead will need to set very clear guidelines on how meetings run and how feedback should be communicated. If these guidelines favor certain styles over others, you’ll need to be extra careful. Make sure to engage and involve the team members who might not naturally embrace that approach to communication. And you can always ask for feedback after meetings to identify those who feel left out or are having difficulty participating. While you need to set clear guidelines, these guidelines can be iterated on to find a happy medium for everyone involved.
Another common communication challenge in squads is overly technical discussions. If you have three developers in your squad and they start talking about webhooks and API keys, how are the marketers going to feel? They might disengage, or be forced to ask countless questions in order to keep up. This isn’t just a development issue either. Your developers probably don’t know or understand why you’re using UTMs to track leads generated through your CPC ads.
Make a point of limiting technical talks in squad meetings. If individual updates veer into the overly-technical, your squad lead should ask if the conversation can be taken offline. You may also consider setting aside five minutes at the end of meetings for technical talk with optional attendance for members.
Squads are meant to be engaging and efficient, helping you crush deliverables as a team. If people feel like their time is better spent elsewhere — either by skipping squad meetings or spending the entire time on their cell phone — you’ve gone off the rails somewhere.
Make your meetings laptop or cellphone free for everyone except those presenting. If participants can’t go 30 minutes without checking in, consider whether they’re right for the squad. You might decide that they are, but at this stage of the project there’s not much value in the meetings. Or if you decide they’re not, have a conversation with them about bringing someone else into the squad.
No matter what you decide, there’s no denying that distracted people distract everyone. Make sure that whoever is at your squad meetings is actually taking part in the process. And if there are no important updates for the group, feel free to cancel your weekly squad meeting. Don’t have it just to have it.
Squads are a new approach to tackling cross-departmental projects efficiently. If you’re not careful, though, squads may quickly adopt the same bad habits that plague traditional meetings and collaborative work — the types of issues that made you seek out squads in the first place.
Meetings running overtime
We’ve mentioned it a few times already, but squads are supposed to be MORE efficient. Core to this approach are quick, weekly meetings that replace a lot of the time-wasting chatter and emails that plague project teams. If your quick 30 meetings suddenly stretch into 45 minutes or an hour each week, are you really saving any time?
Squad leaders really need to be strict in enforcing the time limits within these meetings. This means updating people on time remaining during the meeting, cutting off people who are rambling, and ending the meeting on time. If important conversations still need to happen, encourage squad members to book additional time. They can then update everyone on the outcome in Slack. Doing so frees up those who aren’t actively participating while removing the awkward guilt of leaving mid-discussion. The truth is, there are very few discussions that can’t be solved by a simple Slack message. Physical presence is precious.
This is less about time spent in meetings, and more about the ongoing existence of the squad. In our post on how to manage squads we noted that once the squad has completed its target deliverable, you should disband it. For some reason, when a project involves several different teams, things tend to spiral outside of the original scope. Things are unearthed in work that make you want to pivot to new projects or do several iterations of a single project. One deliverable will become several deliverables. Weeks become months.
A squad should not stray from its specific deliverable. That deliverable is what drove the creation of the squad and the entire point of a squad is to maintain focus. If, during the course of your work, you realize that there’s more complementary work to be done, consider whether that work needs a squad or can be done independently. If it needs a squad, then when your current deliverable is complete, host a post-mortem and disband the squad; then start a new squad for the new deliverable. It might seem complicated, but there’s a reason disbanding is so important…
Repetitive squad make-up
It’s normal that if one group of people worked on a specific project, you’d want them to work on any associated projects or offshoots. Every squad related to your mobile app will have the same group of people. Every squad about your website will have the same group of people. Etc.
Unless the project requires very specific personal expertise, consider changing up the squad after each deliverable. Why? Because it’s only in switching up squads that you ensure the cross-pollination of ideas. Even if you felt a squad ran smoothly, other team members could bring a positive influence or new perspective to the work. Plus, switching out members of a squad ensures that they don’t get set in a certain dynamic, where specific vocal people have more influence or run the conversation.
Another common issue faced by squads is differing tool preferences. Unito allows everyone to work in the tools they love while still collaborating and communicating. Try it free today!