Be Strong

by: Douglas Gastich

“You can’t be strong in two places at once”

This important lesson was shared with me by Nick Theodorou, my martial arts instructor, over 20 years ago. It resonates today.

Sensei Nick used a physical demonstration to prove the point. Nick would ask a student (usually choosing the biggest guy in the class) to hold out an arm, extended, straight and level to the ground. He’d apply pressure to the arm, and ask the student to resist. No way Nick could pull down a determined arm. Sometimes he’d even hang on the arm. No budge.

Then Nick would prove the point. He’d take one hand, and casually, almost lovingly caress the nape of the student's neck. Distracted, the student would inevitably lose focus. With just a slight bit of pressure from Nick’s other arm, down comes the student's arm.

You can't be strong in two places at once.

Wait, really?

Was that just a party trick? Was the student in on it? No, it is a real thing, and an important lesson about focus, resource allocation and decision making.

But I have to be strong in two (many…) places at once!

We all do. But you don’t have to do everything yourself. Smart leaders and teams organize by area of strength and then give operators space to be strong.

What does any of this have to do with software development, building apps, or applying technology to solve problems? Here’s what I see:

1. Scope tightly. Keep the project simple. Avoid the urge to solve all the problems.
2. Speaking of problems, find the most important. The real problem. The ‘job to be done’. Address that problem directly.
3. Focus your teams. One way to be strong in multiple areas is to be smart about who you have working on which problems.
4. Get help. It's hard to be strong, and to stay focused, when software projects are not your core focus. A team like Germinate can bring expertise and energy to make a project succeed. A strong external team is a force multiplier.

It's been a while since I tried Nick’s demonstration. But I’ve seen many projects fail for this precise reason: Too many ‘critical’ problems to address, too many distractions and surprises. You get to chose what you (and your project) ‘reacts’ to. Chose well, keep it simple, and stay strong.