Start Together. Finish Together
It may seem counterintuitive, but…
Start together (at the last responsible moment)
The longer we let ideas and plans stew, the more we fall in love with our pet-solutions, and perspectives. The longer things sit in the “to do” column before the team doing the work actually gets involved…the more crap and baggage they accumulate. You risk…
I’m not suggesting you avoid doing the hard work of building shared understanding, and making tough decisions. Do it (well), but…wait. Wait until the people doing the work can participate, and wait until you’ll actually be able to act on those decisions and exploit that shared understanding (lest all that work just goes to waste as the cobwebs accumulate).
For example…
A problematic initiative kept imploding. Over and over. And each time things went south, a small number of managers would get together and try to figure out “the problem”. Finally, someone (a newcomer) booked a room for a week, and forced everyone involved (developers, designers, managers, etc.) to get into the room. They made sure it was safe to speak up. It turns out that there was never a proper kick-off with everyone involved. Not the 1 hour kind where people nod their head and process <10% of the material…but the three day kind with customer interaction, sensemaking activities, divergence, convergence, messiness, and a powerful outcome.
Had anyone done this originally? Sort of…through countless 1:1s, separate plans, vastly different interpretations, pre-work, pitches to the CEO, CEO pitches to the board, customer promises, back-of-the-napkin estimates, and “small group” meetings. There was a budget, even, and allocated teams! And good intentions … to “make the best use of everyone’s time, and let the developers stay on task”.
So much talk, but if you were to test for shared understanding, you’d find very little shared understanding, and tons of (often accidental) solutioning. More than once in my career I’ve heard some buzzword project get floated around — Project X Redesign — for months, and months…and when it actually became time to talk about it, literally no one described it the same way. And no one could explain the why, other than … “oh, I hear it is super important!”
Why do we do this?
You’ve got loads of people who aren’t building/designing/problem solving who genuinely want to help. How do they help? Talk. Plan. Think. Pitch. That is how they know (and are trained) how to help. Their mental model is that developers/designers are this tiny little pipe, and you have to play this intricate game of Tetris to get the most amount of work “through the pipe”. Ideas are cheap and plentiful. So we load up on ideas, and try to “land” them on teams at the best possible moment. It doesn’t work all that well, and leads to a ton of missed opportunities.
What is the alternative?
Simple, but oh, oh so hard:
- Fall in love with the problem, and resist solutioning
- Embark on discovery together — with the team assigned to solve the problem
- Assign teams to missions, not projects
- Allocate time for powerful, inclusive kickoffs
- Limit planning in progress (“getting ahead of it”). Limit work in progress
- Resist “pre-binding” teams to efforts in advance. Don’t play Tetris (which necessitates a lot of pre-planning, estimation, and early-binding of resources…basically reinforcing the anti pattern)
I’m not ruling out all advanced work … certainly, analysis and research can help frame a powerful opportunity. But limit your work to context building vs. solutioning and pre-planning.
So what is “finish together” about?
Resist the temptation to shuffle teams to new projects without seeing things through. Did you achieve the outcome? Are things on the right track? “Just ship it and move on” is terribly demoralizing for your team, especially if your bets routinely fall flat. At a minimum, leave enough time to make sure things are moving on the right track and that there are some indications that the thing is working.
