#12 - Be unreasonable

#12 - Be unreasonable
Photo by Mark Duffel / Unsplash
"Ask me to do it in a week, and I will build it."

I remember standing there, dumbfounded. We'd been stuck on this wicked problem for three months. Now here's an engineer saying he could do it alone. In a week. It felt absurd. We didn't even understand half the problem space. Was he serious?

But he'd sparked my curiosity, so I asked him why he thought he'd be the one to succeed. "Parkinson's law," he said. "Work expands to fill the time you give it. The trick is being unreasonable about my deadline, but ruthlessly reasonable about everything else."

A week later we met again to review with the team. The solution was scrappy and extremely rough around the edges, but where he'd gotten us in a week's time was amazing. With his hastily written code, he changed our belief of what was possible. The team got unstuck.

In many teams, being reasonable is the safe option towards incremental progress. It helps us get along and it mostly works. Until it doesn't. Then, the structures of reason -reviews, roadmaps, stakeholder syncs- can start to turn against you. Safe plans start failing quietly, for reasons that are all justified: not enough budget, not enough time, too many dependencies. All of it sounds reasonable. None of it is helpful.

To unlock those cases, be unreasonable. Increase the pressure by applying more force to less surface area. Don't worry about quality, stop seeking more time, break a reasonable rule. Invite your team to do something wildly unreasonable. While it may feel reckless or borderline delusional, you'll be surprised by the progress of an unreasonable man.

Because being unreasonable doesn't just change the goal.
It changes what people believe is possible.


p.s. the simplest way to see this principle in action is to ask someone to draw Spiderman in 10 seconds.

Subscribe to adaptivespace

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe