Here’s a question I received today in response to this post on Certainty Theater:

Q: I have a question about the the cold start problem: when you start a cycle (e.g. quarter, sprint, etc.) and product isn’t ahead of a design or engineering backlog. In this case, you feel obligated to project certainty in order to win resources because you’re not confident that you’ll be able to get resources later once you’ve figured out a bit of roadmap. In large organizations it’s coupled to hoarding behavior.And here’s my reply:

My first thought here is that you have to clarify the value of the opportunity. If the opportunity is lucrative, it doesn’t matter — within reason — whether it will take one month or six months, or what the exact roadmap looks like. This is especially true if the team is known for incrementally delivering value and pivoting early when the going gets rough. Progress = continued funding. Plateau = move on to the next thing.

Past outcomes matter. In other words, in your organization do small cross-functional teams have a track-record of starting together (cold start and all) and doing awesome things? It is very difficult to appreciate the value of not “getting ahead” of the work, when you haven’t seen the upside potential. In an environment where no one has seen it work, I recommend doing one or two efforts like this as an experiment. Show don’t tell.

My favorite “Starting Together” picture … https://www.imdb.com/title/tt0089218/mediaindexWhat else might be going on?

Likely, there is someone being incentivized to “play Tetris”. Tetris playing optimizes for packing as much output into a timebox as possible. “If we know this thing is small, we’ll take three people and put them over HERE!” The idea of starting with too many people, or having something take twice as long (even if supremely valuable)* *is anathema to the Tetris player. Tetris players are also more than happy to have a single person work on something low value “over there”, just to avoid having to say No to someone. Or the idea of pairing/mobbing feels messy, and they’d prefer to have a 1:1 relationship between individuals and projects. So…the game of “what does the feature roadmap and backlog look like” takes hold. You can’t play Tetris without knowing the size/shape of the pieces.

Along those lines, you need to ask what constitutes a team. If you have twenty people do you have 20 teams of 1 person each? Or 5 teams of 4? 20 teams of 1 feels powerful because you can do 20 things at once, and “hold individuals accountable”. Sadly, you don’t get the synergies (gotta love that word) you might get with groups of people working together. Throw in a shared team member (paging Design), and you’ll more pressure to figure things out (e.g. “is this Design Heavy?”. Same holds for specialist developers.

All of this points to semi-stable, small teams (in the truest sense), able to tackle any challenge on the “backlog” of opportunities. Prioritize opportunities, not interventions (unless you are talking the proverbial “low hanging fruit” which should be nearly guaranteed small and med/high in terms of valuable). Finally, recognize the power of a team truly starting together, and surface the inherent waste in “packing” large planning inventories with potentially valueless stuff.

Cheers!