Dismantling Engineering Silos

Do your engineers feel isolated from each other? Are your standups boring, with rote recitations of status, without much cross-dev engagement? Is your team a collection of silos?

This is a state I’ve found in many teams across the companies I’ve worked with. In a sense, siloing your engineers feels quite natural as it provides clear ownership boundaries, an easy way to track performance, and an intuitive way to develop and leverage expertise.

Specifically, if Jane is an expert in all things OAuth, it makes sense for her to own the story around integrating OAuth into your authentication stack. If Bob has delivered three stories involving WidgetX, why would you ask him to take on WidgetY?

For a manager, siloing is an instinctual, common-sense reaction. It feels right. Sure, all companies talk about collaboration, and this hypothetical manager, Ruthi, does collaboration just fine. After all, her team has Happy-Hours every Friday afternoon. Granted few people ever dial in, but, hey, the invite is there for them. You can lead a horse to water, and all that.

And yet, there are problems. Ruthi’s directs report feeling isolated and disengaged. When Bob, her WidgetX expert, was out of office for two months with severe COVID, work on WidgetX stalled as nobody else knew quite how to approach it. Thank God, thinks Ruthi, that Bob recovered, not just because she likes Bob and wishes him well, but also because without Bob, she’d have to invest monumental effort in ramping someone else on the team on WidgetX.

Jane, meanwhile, has let Ruthi know in several 1:1s that she’s started to have nightmares about OAuth, and breaks out in uncontrollable itching at the thought of having to deal with refresh tokens again. But she’s the area expert, right? How could Ruthi let her work on anything else?

You can see where this is going. Jane’s going to depart the team first, leaving Ruthi and her team floundering. Bob will follow, because who wants their life to revolve around WidgetX when SpaceX comes calling with an offer Bob can’t refuse?

So, what’s the alternative?

My Process Cocktail

I’d like to introduce a mix of three techniques that together resolve this problem. In this article, I’ll only cover them briefly; later on we might dive in deeper – please leave comments/questions on which ones you’d like to explore more.

Stack-Ranking

I’ve written about the power of stack ranking before. For the purposes of this article, this is a technique that involves putting every work item your team has into a single prioritized stack, and then working strictly down that stack. The stack may change at any time, but once you’ve picked up a story from the stack, you should finish that story before moving on to the next one.

Thin-Slicing

Every story thus picked up gets sliced into small subtasks, “small” being less than 8 developer hours. In other words, each task should take maximum one day to complete, not accounting for regular overhead like code reviews, CI/CD pipeline, meetings, etc. If you take those into account, each task should take no more than three days to complete. That completion duration is known in Kanban circles as cycle time. So, you’re looking to achieve a cycle time of 3 days.

In reality, you’re unlikely to hit that. My team’s cycle time ranges from 3.5 to 6 days, though, naturally, we try to stay on the low end of that. 3 days is just the north star. Exceeding that should prompt conversations about learnings, possible process changes, etc.

There’s been a lot already written about the how of thin-slicing – just look up the term – but I think the why of it deserves particular attention. There are a ton of benefits to the technique, such as frontloading your unknown unknowns, achieving predictability in your deliverables, tightening your MVP requirements, and so on. But for the purposes of this article, the benefit I’d like to focus on is parallelization. Splitting a story up into these tiny chunks invites a discussion about how to best parallelize the work, since the chunks are very rarely going to be purely sequential, i.e., all dependent on each other. There are invariably going to be work streams within the bigger story, and those work streams can be parallelized.

An outcome of a successful thin-slicing exercise should produce the maximum number of developers who can work on the story at the same time. I call it the story’s saturation point.

So, in combination with the previous stack-ranking technique, your goal is to completely saturate the highest-ranking story before moving on to the next one.

Naturally, a story’s saturation factor isn’t going to remain constant throughout the story’s development timeline. For example, the story might start out needing only one dev to lay some foundation before other devs can jump in to build on it. (Though I should note that in correct thin-slicing, called vertical thin-slicing, such a situation is an anti-pattern. Don’t build foundations. Build thin, vertical scenarios.)

Or a story might saturate with four devs up until the final stage where it only needs two for bug-fixing. The larger point is that the saturation factor might differ.

With that in mind, let’s talk about the third technique.

Swarming

Given what we’ve just talked about, this one should be obvious. Swarming is simply saturating a story to its maximum capacity. Because a story’s saturation factor changes over time, this means developers will frequently migrate between different stories, and that’s a good thing! In my team of eight, we typically have a couple stories under active development. There might be a story on the board that’s blocked by a dependency that has nobody actively working on it, but ready to jump back once the block is resolved. This basically means that everyone on the team collaborates with each other, which means people intrinsically know the details of every moving story. If one person is out for whatever reason, the work can continue – it just means the least important story in the stack gets desaturated.

But if everyone’s doing everything, how do they get evaluated?

A common concern I hear about this technique is that shared ownership means effectively no ownership, making it exceedingly difficult for the manager to evaluate everyone’s contributions.

I have a two-part answer for this one. Let me get the more contentious point across first:

What’s your goal in evaluating your directs?

Sounds like a dumb question, right? It’s to make sure everyone gets fairly compensated for their contributions. Right? Right?

Wrong. Sure, compensation is a part of what performance reviews are for, but the major goal of a well-functioning performance review is to identify strengths and weaknesses (see the other article I wrote on this topic) and come up with a plan for growing former and plugging the latter.

So, if that’s the mindset you adopt, you should be embracing swarming. Why? Because working with others will help your directs uplevel. Working with others will provide you with some of the more reliable data points about everyone’s performance: peer feedback. And, of course, remember that swarming still means everyone has a thin-sliced task of their own. They can pair-program, sure, but they don’t have to.

Story Ownership

But all that said, mid-level and senior engineers still need big-ticket tasks to own. It’s tough to come to a promotion review meeting and say “my SDE2 implemented a bunch of 8-hour tasks.”

The way we’ve solved this on my team is through story ownership. Each developer gets an entire story assigned to them. They handle the initial analysis of the story, and for thin-slicing it into smaller chunks. They run the design and thin-slicing reviews for the story and create the necessary artifacts in the team’s issue tracking system (JIRA?). They oversee the execution of the story, working with the swarm (and, of course, implementing specific tasks too) to make sure everyone’s unblocked. Finally, they act as the single point of contact for the story, dealing with dependencies, stakeholders, management, etc. In other words, this is a leadership role.

Ultimately, they get the bulk of the credit for the story’s success.

In any given year, I aim to have each member of the team own at least two stories appropriate to their level. (e.g. junior engineers will own stories too, just smaller ones. Seniors will own much larger, much more ambiguous stories, that sometimes will require a month’s worth of analysis.)

The IC’s evaluation, then, primarily focuses on how well the stories they owned ran. Specifically:

1. Were they designed appropriately? (whole articles have and have been written on this, so I won’t go into what ‘appropriate’ means here.)
2. Were they thin-sliced correctly? When a story is thin-sliced well, it will tend to have few if any unexpected roadblocks during the execution phase and will land within 10% of its target date. (Where the target date is computed as number of thin-sliced tasks times the three days per task, divided by saturation factor.)
3. Did the story owner make sure nobody in the swarm was blocked, and that everyone had a task? (I.e., that the path through the story was always clear?)
4. Were the stakeholders kept in the loop about story’s progress?
5. Were any dependencies accounted for, with timely communication and status updates?

Yes, I realize that what story ownership asks of the IC is to function as a developer, a PM, and a manager in one. To me, that’s a good thing, and I’ve seen it be motivating to ICs too. Acting this way, they're not owning a collection of tasks, but a business problem, and collaborating with their teammates to solve it.

Bottom Line

Silos are bad. They’re bad for morale, they’re bad for knowledge sharing, they’re bad for team cohesion. Even if breaking them down incurs a temporary slowdown, it is a worthwhile investment for the medium and long term well-being of the team.

In this post I’ve outlined some techniques you can use to approach breaking down these silos. I’m sure there are others. Please leave a comment with your suggestions and thoughts, and please follow us for more in-depth material on how to form a smoothly-functioning team.

Have an article idea you’d like to run as a part of Empathic Insights Collective? Reach out to us – we welcome guest writers. Have a question or a specific topic you’d like us to explore? Reach out!