TBM 4/53: Teach by Starting Together
I am a big advocate for starting together as a whole team.
What is the opposite of starting together?
Most of the time it means doing early work on an initiative in a smaller group while the team focuses on delivering something else. The small group tends to be more senior/experienced. At the "right time", the official kickoff begins. Someone describes the work and the research, and the team starts working.
The small group approach tends to be more efficient in the short term. Meetings are easier to schedule and run. The conversation flows. Conflict is easier to tame and temper. "Fewer people are sitting around." There's less scrutiny. For roles like UX, starting in advance also carves out much needed space for less structured work. This is all true.
Some people get very nervous when they can't hear people typing (or when they themselves aren't typing). "We aren't paying developers to sit in meetings and play with stickies!" they say. I try to put myself in their shoes. If you've never seen co-design and starting together work, you're liable to settle on what you know: typing = progress.
My main problem with the small group approach is that it impacts learning. Less experienced team members don't get exposure to the discovery and "shaping" process. Seeing the final deck, mockups, or "high level stories" doesn't count. Instead of building product discovery chops across the board, we silo those skills. In my experience, resiliency decreases.
I'll always remember an activity where we paired more junior and more senior developers with a subject-matter expert CEO. Two customers, a Product Manager, and a Designer also attended. A UX Researcher facilitated. The CEO took off his CEO hat (and HIPPO hat). Together they grappled with a messy problem. It was rocky to start, and divergent, but after a couple days -- and fifteen customer calls -- they found their stride. "I remember when we always used to work like that!" said the CEO, "it was always so invigorating. I can see how this will save us time in the long run.”
There was a small group who did the legwork and prep for that effort. But they didn't start the effort without the team. Their primary role was that of context builder.
I understand all the risks here, and completely respect that many teams can't start together (or don't want to, and do just fine).
What I would suggest is an experiment. Some teams are successful with "rotations". They'll invite one or two less experienced team member to participate in discovery or research. The invited team member gets the support of her team, very reduced workload, and commits to show up. When (and if...often this work results in a no-go) the effort "starts", she can act as a bridge to the discovery activities.
Give it a try. Let me know how it went.
I’m confident of one thing. That junior developer or designer (or marketer, or data scientist, or product manager) will learn something.
Tidbits:
Wrote this thread about real world experiments.
Very cool hands-on free strategy mapping practice with David Holl and Ben Mosior. Two session: Jan 24 and Jan 25.
Having our son has sapped my memory. I forgot about my Vimeo explainers.
Hosting a Product Community Happy Hour in London on Feb 5 at The Gherkin
Missed this post by Jared Spool on UX Metrics. Very good.
Kicking off the Iterate.fm podcast again with Tareq soon.
