In improvisation theatre (yes, I was a theatre nerd in high school) there is a concept called blocking. Essentially, whenever you have an interaction with someone on the stage in improv, your interaction should allow the next person to pick up the thread and run with it to continue the scene. In other words, you need to provide a hook for the next person to continue the story.

If you don’t provide a thread for the next actor to continue the scene, it’s called ‘blocking’, as you’ve essentially blocked the scene from proceeding.

A quick example:

Actor A: “Do you want to go for a walk with me?”
Actor B: “No, I don’t feel well.”

B has blocked A’s offer to go for a walk, without providing an alternative option for the storyline, leaving A with the responsibility for creating a new storyline for the scene.

In development teams I see people blocking each other all the time.

Another example:

Developer A: “Can we add an extra parameter to this function?”
Developer B: “No, it doesn’t work like that.”

Developer B has blocked Developer A from solving the problem, without giving A another thread to follow. In other words, B has shunted the topic back to A, leaving A with the responsibility to try to find another way to attack the problem, but with no extra cues from B on what might work better next time.

Saying ‘no’ is not the problem here. But when you say ‘no’, you should always try to give a thread to allow the scene to continue.

Let’s try the example again:

Developer A: “Can we add an extra parameter to this function?”
Developer B: “No, it doesn’t work like that, but if you look at the sample requests you might get an idea of what’s working already.”

Now Developer A has a thread; she has an idea where to go to continue the search for the solution.

Not blocking someone can be as simple as giving a cue to let the scene continue. So when interacting with people in your team, or with other teams, remember: everybody wants the scene to continue, so avoid blocking.

The show must go on!