4 ways to know your engineering team is full of silos

2 minute read

We all know silos in agile engineering teams are something to avoid but can you walk into a brand new team and recognise them immediately? Here’s the attributes of siloed teams that I’ve seen in the wild…

Daily stand-ups are almost useless

There’s the API guy, the CLI guy, the JavaScript guy, the server admin guy and so on. They rarely work in each other’s domains so they have zero interest in what each other is working on and even less ability to help each other out.

One primary function of stand-ups is to help other engineers in order to keep development moving along. You can’t do that effectively if the other engineers are all working on a part of the application you know nothing about.

People drag work items in and out of sprints

If you’re working away in your own silo then there’s practically no negative consequences of dragging work in or out of the sprint. Sprints are just mental concepts that managers care about. You’re interested in coding the feature you’re working on. If all you know is your own part of the application then why would you check to see if there is anything that another person is working on that you can help close? Just drag in the next task on your feature and get to it!

Stuff is coded in loads of different languages

Of course there are valid reasons for using different languages for different parts of the app but when you’re using 5 different languages in a 12 people team it’s a sign you have silos. After all… if you’re the only person who’s ever going to work on the codebase, why bother coding it in a language that people around you can understand? Just use whatever you’re language du jour is, you might as well enjoy it.

You gotta wait for Paul to get back when his feature breaks

It doesn’t even have to break. Imagine sales come to you and they’re like “Huge customer X won’t buy the product unless we add small-thing-Y” (be super wary of this but that’s a problem for a different day) but you know that Paul is the guy that build the part of the product that Y is in and Paul is gone on parental leave. Sure you could spin someone else up on that part of the codebase but by the time they understood it Paul would probably be back.

Categories:

Updated: