First-class blockers are one of Constructor's superpowers, letting anyone record, assign, and discuss what's stopping progress, so there's never a question like "is this blocked?", "what's it blocked on?", "who's responsible for addressing it?", or "what's the latest update?".
If you're coming to Constructor from another tool, you may be accustomed to thinking of "blocking" as a kind of relationship between tickets. To quote a certain Jedi Master, "You must unlearn what you have learned." Read on to see how Constructor's approach is both lighter weight and more flexible and practical.

Key concepts

In Constructor, a blocker is a special type of discussion thread.
Like a regular discussion thread, you can assign a blocker to a teammate to make them clearly accountable for following up. It'll be shown prominently in their "My work" view. And you can resolve the blocker when it's no longer an issue.
Unlike regular discussion threads, blockers support a variety of use cases by having additional capabilities:
  • A blocker has a brief description explaining what's stopping the ticket from moving forward. Think of it like an email subject line. It's a bit of text that succinctly frames the topic of conversation.
  • When a ticket has a blocker, its brief description is shown prominently on the board on the ticket's card. That makes it abundantly clear to everyone on the team not only that a ticket is blocked but also why.

Use cases

Blockers are designed to be lightweight and flexible and can model all sorts of day-to-day activities on your team. Below are a few examples.
These are just a few examples of how your team could use blockers. It's OK to experiment, find the practices that align with how your team likes to work, and evolve your practices over time.

Progress is stuck on a critical issue

Imagine a developer is working on a ticket and discovers a major gap in the technical design. They can't continue development until the gap is addressed. They open a blocker on the ticket with a brief description like "Need to fix gap in technical design", add a comment with additional details, and assign it to a senior engineer. Once the design is fixed, they can resolve the blocker.

Responses from a third party

Imagine a team member is working on a ticket to fix a bug that's affecting a particular customer. They can't reproduce the bug, so they reach out to the customer for more information. In the meantime, the developer adds a blocker to the ticket with a brief description like "Waiting on customer to provide more reproduction details". Now it's clear to their manager (and the entire team) why the bugfix isn't moving forward.

External constraints

Imagine a developer is working on a technical investment to switch from one third-party dependency to a new one that's a better fit. However, they discover the new dependency is currently missing a critical capability, but the dependency authors have plans to add it in the future. The developer adds a blocker to the ticket with a brief description like "Waiting on dependency ABC to support XYZ". Now the team won't forget why this technical investment stalled. If they revisit the ticket in the future, they'll be able to quickly assess whether it can now move forward.


Creating and replying to a blocker

To add a blocker to a ticket, visit the ticket's page and click New blocker toward the upper right corner, then provide a brief description and submit. You can optionally assign the blocker to a team member by picking their name from the dropdown.
We recommend keeping the blocker description brief, around ten words or so, so that teammates can quickly understand the basic issue. If you want to provide more detail, remember, the blocker is also a discussion thread. Try adding that additional detail in a comment.

Other actions

Blockers are a special type of discussion thread, so viewing, assigning, and resolving blockers are exactly the same as any discussion thread.
Learn more about discussion threads: