Peanut Buttering

Helping your team progress even if you don't know anything

(I have a dream of maintaining a personal wiki with evergreen pages about different things. Then if I want to explain my take on something, I can just link someone to the relevant wiki page. This post is a rough draft of one such page. The intended audience is software engineers.)

Sometimes you need something to happen in order for your work to succeed, but you can't do that work yourself. Worse, sometimes it's not even clear who can do that work, or even who knows who can. Often in a situation like this, progress grinds to a halt. What can you do when this happens?

I have good news: there is a general skillset of "making progress" that you can apply to any situation, regardless of whether you have any idea what's going on. It's straightforward and yet also magical -- someone wielding this skillset will be beloved by all.

This skillset deals only in people, questions, and commitments.

Step 1: Figure out what the next step is. There might be a dozen things that need to happen to resolve the problem, but right now you only need to worry about the very next step in the process.

If you know that is, great! Say in whatever chat you're in: "To move forward, first we need to (NEXT STEP).

If you don't know the next step, that's okay too. If everyone's at an impasse, it's often sufficient to just ask "What's the next step here?" and some knowledgeable lurker/introvert will chime in.

Step 2: Find an owner. If you're in this situation, it's because right now it matters more to you than to anyone else that this problem gets solved. That means you're probably the de facto "owner" of the problem. But you also have admitted that you can't do the work necessary to fix the problem yourself. So you need to find a new owner, and fast.

The owner for a problem can change over time, but at any time it should be the person who is on the hook for the next step toward solving that problem. If there are multiple parallel next steps with various owners, then the owner is accountable for making sure that all those steps are completed, and synthesizing the result into a next-next step.

So, you found the next step earlier, now you just need someone to commit to owning it.

Once again, if it's obvious to you who should own it, great! Say in chat: "@Person, does it make sense for you to own doing (NEXT STEP)?"

If you don't know who should own it, that's okay too. Ask: "Who is the right owner for this?". While you may not know who should be the owner, you might know a person who is likely to know who should be the owner. If so, give them micro-ownership of the owner-finding problem, by asking: "@Person, who is the right owner for (NEXT STEP)?".

If you have absolutely no idea who could possibly own it, just guess. Pick a random person, even someone you're pretty sure should not own it, and say: "@Person, does it make sense for you to own (NEXT STEP)?" If they say no, just immediately move on: "Got it. @Person2, would you be an appropriate owner?". Chances are someone will say yes. And if not, and you go through the entire group and everyone says no (this should be really rare!), you can say "Okay, it sounds like no one here can be the owner. Who do we need to pull into the conversation?" You've gotten out of the dead-end and can resume problem-solving.

Step 3: Get the owner to commit to a timeline. At this point you should have someone saying "yes I'll own that." It can be useful to set expectations of when we can check in on the completion of their NEXT STEP, to see if we can move on to the NEXT-NEXT STEP.

This can be accomplished by saying, "Thanks @Owner! When do you think you will be able to complete NEXT STEP?". Once they publicly commit to both ownership and an estimated timeline, you're golden. People don't like to look bad, and it looks bad to break a public commitment, so they generally won't. Go do literally anything else, just remember to come back at the estimated ready date and check in on their progress.

Step 4: Is the problem solved? If so, you're done. Otherwise, go back to Step 1.

--

That's it! You can repeat this algorithm ad nauseum and progress WILL be made. It's simple and effective.

There are, of course, edge cases. When an edge case happens, either nudge, or escalate.

Nudge: This is for cases where you simply aren't getting a response. You asked for a next step, or for an owner, and all you got were crickets. It's okay -- sometimes people are busy, or get distracted, or they're hoping that you get busy or distracted so they won't have to help.

The best remedy is to remind everyone that you do care, and that you will keep nudging until something happens. This can look like:

Escalate: This is for when your nudges are ignored, or the owner will only commit to a timeline that's slower than acceptable, or the person who obviously should be the owner refuses to own anything. In other words, this is when you don't see a path forward. If you just keep pushing, you'll be pushing on a brick wall that's unlikely to budge.

In this case, escalate[1].

(Note: this is where your organization culture may vary, so proceed at your own risk. I have very monocultural experience.)

The most common path is through the manager of whoever appears to be blocking your group's progress.

Send them a message like "Hey, I'm (BLANK) and working on (BLANK) which is important because (BLANK). We need help from (PERSON) to proceed but (they haven't been responding; they seem to have competing priorities; they haven't been able to make much progress). Is this something your team can prioritize?"

They might need more information from you to understand what they should do to help. The manager may say "No, Person isn't the right owner for this" -- to which you can then ask "Who is?". But some version of this escalation conversation should be sufficient to un-stick the gears and get progress moving again.

OR: you may realize that actually, the only person who can help you in fact can't help right now. The manager may respond: "No, we are busy with higher priorities than this". If this happens, you can try to talk through to find where the disagreement is. You might even find you agree with them, and that it really would be a silly move to prioritize your problem over their other, bigger problems.

If they couldn't suggest a path forward that's acceptable to you, you may require an extended escalation. You can return to your manager (or whoever is the stakeholder of the problem you're solving) and explain the impasse you've reached. Now they can decide whether to escalate further, or if the current level of support is acceptable.

One way or another, at this point you've once more found the next step, and can return to the Infallible Process detailed above.

Conclusion #

You'll note that everything I wrote above was mind-numbingly vague. I didn't mention any specifics, and it wasn't even really software engineering specific.

And that's the power of this method! Even if you know diddly-squat about whatever everyone's talking about, you can ALWAYS ask "What do we need to do next? Who should do that? How quickly can they do it?" over and over until things move forward. It may require a lot of nudging, and an occasional escalation, but I promise you it will work.[2]

And when you do this, people will be grateful. Because a lot of the time life is a swirling, confusing mess, and no one knows what's going on or what they can do to help, even if they badly want to. If you bring calmness and clarity to a situation, and help others identify the next baby step to take on a journey of a thousand miles: that is kindness.

  1. This should really be its own entire page in my hypothetical personal wiki. Or, I know it's been written about a million times elsewhere on the internet, so I could just link to (or you could just google) such a post. ↩︎

  2. You may be pleased to discover you can also use this method in non-work contexts. ↩︎