Open the Scrum Guide and read the job description for the Scrum Master. One line has shaped a generation of engineering managers:
"Causing the removal of impediments to the Scrum Team's progress."
It's right there in the official guide. Somewhere along the way, most of us shortened it in our heads. Not "causing the removal." Removing. Personally. Fast. Every time.
Someone's stuck on a flaky test? You fix the pipeline. Someone needs access to the staging database? You ping the DBA. Someone hits a weird OAuth error? You've seen it before, so you lean over and type the answer.
It feels like service. It feels like leadership. It's the fastest way I know to build a team who stops moving the moment you leave the room.
The Splinter and the First Aid Kit
Claude Silver is Chief Heart Officer at VaynerX. When she joined Debra and me on Corey-osity Unleashed (S1E9), she talked about leading the generation coming into work now. She wanted to support them without coddling them and without creating entitlement. Then she gave the cleanest description of good support I've heard.
If they have a splinter, she said, it's "rather than taking the splinter out for them, showing them where the first aid kit is."
She went on to talk about empowering people instead of doing things for them. And about how VaynerX moved away from handing out fourth and fifth place trophies, toward a culture of accountability, feedback and performance. Support plus expectations. Both at once.
I've been chewing on the splinter line for months, because I've played the splinter remover more often than I'd like to admit. Tweezers out, hand outstretched, before anyone asked. I thought it made me a good manager.
It made me a bottleneck.
Your Help Desk Has a Queue
Here's what happens when the manager becomes the first aid kit.
Every blocker routes through you. You're in meetings half the day, so the queue builds. People wait. Some wait politely. Some give up and start something else. Some work around the problem and leave a mess for later.
The Stack Overflow 2024 Developer Survey put numbers on this. 53% of developers agree waiting on answers to questions often interrupts and disrupts their workflow. 61% spend more than 30 minutes a day searching for answers or solutions.
Then look at this one. Among people managers in the survey, 57% agree they often find themselves answering questions they've already answered before. Across all respondents the figure is 49%.
Read it again if you manage engineers. Over half of managers say they keep answering the same questions.
A repeat question is a splinter you pulled out last month. You fixed the symptom and kept the knowledge in your head. So the next person with the same splinter walks back to your desk. And the person from last month? They didn't learn where the kit lives either. They learned where you sit.
I wrote before about your best engineer becoming a single point of failure. The blocker-removing manager is the same problem one level up. You built key-person risk, and the key person is you.
Struggle First, Teach Second
The rescuing instinct comes from a decent place. Watching someone struggle is uncomfortable. Struggle looks like waste.
The research on learning says otherwise, with one important condition.
In 2021, Tanmay Sinha and Manu Kapur published a meta-analysis in the Review of Educational Research. They pulled together 53 studies with 166 comparisons. The question was simple. When learning something new, is it better to get instruction first and then solve problems, or to try solving problems first and get instruction afterwards?
Problem solving first won. The effect was moderate (Hedges' g of 0.36), and stronger when the design followed the principles of what Kapur calls Productive Failure.
Notice what the study does NOT say. It doesn't say "leave people alone and let them flounder." In every one of those designs, instruction still came. It came after the attempt. The struggle made the teaching land.
The study also found exceptions. For the youngest learners and for general, domain-wide skills, instruction first came out ahead.
I'm not sure about this part: Sinha and Kapur studied students in classrooms, not engineers in production systems. I couldn't find a study testing struggle-first against answer-first for working developers. My read is the pattern carries over to debugging, but treat this as my judgement, not proven fact.
Here's how it maps to your team. When you pull the splinter, you skip the attempt. The person never builds the mental model. When you point at the kit and debrief afterwards, you get both halves: their attempt, then your teaching.
Not Every Blocker Is a Splinter
I'm not arguing you stop removing impediments. Some blockers are not splinters. They need you.
Here's the line I'd draw. Ask one question about the blocker:
Is this person missing authority, or missing knowledge?
- Missing authority means you remove it. Another team won't prioritise the API change. Procurement is sitting on a licence. A director keeps adding scope. Your engineer has no lever to pull. You do. Pull it.
- Missing knowledge means you show them the kit. How the deploy pipeline works. Where the feature flags live. Why the build server behaves differently from their laptop. If you hand over the answer, you'll be handing it over again next month.
The Scrum Guide wording supports this, by the way. "Causing the removal" is not "personally removing." Causing removal includes teaching the team to remove it themselves.
Production fires are the obvious exception. When customers are down, nobody needs a teaching moment. Fix it, then run the lesson afterwards.
What Goes in the First Aid Kit
A first aid kit is useless if nobody knows where it lives, or it's empty. Here's what I'd put in yours.
1. Write it down the second time
The first time someone asks a question, answer it. The second time anyone asks the same question, the answer goes into a runbook, a README or the team wiki before you reply. Then reply with the link. The Stack Overflow numbers say most managers skip this step.
2. Ask what they tried first
Before you offer a single suggestion, ask what they've already tried. It credits their effort and shows you where their model of the system broke. Often the gap is one fact, not the whole solution.
3. Point, don't fix
Give the smallest hint which unblocks them. "Check the logs on the build agent, not your local ones." Then walk away. Resist the urge to drive their keyboard.
4. Agree on a struggle budget
Productive struggle has a limit. After a while, it becomes plain waste. Agree a timebox with your team for when to ask. Pick a number which fits your work and stick to it. The point is to protect both the learning and the deadline.
5. Debrief after the fix
This is the half most managers forget. Once they've solved it, spend five minutes on what they learned and what they'd check first next time. Without this step, you're leaving people alone, not teaching them.
6. Give the team a playbook
Common failure modes, how to diagnose them, who owns what. Engineers shouldn't need to find you to find out who runs the auth service.
This Is Not a Gen Z Problem
Claude framed her point around Gen Z, and I understand why. She's leading people on their first, second and third jobs.
I don't think the splinter is a generational issue. Put a senior engineer with twenty years' experience under a manager who always unblocks them, and they'll learn to wait too. Dependency isn't a personality trait. It's a habit we train into teams, one rescue at a time.
The bad boss Debra and I call the Micromanager rarely thinks of themselves as controlling. They think of themselves as helpful. In our research, 99.5% of people said they'd had one or more types of bad boss, and 80% said they'd had a Micromanager. I doubt many of those bosses woke up planning to smother anyone. A lot of them were pulling out splinters.
I wrote about how micromanagement and coaching pull in opposite directions. The splinter remover sits right on the boundary. It looks like coaching. It works like micromanagement.
Count Your Splinters This Week
Try this for five working days. Keep a tally on a sticky note. Every time someone brings you a blocker, mark it as authority or knowledge. Every time you answer a question for the second time, circle it.
At the end of the week, look at the circles. Each one is a missing page in your team's first aid kit. Write those pages next week.
Then ask yourself the uncomfortable question. If you went on holiday for two weeks with no laptop, which of your team's splinters would still be stuck in their hands when you got back?
If you'd like help building this into how your managers lead, take a look at our leadership workshops at Step It Up HR.