Humans are great at reacting. A lot of us wish we were better at planning and anticipating and preventing, and also, the reality is that we don’t fix things until we really need to, we don’t make changes until something pushes us over a line.
We can use this reaction to move things faster and get our teams aligned around a common understanding.
What it takes is giving people something to react to.
Let’s break that down into the two critical components:
“Something” is not a rough draft or a minimum viable product
Rough drafts are big. Minimum viable products (MVPs) are big.* They’re a substantial investment into a particular idea or direction.
(When I think about the ‘rough draft’ of a 5-page paper, for example, I’m envisioning around 3 pages of ideas and quotes. It’s the result of a substantial investment of work. I don’t want to invest the equivalent of that much work before realizing that I’m missing some critical context. I don’t want people on my team to spend that long on an idea that isn’t solving the root problem.)
By the time we’ve done that much work, we want to avoid throwing the whole thing out and starting over. Our peers may feel reluctant to tell us that we should.
And starting over is often the right response to ideas – especially wild, unexpected, high-potential ROI ideas!
The smaller you stay, the more freely your peers will give you feedback and the more freely you’ll be able to walk away from it. That’s why I use the phrase “something to react to” – “something” is not yet even a draft or a mockup or a chunk of pseudo-code.
Words are important! They shape our actions.
*MVPs don’t have to be big, and also most of us are incapable of keeping them small.
“React” does not mean generic, polite, or “what do you think?”
We often casually float an idea to a peer – “hey, what do you think about [idea]?”
It’s easy. It’s also not very useful. It yields a lot of false positives (“easy to like” ideas are often too incremental to be valuable) and a lot of false negatives (unique ideas often sound impossible or too complicated when summarized).
Imagine getting a message like this:
“How do you think we could improve cross-team communication?”
How do you respond?
It’s hard to know where to start – especially if you don’t know the person well enough to predict their intentions. Should you give a surface-level answer or go into details? Do they want you to be honest, or to politely validate the status quo? You don’t want to suggest tactics that I’ve already tried or make recommendations that don’t work with the specific constraints of my situation. It’s a waste of time if you write a 2-page memo only to find that I was thinking about a different problem. Or maybe you think this is such an important topic that you don’t want to respond until “you’ve had time to really focus and think about it”.
Either way, no progress happens.
We need to bravely ask some questions that reveal our lack of context or domain knowledge. We need the other person to pay attention long enough to argue with us or join forces with us.
Human brains notice when something doesn’t match our knowledge of the world, even if we don’t understand how or why it’s wrong.*
How is this different from “strong opinions, weakly held”?
“Strong opinions, weakly held” is all about the opinion-holder.
I mean, it’s the same general theory – and also – I’ve seen too many people use that phrase to mean “I, a person in a position of power, am going to shout my opinion and assume that any junior or underrepresented person will of course feel comfortable publicly challenging me.”
“Something to react to” flips the situation – it’s my responsibility to create a ‘something’ and it’s meaningless unless it encourages you to react so I can learn from you and my idea can grow stronger through your input.
I’m on a team where people only show very ‘refined’ work – how can I get us closer to ‘something to react to’?
I’ve found that introducing the concept of “30% vs 90% feedback” is an easier first step.
Start by explaining the concept:
- “30%” ideas are explorations, early enough that it’s okay to change anything or even throw the whole thing out, early enough that polish or detail feedback is a waste of time.
- “90%” ideas are close to done, there’s still time to adjust and refine, it’s too late to incorporate major changes so save that feedback for a v2
You don’t need to convince everyone to actively use this language – once you’ve set the expectation, you can refer to your own work as “30%” and direct the level of feedback that will help you most:
“Hey, I wanted to share this spec. I’d love your 30% feedback, I put some very early thoughts on paper but I’m probably missing context. Is this solving the right problem? Am I missing major constraints?”
You can also ask teammates what type of feedback they’d like.
“Just to be sure, is this mockup at more of a 30% or 90% feedback state? Are you looking for feedback on the core concept or should we talk about pixels and details? What would be most helpful to you?
30%/90% feedback helps people get relevant and useful feedback on their work. Once you’ve introduced the concept, it helps to normalize sharing early and ‘ugly’ or incomplete work.
I’m willing to try this, but I’m a little concerned that being blunt / showing early work will be perceived as rude or careless.
Yep – this is why we usually engage in generic polite questions and face-to-face meetings where we slowly assess the other person’s motivations… all of that social interaction that is both valuable and slooooooow.
We still need to build trust with coworkers and stakeholders – that work should be ongoing. And also, we can get away with more bluntness/early work when we explain what we’re doing and why. For example, I might first send a message like this:
Let’s see if we can avoid having to have yet another meeting. I’m going to state some assumptions and questions. Some of them are going to be wrong or incomplete — please correct me, add context, and/or add your own questions! How does that work for you?
And then, once the recipient has acknowledged that message, I’d follow up with some bullet point assumptions and/or questions. For example:
Assumption: you’re already doing (design|spec|code) reviews, and they’re ‘too nice’ – you aren’t seeing healthy critiques and hard questions
Assumption: you believe that being generative and exploring many solutions leads you to better solutions
Assumption: you’ve seen cross-functional projects go faster and smoother when someone takes ownership, but you’re not sure if you have enough context to play that role
Question: how safe does it feel to share very early, very rough ideas within your team?
People respond quickly because these points are so specific that they trigger agreement or disagreement. Most of the time, someone can correct assumptions and give me context within a quick reply. Sometimes we get to avoid a real-time meeting! Other times, the meeting goes quickly into productive problem-solving because the overhead of exchanging context happened so quickly.
Is ‘something’ always in writing?
No! For me, it often is. But a “something” can be a pen-and-ink sketch, a bit of pseudo-code, or whatever the small fast unit of your craft is. As long as it’s direct and opinionated, it moves the conversation along quickly.
I manage a team and I want my reports to feel comfortable sharing ‘something to react to’ work – how can I create an environment where this feels safe?
Start with yourself. Share some early work with obvious holes/flaws and give your team explicit permission to correct or add to it. “Jie has worked on this feature more recently than me; what am I missing?”
Even better: don’t ask on-the-spot in a meeting and stare everyone down – find a volunteer. You probably have at least one person on your team who could be a willing volunteer. During a 1:1, ask them if they’d be comfortable critiquing your work, and/or sharing some of their early work with the larger group.
When you explain the ‘why’ – that you want everyone to feel more comfortable sharing earlier-stage work so they can get helpful feedback faster, they’re likely to agree.
Shower positive recognition on anyone who shares early work. Look for ways to remember useful takeaways from shared work – “remember when Dave tried [approach], that’s how we discovered [constraint] before it became a big problem”.