TBM 43A/52: More Stories About the Mess

Here's a big challenge in the industry.

On one hand you have simple frameworks. Yesterday's post on Drivers, Limiting Constraints, Floats, and Enabling Constraints is an example. I have dozens of these. The product space is awash in four stage acronyms, three letter acronyms, canvasses, loops, figure 8s, and variations on the same ideas. And we create more every day! It is easier to create new ones than find the best old ones.

Note: It is a total joke that I included a stupid seven stage thing here.

Then you have have high-level principles/patterns like empowering teams, and focusing on learning. These are very important. It is vital that we shout these things from the rooftops. Simon Wardley's "Doctrine" is a good overview of these ideas.

Less so now, but I used to write incessantly about patterns and principles. I would write things like this for fun (yes fun).

There's product leadership advice and general leadership and management advice. Again, very important. Product leadership is hard.

You also have vast and complicated frameworks like SaFE. I very rarely interact with teams using SaFE, and that is fine by me. To be honest, it might be the perfect framework for those companies. It's unclear whether anything else would work.

Here's the problem. And it is a problem reflected in my conversations with teams from around the world on a daily basis.

We don't have enough stories about operationalizing any of this "at scale" (e.g. >10 teams). We don’t have enough stories about The Mess. Sure you have Spotify and those classic presentations and posts. And a couple of companies that have written "how we do _____" type posts. But beyond that there is very little to draw from.

So say you are a bigger company, and you know you don't want to do SaFE. You know the Spotify Model was a point-in-time snapshot. You've bought into Cagan's Empowered. You understand some of the ideas in Team Topologies. You know you'll need to adapt anything! You might even have direct experience establishing an operating model, but it was at a smaller company.

There are very few examples to share with your team. Which is a big problem! Not every executive will be with it. They are right to distrust one company's blog post or one book. One of a couple things happen. These companies either:

• Spend time reinventing the wheel instead of focusing on making the customizations that matter

• They apply the simple frameworks on the "team level", but end up using whatever top-down project management approach they were using before

At the day job I talk to LOTS of teams. And hear about their artifacts, tools, rituals, documents, etc. The work is non-trivial. I chatted with a team recently that has:

• 8 key document types

• 12 key meetings types

• An 80 page "how we build" internal document

• Team level agreements (So ~50 of those)

• Playbooks for quarterly and annual planning

• Various other playbooks (kickoffs, learning reviews, etc.)

• Templates for Amplitude notebooks and dashboards

• Metrics overviews and descriptions

• 3,000 pages in a WIKI ... many of the pages are regularly reviewed

• A big onboarding program to help situate people

We talked for HOURS. This is a company known for being VERY GOOD at product.

Yet the world will likely never hear about how they work (because of legal, the time, etc.) Or even see a “Table of Contents” of what is required.

And I kept thinking "My god, if only BigCo X could see this! BigCo is inspired to work in a better way but just can't see how it all works!"

So here's my plea. Either start telling more stories. Or I might have to start a side project interviewing companies anonymously and sharing the details. That might make a fun Patreon actually. Not every company is a dark enterprise hellbent on having a formula. There's a huge community out there looking for reasonable inspiration.