I had teams working internationally, installing and integrating systems across multiple time zones. When something broke in the field, whether it was our in-house software, a third-party machine, or a customer’s equipment we’d integrated,my team had to make it work. We were the integrators. The product had to be delivered.
The communication between my field teams and the development team was terrible.
My guys would say: “Dev didn’t even read the email. They asked me the same questions I already answered.” The dev team would say: “Did they check the logs? Did they do anything before they shipped this over to us?”
This was happening multiple times a month. I realized we had a communication problem, not a technical one.
The Soft Skills Program
I’d been running a soft skills class for a while. Wednesday afternoons after lunch, one to two hours. It was a light day, and I used that window to teach things most IT departments never talk about: structured troubleshooting, communication protocols, the basics of working with people who aren’t in the room with you.
The troubleshooting methodology came straight from the Marines. When I was trained on F-18 avionics, they taught us a process: make an assumption, predict what the output should be, test it, evaluate the result, then use that information to inform the next step. I didn’t realize at the time how valuable that framework would become, but I’d been teaching it to IT teams for years.
I’d already taught a communications class before, when to send a text, when to send an email, when to pick up the phone, when to walk down the hall. The formality ladder. That took an hour and it was useful.
This was different. I needed my team to feel what it was like on both sides: to be in a remote location, relying almost entirely on email, trying to solve a problem with someone who isn’t looking at what you’re looking at.
The Setup
I went to Target and bought two identical 500-piece LEGO sets. Generic, random bricks, no themed kits, no instruction booklets.
And this is where my OCD kicked in. I assumed the two boxes were identical, but this was critical. They had to be exactly the same. So I poured both boxes onto a table and sorted them back into two buckets, two pieces at a time, one in Bucket A, one in Bucket B.
My brain absolutely loved it. You know what I couldn’t do while sorting LEGO bricks? Think about anything else. It was an hour or two of pure quiet. Just sorting. As an aside, the two boxes didn’t match. I had a few pieces left over. My paranoia was justified.
The Exercise
I split the team in half. Each team had a mix: project managers, senior systems engineers, junior engineers, and field technicians. Same composition on both sides.
Each team got an identical bucket of LEGOs. I sent them to two different rooms, the boardroom and the training room.
The instructions were simple: Build a doodad. Then write instructions so the other team can recreate your doodad using their identical pieces. You have 30 to 45 minutes. Your only method of communication is email. Go.
I walked back and forth between the rooms and watched.
What Happened
Neither team finished the exercise. Both teams failed. That was the point.
Some people were just excited to play with LEGOs, and honestly, I couldn’t blame them. Some teams naturally divided the work: half building, half writing instructions. Others threw all their talent at building an elaborate doodad and barely started on the communication.
One team tried to craft one perfect, comprehensive email. They spent so long writing it that they never actually sent anything before time ran out. The other team fired off fragments, “get two 4-by-2 blue bricks”,with no context about where those bricks went or what the final structure looked like.
Instructions described colors and shapes but not spatial relationships. “Blue brick on top”, on top of what? “Attach it to the base”,what base? What does “attach” mean with LEGOs? The receiving team was frustrated because every instruction assumed knowledge they didn’t have.
Someone sent a clarifying question by email. They never got a response, the other team was too busy building to check their inbox. At least one person on each team tried to take charge of the email, creating a bottleneck while others waited. Someone tried to send a photo of their build and was reminded: email only means text. At least one email arrived with no subject line, no greeting, no context, just raw instructions dropped into a void.
Both teams panicked about the clock. Both prioritized their own build over the communication task, the thing that actually mattered.
The Debrief
Everyone came back to the training room. I asked one question: “What did we learn?”
The room exploded.
Is it better to have all the information at once, or to send pieces of information in a timely manner? Is a perfect email that arrives after the deadline better than an imperfect one that arrives early? If your instructions assume the other person knows what you’re looking at, do they actually help? If you’re too busy doing your own work to read the question someone sent you, what was the point of having a communication channel at all?
Every failure mode they’d just experienced was the same failure mode that played out between the field teams and the dev team every single month. Nobody had to say it out loud. They all knew.
The Closer
I didn’t fix the communication problem with a PowerPoint about email etiquette. I fixed it with two buckets of LEGO bricks, a 30-minute timer, and a rule that said you can only use email.
Sometimes the best way to show a team what’s broken isn’t to tell them. It’s to put them in a room, give them a task that’s designed to fail, and let them discover it themselves. They’ll remember the lesson a lot longer than they’ll remember the lecture.
The LEGOs cost about $40. The look on their faces when they realized they’d been doing the same thing to each other for months? That was free.