Create containers for others to contribute

Do 60% of the work, then invite others to improve it

The Overlap is a biweekly newsletter somewhere between product development and organizational development. It comes out every other Wednesday morning.

Everyone has something to teach you. Even (and especially) those who you experience as resistant, rigid, and cynical.

Spending time in New York at the moment

Cynics want to improve their org, too

In almost every organizational transformation engagement I worked on, there were always folks who didn’t think it would work.

“This would never work at our company.”

“Why will agile work? It’s just another flavor of the month.”

“We’ve tried this in the past.”

I experienced them as resistant, rigid, and cynical. This energy made me feel frustrated. I noticed these thoughts come up:

“They just don’t get it.”

“They’re too closed-minded.”

“They’re just projecting some insecurity.”

As these assumptions came up, I caught myself and reframed them. These assumptions are what org change practitioners would categorize as Theory X. Theory X assumes that people are lazy, unmotivated, and unwilling to contribute by default. While Theory Y assumes that people actively seek responsibility, are self-directed, and want to contribute toward a broader purpose.

Falling into Theory X assumptions isn’t productive. You won’t foster positive change if you assume folks are cynical because they are shitty human beings. 

Instead, you want to get curious. Why are they resistant? What experiences have led them to criticize our change effort? What wisdom can they offer that could help?

I practiced reaching out to them. I asked for feedback on how our org change is going:

Hey! I’ve heard you express some concerns about our transformation effort. Would you be willing to share with me 1 to 3 reasons why this is doomed to fail? I’d like to do our best to avoid these pitfalls so that history doesn’t repeat itself. 

Two possible outcomes from this message:

1. They share the reasons: Amazing. Quality work is the result of productive critique. You have insights that you can apply to the org change effort. And they’ve positioned themselves from being a naysayer to a critical thinker.

2. They don’t share the reasons: You know not to spend more energy on this person. Carry on.

By inviting feedback, you create a container for cynics to contribute.

Create containers for others to contribute

Creating “containers” for others to contribute is a great tactic for product managers, too.

As a PdM, you’re constantly waiting on sign-off, input, or work output from other stakeholders. These stakeholders are in a different discipline than you: they’re a developer, a designer, a marketer, a leader, a data analyst, a customer. When others are taking longer than you’d like to give you that thing you asked them, you can easily convince yourself that it’s their fault that you’re waiting on a deliverable. “I’ve done my tasks, why haven’t they!?” 

Pause. Notice: This is Theory X thinking. What might a Theory Y way of looking at this look like?

Maybe your ask was vague. “Send me insights from your customer research work” could be more specific. Perhaps they just didn’t have a proper container to contribute in. 

Brian Dell says “do 60% of the work, then ask for the expert’s help on the remaining 40%.” This idea came from a conversation in Tom Critchlow’s Discord about how to work cross-functionally:

Doing 60% of the output gives your teammates the container for them to contribute. It’s hard to do the work when it isn’t started. It’s much easier when it’s in progress. Unfinished work catalyzes collaboration.

I made a similar point in an older blog post. Writing is a catalyst for collaboration:

In my experience, having a clearly written thing makes it easy for folks to collaborate with me. This is because people naturally enjoy poking holes in arguments, adding points that were missed, or mentioning any risks that weren’t taken into account.

In addition to creating the container for others to contribute, you are also asking for feedback. This communicates to your cross-functional partner that their expertise is valued. This builds trust. Everyone wants to contribute their expertise toward a larger goal. 

This isn’t a silver bullet

You shouldn’t always do 60% of the work and ask for feedback on the remaining 40%. This isn’t a silver bullet. 

I don’t ever write a developer’s code. I don’t ever produce high-fidelity design. If the marketing strategist is focused on customer segmentation work, I don’t jump in and do it for them. 

No one wants their toes stepped on. Be smart about when to do this and when not to do this.

Be specific about the feedback you need

The conversation that happens as a result of you asking for feedback on unfinished work is more important than how hard you worked on the output. This means that the way you ask for feedback is critical. Be specific about finding the nuggets of feedback that would drive the most progress.

Don’t prompt feedback by asking “Thoughts????” Others interpret this as “great, now I need to find all the ways that this is imperfect.” As a result, you’ll receive feedback that won’t move the work forward.

Frame your feedback specifically. Try something like:

To have this conversation in the most productive way, I’m looking for feedback on [this], [this], and [this]. Trying to solve [this problem] with this work.

Early in my career, I would just expect that people knew the feedback I was looking for. This just spiraled into conversations about trivial details of my work. I learned to help a team focus by asking for the specific feedback I needed.

It’s in our nature to contribute

It’s difficult to collaborate from scratch. People need containers to contribute.

To create that container, do 60% of the work, then ask for help on the remaining 40%. This demonstrates a willingness to help, fosters alignment, and makes it easy for others to contribute.

People want to contribute. Even and especially the cynics.

---

What I’m Reading

1. Why aligned autonomy is an ongoing struggle - Jason Yip

2. Responsive roadmaps - Matt Strom

3. Minimum Viable Work - Stowe Boyd

4. The data model behind Notion’s flexibility - Jake Teton-Landis

5. Reframing disadvantage - Mika Reyes

See you in two weeks,
–tim