TBM 3/52: Help Your Team Find Its Own Way
I enjoy when companies like Basecamp, Intercom, and Buffer describe how they work. Specific examples are useful. But I always recommend that people look deeper. Why do these approaches work in context? What are the underlying principles at play?
Each of these companies arrived at an optimal batch size of six weeks. Is there something magical about six weeks? No. New and unique? No. This is pretty common. Useful everywhere? No.
But if you've worked in product development for a while you can figure out why it works/worked (for them).
Six weeks is enough time to do something meaningful. But not so much time that you can wander too far afield. If you dawdle you're liable to get off track, so there are incentives to make progress early and work small. And if things go wrong? It is not so much time in the grand scheme of things. You've got the next one.
What else? It helps with apples to apples prioritization. And strikes a balance between "set up costs" -- the overhead of putting an effort in motion -- and the time spent working. Basecamp keeps their planning inventory at zero (no backlog or roadmap) -- a beautiful example of lean principles at play.
But this is not a post about six week cycles (or about Basecamp, Intercom, and Buffer). When you get to chat with lots of teams, you learn about all sorts of interesting approaches. Many were lovingly (re)invented in-house, and given unique names. Many were replacements for the last Way, which was a tweak on the Way before that. And many borrow, copy, paste, and tweak -- either knowingly or not -- from other teams and various traditions.
Anyway, you start to realize that it is the willingness to experiment and continuously improve that is key! It isn’t the 6 Weeks! The path they took to X was/is as important as where they ended up.
I’m torn. I think there is some validity to the argument that new teams might benefit from copying what [Some Company] does, or did. Doing that might be a decent start. An experiment. Or it might give them air cover with their managers. But I get nervous when I see people putting companies on a pedestal for what they evolved over many years — and maybe don’t even do anymore.
In closing, ask why X works in context. Try to tease out the principles. Sure, research what others have done, but work together with your team to evolve your own way. You’ll be tweaking it forever anyway, so might as well get started.
Check out the 2020 TBM collection on Gumroad!
You can find the free web version here.
A quick checklist for high decision quality and decision flow. When looking at what Company X does, ask how it supports these things:
A table I put together a while ago that I refer to often. When looking at what Company X does, ask how it supports the shift from left to right:
