The Rule Followers

How a management training exercise taught me a thing or two about building products.

A few years ago, ten people and I attended a management training session at work. The instructor gave us an exercise known as “Traffic Jam”.

We were broken into two groups: 8 employees and 3 managers. I was a manager.

There was a grid of nine boxes drawn with blue painter’s tape on the floor. Eight “employees” were split into two equal groups of four, and they had to stand in the boxes. One group stood in the first four boxes, and the other stood in the last four. There was an empty box in the middle.

The three managers broke out into a separate room together, and were given a goal: switch the groups, and keep each group in the same order

There were a few rules given to us by “upper management”:

Only one manager can visit the employees at a time.
Only the managers can tell the employees what to do.
The employees have these movement restrictions:

  1. No moving backwards.
  2. A person can only move forward to an empty space.
  3. A person can not “jump over” their own teammate.
  4. Only one person may move at a time.
  5. One spot per person, no sharing.
  6. If any of these rules are broken, the group must begin again.

We had thirty minutes to achieve the goal. 

The other team wasn’t privy to the goal, nor the rules. So early on, one of the managers informed the team of both, but then hopped back in with the other managers.

The managers were given sharpies and a big poster pad to draw everything out in the separate room. We spent a decent amount of time in that planning room drawing out scenarios, trying to achieve the goal while abiding by management’s rules, and offering a solution to the group.

The employees were left to themselves, without any tools, or a written list of the rules.

With seconds left in our thirty minutes, we achieved the goal. And if memory serves me correctly, we didn’t break any of the rules. But why did we take almost a half-hour to figure out such a simple thing? I think we made two mistakes: 

1. We didn’t iterate fast enough.

Without breaking any rules, one of the managers could have just bounced to hang out with the employees full-time. Instead, we operated in a vacuum. The three managers did their thing together, and the employees waited (and probably got frustrated) in the other room. We could have allocated a manager to just work with the employees, while the other two managers worked together.

Iterating quickly is actually how we solved the puzzle. We were nearing the thirty-minute deadline,  and had no choice but to go in and just “do it live.” So we sent a manager in.

Rule #6: “If any of these rules are broken, the group must begin again.” Ok. It takes 2 seconds to reset and try again. Why didn’t we just do it live? Who needs a pen and paper? Failure had very little cost, and it took way more time to convert the game to pen and paper.  

2. We didn’t think to write our own rules.

We have a natural curiosity and desire to solve puzzles by the rulebook. The coder in me wanted to “find the algorithm.” But to repeat rule #6: “If any of these rules are broken, the group must begin again.” Ok. So if we have to start over again anyway, why not break into subgroups? Forget the squares and move to tables for a little bit? Why not give the other team the rules to look at? Why not give them the pen and paper? Why not bend the rules?

The goal was to switch the positions. No one asked upper management: “Why do these rules exist?” We could have easily just said, “Um, no. Just go ahead and switch. Upper management isn’t looking.” That might have been boring and obvious, and we likely would have wanted to solve it by following the rules anyway. One might argue that this is just a group exercise, and it’s fun to figure out puzzles while adhering to the rules. 

But there was no special reward for figuring out the solution by the rulebook. This group exercise was contextualized in an office environment, with employees, managers, and “upper management.” In real life, the goal is the goal. If two teams were doing this for real, and achieved the exact same outcome, the faster team is likely to be perceived as the better team.

We were perhaps duped by the rules and tools that upper management provided us.

This learning is beyond relevant in my day-to-day life of working on teams that build products. Sure, sometimes, the law is the law. Company politics can certainly create an unwritten rule book. What we experienced was a simplified example of how bureaucracy can increase the time needed to achieve a goal. Rules can slow you down. Sometimes, it’s even a simple suggestion by a well-respected peer that can put you in the slow lane.

If I could boil it down, what I learned from this exercise is this: before starting a project and using the tools at your disposal, it’s really important to take a step back and make sure you have a clear understanding of the goal first. Strip out all the fluff and strategize. Optimize for resilience. Ask why certain rules are in place. Iterate often. Remember, you will measure your success by the goals you achieve, not the rules you followed to get there.


Photo by Travis Saylor from Pexels