One of the most challenging parts of running a web development firm is workflow management. Inevitably members of our Brick Factory team get blocked, meaning they can’t complete their work while they wait on someone else to make a decision or perform a task. Blocking is a huge problem, as it can result in delays, budget overruns and unnecessary fire drills.
In this post we explain what it means to be blocked, why it is such a big problem and provide some tips on how to keep the work flowing.
Why do people get blocked?
We are a mid-sized web development firm of around twenty people. A typical project might take 400-500 hours spread out among 5-6 staff to complete. A project team usually looks something like this:
- An outside client responsible for approvals and content creation.
- A project manager who handles requirements gathering, quality assurance, client communication and generally assuring that things run smoothly.
- A designer responsible for creating the look and feel for the project.
- A backend developer responsible for CMS setup and custom development work.
- A systems administrator responsible who sets up the hosting infrastructure and handles deployments.
Over the course of a project any one of these team members might be blocked from completing their work.
- A designer might be blocked from starting on design comps while they wait on feedback from the client on wireframes.
- The front and back end teams might be blocked from starting on a new feature while they wait for specifications from the project manager.
- A front end developer might be blocked from building a site’s theme while they wait for clarifications from the designer.
- The client might be delayed in doing critical content management work while they wait for the back end developer to finish setting up the CMS.
On large projects, when the workflow gets disrupted the problems often cascade. A designer might be waiting for clarification from the project manager to complete design work. The front end developer may be waiting on the design before working on implementing the feature. And so on.
While blocking is a problem on large builds, it can also be a huge problem on small 2-3 hours fixes to existing sites. Below is a typical workflow for fixing a bug on an existing website:
- Client reports bug to project manager
- Project manager passes bug to front end developer
- Front end developer fixes bug in development environment.
- Project manager tests and sends fix to client for review.
- Client reviews and approves.
- Front end developer (or systems administrator in some cases) deploys bug to production site.
- Project manager and client review again to confirm fix.
So even a small change might require coordination between 3-4 people.
How to stay unblocked?
There isn’t some sort of magic bullet that will solve the blocking problem. It is something we still struggle with at the Brick Factory every day. However we do have some simple steps we’ve taken that we have helped alleviate the problem.
(1) Make communicating blockers a part of your process
On the projects I work on, I typically play the role of project manager. On a typical day I work on between 10-15 tasks across multiple projects. I might juggle responding to client email, answering questions from internal team members, writing a blog post like this one and testing a feature turned over for testing by our back end team.
Sometimes it is obvious to me that I am blocking someone from doing work. But sometimes it isn’t. If you are blocked from doing work you should communicate that clearly and loudly. You should make 100% sure that the person blocking you is aware that they are holding up progress.
Another important part of this is to use the right communication channel for the level of urgency. At the Brick Factory we try not to be slaves to email, so we encourage folks to only check it periodically throughout the day. If you need an immediate answer, sending an email or making a post to a project management tool like Jira or Basecamp isn’t a good plan. Give the person a call or contact them via Instant Message/Slack so they understand it is important.
(2) Prioritize unblocking other team members
When I start work every morning I make a list of the tasks I need to work on in order of priority. I’m often disrupted, but I make that list every day and start every morning with the intention of completing my tasks in the order they are on my list.
When compiling my list, I always try to prioritize items that are blocking others from doing their work. And when tackling any task, I try to anticipate what information others on the team will need and be thorough in an effort to minimize back and forth.
At a web development firm one of the keys to being a good team member is never being a bottleneck.
(3) Empower team members to make decisions
As a front or back end developer is building a website, there are hundreds of little small decisions that need to be made. As an example, as a front end developer is implementing a design they might run into a small detail that needs to be adjusted for expedience. Instead of calling a meeting every time a situation like this comes up, we encourage the front end developer to make the call themselves.
We encourage our team members to use their own judgement instead of holding up small things for input/approval.
(4) Dedicated Teams
On large projects requiring hundreds of hours of work blocking can be particularly destructive. As a project manager, on a site build of that scope you might have 4-5 questions or tasks each day that could potentially block other team members from doing their jobs. If you are juggling work on a bunch of projects simultaneously it can be easy to get sidetracked and block others.
While it is not always possible for a firm of our size, having dedicated teams working on a project is a great way to keep work flowing. Dedicated teams maximize efficiency. Since everyone is 100% focused on a shared goal and priorities are aligned being blocked is typically not a huge problem.