Introducing Blocker Threads

"Is this blocked? What's it blocked on? What's the latest update on the thing that it's blocked on?" — it's frustrating to have to dig for answers or remember them on the fly at standups.

Phil Sarin, former CTO of Managed by Q

If you’re a manager and want to deliver projects rapidly, a big part of your job is to discover and clear blockers. Otherwise, blocked developers will either move on to other work — work that’s presumably less important — or worse, just twiddle their thumbs.

Dev work gets blocked for all sorts of reasons: an incomplete design, a need for clarification from the PM, an open question to a customer, a cross-team dependency, you name it. When I was a frontline dev manager I encouraged my team to escalate these sorts of issues promptly, and I’d also try to suss them out during standup. Our issue tracker was no help. If it supported blockers at all, it was only in the form of a generic and easy-to-miss comment that an IC could never be quite sure I’d see. Or it was as a reference to another ticket, which is fine for tracking dependencies but either inadequate or too heavyweight for the general case.

Over the past year we’ve seen many of our customers jury-rigging ways to capture blockers in Flat. Some have a column called “Blocked”; others attach a “blocked” label to the ticket, and others prepend a ticket’s title with “[BLOCKED]” to call attention to it. But these workarounds neither capture the reason the ticket is blocked nor provide a dedicated place to discuss it. So, we decided to build a first-class solution.

Our new feature is designed around the idea of a blocker as a short, one-line summary of the reason a ticket can’t move forward. Since we know that blockers usually entail conversations, it was natural for a blocker to be the start of a dedicated conversation thread on the ticket. Thus, once a blocker has been created, anyone can click on it to reply, and just like a normal thread, a blocker thread can be assigned to anyone and resolved when the issue has been addressed. And of course, a ticket being blocked is a big deal, so blockers are clearly indicated on the board.

Threaded comments are already one of Flat's most popular features, and now they underlie a model of blockers that’s natural, flexible, and consistent with our product value of modeling the world in a lightweight, pragmatic way. Teams will vary in what constitutes a “blocker” and in their norms for escalating and addressing blockers. We’ve aimed to give them a simple primitive that’s accommodating to many different uses.

Let’s walk through how it works in the product.

Walkthrough

On a ticket details page in the discussion pane on the right hand side you’ll find a new button called “New blocker”:

Clicking this button allows you to provide a brief description of the blocker, similar to an email subject:

You can also assign the blocker if there’s someone who should be responsible for addressing it. Once you click “Add blocker”, the new blocker will appear in the discussion pane like a comment thread:

And on the board, the blocker now appears on the card, so everyone can see its blocked status:

Team cultures differ on whose job it is to resolve blockers, but our user testing indicates this level of visual prominence strikes the right balance and is noticeable without being tiresome. It’s easy to see that the ticket is unhappy, but it’s not shouting at you.

Phil Sarin, former CTO of Managed by Q and now at Datadog, had this to say about our approach:

" I like that they are free-form, because it should be easy to surface blockers and to phrase/structure them in a way that makes sense. I like that a comment thread captures the history of the blocker and that it's a distinct comment thread from other stuff in the ticket. All eyes should be on the thing that's impeding progress.

I like that blockers show up as red-X-error-like-things on the board, as that's how they should appear. Jira's buried "A is blocked on B" makes that seem normal/okay, as does the "blocked" column that I vehemently fight against on pretty much every team I work on. The way Flat presents them make blockers appear as Not OK, which is how I'd want my teams to think about it."

We know our customers are looking forward to this feature and this is something I’ve personally been wanting for almost a decade, so I’m delighted to announce it.