TBM 11/52: Scaffolding & Skepticism

Midjourney: prompt “scaffolding, building, fine lines, and watercolors”

Scaffolds are helpful and sometimes necessary. 

Example:

To understand and eliminate costly dependencies, you’ll need to observe those dependencies. To accomplish that, you might set up an intricate system to specify and view dependencies across the organization.

But the scaffold isn’t the end goal—ideally, you remove the scaffold. You don’t want to institutionalize costly dependencies! You don’t want someone falling into the trap of trying to “manage” dependencies instead of eliminating them. When this is over, you want dependencies to be the exception, not the rule.

Someone asks Mary to fill out a dependency list. Here’s what might go through her mind:

Oh god, another one-off form to fill out. And why? Are they going to do something about it this time? I don’t want to work somewhere that makes me fill out dumb forms like this. I don’t want to be reminded about all these dependencies. We raised this last year, and no one did anything about it. Plus, do they know I’ve filled out 20 other forms this week from all the other people trying to fix things?

Mary has a lot of good points! 

Notably, she is NOT “resistant to change” and presents a perfectly rational argument. Why will this time be different? What evidence does she have that her company will follow through this time? And what is to say that dependency management (vs. elimination) will not become the norm once people see the fancy charts?

My theory is that most “resistance to change” is realistic pessimism of corporate machinations.

It’s a puzzle:

1. By definition, the scaffold may be more work (it is not subtractive)

2. People rightfully suspect the scaffold

3. But the scaffold may be necessary

The fix here is to be incredibly intentional about your goal and position the scaffold as an experiment. You must align on The Why, and frame the experiment as a Way.

Example (ideally from a senior leader):

The goal is to have fewer messy projects with many dependencies. We guess that over 60% of our efforts have >2 dependencies, causing tons of pain for our teams. Painful dependencies were a huge theme in our recent cross-department retro. Just this week I was meeting with Team Juniper, and heard about how many meetings they needed to attend, just to make some forward progress.

The problem? We currently don’t have a way to visualize these dependencies reliably. We can’t prioritize. We need your help to get this data. We estimate it will take ~20 minutes a month, so we’ve asked managers to give everyone the time during business hours to help. Once we get more reliable data, we will prioritize work to address the biggest culprits. This is a priority, so it is OK if other things slide. 

We also commit to holding ourselves accountable as leaders to follow through. We’ll be adding KPIs to our bi-weekly readouts. Our goal is that <10% of initiatives have >2 dependencies by 9/1/2023. If our progress lags, we will gradually focus more and more attention until we make a meaningful dent. Once we get to that point, we will pause manually collecting the information. If by the end of the year, we haven’t made enough progress, we’ll pause anyway and try another approach.

Thank you, and please feel free to DM me any suggestions on how we can make this easier for everyone.

That’s how to erect a scaffold and promise to bring it down! Note:

1. Acknowledges the pain (really)

2. States the problem in a way most people can understand

3. Makes it a priority—in a sense making it at least neutral (not additive)

4. They ask to be held accountable

5. They give the whole thing an expiration date

6. They give a channel for feedback

Scaffolds are helpful. But you can’t leave them up!

Aside: Be skeptical when people say teams need training wheels. Often they have a vested interest in selling training wheels. Or SaFE.