TBM 29/53: Quicksand vs. Challenge

Update: I had a great time recording an interview with Shreyas Doshi (the Twitter product thread wizard). It is ninety minutes of wisdom, humility, and self-awareness. Shreyas was kind enough to help supplement the transcript with various related threads.

Product is challenging. Everywhere.

People read "how we work" posts from well-known companies and imagine product utopias. The posts make things seem so functional, and easy. In reality though things are never easy. Why? The work is collaborative, creative, and messy.

That said, I have observed huge differences between organizations and teams within organizations.

Some teams operate in veritable fever dreams. They navigate endless mazes, thwarted at every turn. There's no momentum. Days filled with firefighting, punctuated by mind-numbing meetings and navigating "blockers and impediments". Things feel like quicksand.

The opposite situation is no less difficult. But it is a different kind of difficult. If the prior situation is like a fever dream, this is more like one of those epic adventure dreams. Instead of quicksand, these teams have some momentum, at least some of the time. It is tough going, but there's progress. There are ups, like delivering something that has a lot of impact. And downs, like completely missing the mark, a team member leaving, or a challenging kickoff.

Why is this important?

I met an executive recently who was sure teams at his company needed to learn a bunch of new practices and frameworks to "do product". This was a large enterprise in the middle of a "product transformation".

"I'm guessing this is one of this crawl, walk, run type situations," he said.

WRONG! I didn't say that. But I thought that.

What was he missing? Quicksand! Frustration dreams.

The teams were spending most of their energy battling organizational inertia. They couldn't operate independently, thwarted by an outdated architecture that created dependencies everywhere. No access to customers. A siloed, understaffed, design org. Dozens of stakeholders. A calendar filled with song-and-dance Scrum rituals. Proxy metrics. No clear strategy. This was not a knowledge and skills issue. No team, anywhere, could do good work in those conditions.

I did manage a “I’m not sure OKRs are really going to address the key issues here.”

I've come to believe that a lot of what people see as "skills" on the part of well-known product companies, is actually freedom and space. The work is difficult, but the good (or at least rewarding) kind of difficult. At a core level, the organization has confidence that the teams will contribute meaningfully, and the surrounding architecture, strategy, and org structure support that. This is most evident when junior product designers and product developers join the team. Yes, the ramp is hard. But they are able to contribute fairly quickly.

If you haven’t experienced that flexibility and freedom, it is easy to assume that the quicksand is just “the way it is”.