Engineering silos can lead to loss of productivity, lower morale, and lack of ability to achieve your mission. Here's how to break them and build a successful engineering department.
One tool for pulse checks, team building, and coaching––in Slack. Free forever. No credit card required.
Try for FreeOr book a demo to learn more.
If you’ve worked in a heavily-siloed organization, you know what a frustrating experience it can be.
For engineering teams, silos are when your individual engineers or teams function separately from others. They have minimal interaction with the rest of the engineering organization (let alone the rest of the company).
The negative impacts of silos can be huge, including lost productivity and lower morale. But even more than that, silos hurt your ability to achieve your mission. They make almost everything harder.
Rome wasn’t built in a day, and neither are silos.
Several of the chief factors contributing to silos among engineering teams are:
Silos are built slowly over time. As factors like these take root in your engineering organization, they eventually solidify into new cultural norms.
Voilà. Just like that, you’ve got a silo problem.
But don’t despair if you feel like you’ve seen some of these factors at play among your engineering team. Even if you’ve got crystal clear silos that everyone can see, all is not lost. By taking deliberate action consistently, you can deconstruct those silos and create a more effective engineering team.
It’s impossible to break down silos overnight. But by putting these tips into practice over time, you’ll be creating a better workplace and a stronger team.
If your engineering teams are working with totally different tools, you’re making life harder for yourself.
Of course, some teams and roles will need specialized tools to do their jobs. That’s fair, and there may not be much you can do about it. But speaking broadly, centralizing your engineering team onto a common set of tools is going to make eliminating or avoiding silos a lot easier. And research shows that the average company uses 137 SaaS products (and that number is growing fast), so this is certainly not an uncommon challenge!
Think about each key function your engineering team plays in your company. What are the outcomes your teams need to deliver? Next, what types of tools are necessary to deliver those outcomes?
Once you have that list, bump it up against your existing tool stack. What items are unnecessary or redundant? Where can you reduce overlap? Where can you build out processes in some tools to eliminate the need for other tools?
Working through this process over time will help you curate a list of tools to make your teams successful while reducing the risk of siloed work.
There’s a stereotype that most developers hate writing documentation. But who knows if that’s true because developers in StackOverflow’s survey also voted poor documentation as the second biggest challenge they experience at work.
Documentation may never win a popularity contest among software engineers, but it’s always going to play a critical role in breaking down silos across your teams.
That’s because documentation’s importance stems from the fact that it’s the single best way to codify and share information across an organization. Consistent and standardized documentation creates a historical record of decisions, enables faster onboarding of new hires, and contributes to a culture of transparency (more on this below).
There are a number of tools that can make software documentation easier for your team. And while you can pick a great tool, the real wins come from making documentation a central part of your engineering team’s culture.
Some ways to do this include:
Take inspiration from the journeys of organizations like Google, Twitter, and Spotify. Documentation may not be sexy, but it’s valuable. Every piece of clear and useful documentation your teams create becomes an artifact that other teams can use to learn and stay in sync.
If your engineering teams are siloed, by definition you probably don’t have a lot of cross-functional work happening.
You can change that.
While we’d never suggest creating task forces or cross-functional teams for no reason, there are plenty of situations in a tech company where cross-functional collaboration makes sense. Consider new product development or triaging a bug in your existing product.
Could you have an engineer or group of engineers hunker down and try to complete everything in isolation? Probably.
Would it be effective? Probably not.
Scenarios like these are great opportunities to create cross-functional teams. Pull together a diverse group of people with all the necessary skills needed to get the job done. This can include members from different teams across your engineering organization, but it can extend out to teams like customer support, marketing, design, and more.
Organizing teams like this has a double benefit: it can make the process more efficient (because the team has everything they need to move fast) and it can foster mutual trust and relationships across your teams.
Here’s what Ben Richardson, Senior Software Developer at SecureW2, had to say about their experience:
"Creating cross-functional roles and implementing cross-training has played a major role in helping us break down silos within our engineering team. Both of these strategies have made it easier for us to understand one another, the roles we each play, each team’s specific contributions, and our different work and communication styles. Moreover, these strategies have enabled us to find common ground in the different projects we work on, and to identify and work together towards common goals that will benefit the company."
That’s a win-win anybody can appreciate.
Silos thrive in organizations with poor communication habits and low transparency.
If you want to combat silos for the long term, you’re going to have to cultivate a culture of transparency within your engineering team. There are a lot of ways you can start building a psychologically safe culture, including:
Don’t let something as important as communication be an optional thing for your software engineers.
The format can vary, but make it clear what each team member should be communicating to the broader team. Some examples of how this might look are things like:
Adjust these depending on how you want your teams to work together, but don’t leave it up to chance. You’ll reap major benefits. When Code Climate focused on improving communication and reducing knowledge silos, they saw a nearly 70% throughput improvement from their engineering teams.
Communicating transparently can be really uncomfortable for people. As a leader, you’ll often need to be the one who kicks things off. As you share about your own struggles, questions, and challenges, you’ll find that your team members begin to open up as well.
Stéphane Boisvert, Director of Engineering at XWP, does his best to embody this approach:
“As a leader on a team, it’s important that you show that it's okay to ask for help, that it's okay to not be super-human. Exposing your own vulnerabilities enables the team to trust you and each other with theirs, and that will always lead to stronger teams in the long run.”
Spread trust to reap trust. If you want to create trust among your team, the best way to make that happen is for you to lead the way. Show your teams you trust them enough to be vulnerable yourself.
One of the biggest impacts of working in silos is that, oftentimes, teams may not learn about something until it’s too late.
You can actively combat this by creating a culture where it’s safe and normal to give feedback. The tactics above—about communication and cultivating trust—will help (and you can find more tips here).
When you’re trying to foster feedback across different teams, the key thing to remember is that feedback is like a compass. It’s a gift that allows you to recalibrate and course-correct when needed.
That doesn’t mean all feedback is valid. And it certainly doesn’t mean it’s appropriate to give feedback in ways that are harsh or unhelpful. But when feedback becomes normalized and valued in a transparent and psychologically safe environment, it can be a wonderful catalyst for change.
Silos don’t serve anyone well. You don’t want them among your engineering teams (or anywhere else in your organization). So take action on these tips today to start breaking down silos anywhere you encounter them.