An employee asked their boss for an oven. Nothing fancy. Somewhere to heat up lunch.

The boss drove to Walmart, paid $40, and put it in the break room. No budget meeting. No business case. No "let me take this to the leadership team."

The employee's reaction? "He listened? No one's ever listened to me."

James Ferguson told me this story when he came on Corey-osity Unleashed. James coaches leaders on culture, and he calls this move "solve small things fast." I haven't stopped thinking about it since, because I've watched engineering leaders do the exact opposite for years.

A small countertop oven in an office break room with a handwritten thanks note stuck to the door

Forty Dollars Bought Something No Programme Buys

Look at what the employee said. They didn't say "great oven." They said nobody had ever listened to them before.

The oven was the receipt. The listening was the product.

Most companies run this backwards. They spend six figures on an engagement platform, run a quarterly pulse survey, hold a town hall about "employee voice"... and then leave the broken coffee machine broken for eight months. People notice. They notice the small stuff first, because they live with it every day.

Salesforce Research found an employee who feels heard is 4.6 times more likely to feel empowered to do their best work. Feeling heard doesn't come from a survey. It comes from saying something and watching it change.

Your Engineers Have Their Own Broken Oven

In software teams, the $40 oven has a name. We call them paper cuts.

A flaky test nobody owns. A build which takes eleven minutes when it ought to take two. A staging environment which falls over every Tuesday. The one config file three people need to edit by hand for every release. None of these would ever make the roadmap. All of them drain your team a little every single day.

Atlassian's 2024 State of Developer Experience report, built with DX and Wakefield Research from over 2,100 developers and managers, found 69% of developers lose eight hours or more a week to inefficiencies. A full working day, every week, gone.

The number I find worse: less than half of developers believe their leaders know about it. And two out of three developers consider leaving when their developer experience is poor.

So your people are bleeding a day a week, they don't think you've noticed, and they're eyeing the door. None of it shows up in your sprint review.

A kanban board dominated by one big project card while dozens of small sticky notes about everyday annoyances pile up underneath

GitHub and Stripe Proved Small Fixes Pay

Some companies worked this out and built teams around it.

In 2018 GitHub launched Project Paper Cuts, aimed at what it called "usability nitpicks" ... the small daily frustrations sitting outside its bigger product initiatives. In the first month the team shipped ten fixes. Tiny ones. Diff markers you no longer copy by accident. A button to copy a comment's link. Branch names in merge emails.

Nobody writes a press release about a copy button. Developers loved it anyway, because it told them GitHub was paying attention to the stuff they swore at every day.

Stripe went further. When Rebecca Murphey ran engineering effectiveness there, her team put "bad day" buttons inside internal tools so engineers logged a paper cut the moment it bit them. According to Swarmia's write-up of her work, the programme pulled in over 1,000 tickets, and plenty of them pointed at problems the tool owners had never spotted.

Her team's starting assumption stuck with me: they treated developers as grown-ups who wanted to do the right thing. Not as slackers making excuses. Trust went in first. Trust came back.

Listening Without Action Teaches People to Stop Talking

Here's the part leaders miss. Asking for feedback and doing nothing is worse than never asking.

Gallup's research on survey follow-through shows workgroups in the top quartile on action planning raised engagement by an average of 10%. Workgroups in the bottom quartile saw engagement fall by 3%. Gallup puts it bluntly: "Employees doubt the motives of managers who ask for their opinions, then don't do anything with them."

Read it again. Ignoring feedback doesn't leave you where you started. It moves you backwards.

My research found 99.5% of people have had one or more types of bad boss. I'd bet a big share of those stories include a manager who asked "what's getting in your way?" and then did nothing with the answer. After the second or third time, your team stops telling you things. And a silent team is the most dangerous team you'll ever lead, because the problems don't go away. You stop hearing about them.

I noticed a thread trending on Reddit this week, the day's top post by a wide margin, full of people describing a company which refused a small raise for a star employee and then spent far more replacing them. Same pattern, bigger price tag. The small yes was cheap. The big no cost a fortune.

Why Leaders Sit on Small Fixes

If small fixes are this cheap, why don't more leaders make them?

They think small problems are beneath them. Leaders like big problems. Strategy. Architecture. Reorgs. Fixing a flaky test feels like a junior's job. Your team doesn't see it this way. They see a leader who won't spend ten minutes on the thing ruining their afternoon.

They route everything through process. A $40 oven turns into a procurement ticket, which turns into a facilities request, which turns into silence. Process protects you from big mistakes. It also kills small wins.

They wait for the complete solution. "We'll fix the build properly when we migrate to the new CI system." Next year. Perhaps. Meanwhile, your team waits eleven minutes, forty times a day.

They don't know. Remember the Atlassian number. Most developers don't believe their leaders know what's slowing them down. If nobody tells you, you have a listening problem before you have a paper cut problem.

A team lead in a hoodie kneels to tighten a wobbly desk leg while a developer looks on pleased

How to Run Your Own $40 Oven Programme

You don't need a new team or a new tool. You need a habit.

Ask one small question every week

In your one-to-ones, ask: "What annoyed you this week?" Not "what's blocking you." Blockers sound serious, so people save them for serious things. Annoyances are where paper cuts live.

Set a dollar and time limit for "fix it now"

Give yourself, and your team leads, a standing budget. Anything under $100 or half a day of effort gets fixed without a meeting. Tell the team this rule exists. The rule itself is a signal.

Close the loop out loud

When you fix something, say so. "You mentioned the staging deploy kept timing out. Priya fixed it Tuesday." This is the part the oven story gets right. The employee knew exactly who listened and what changed.

Protect a slice of every sprint

Keep a small, fixed chunk of each sprint for paper cuts. Let the team choose which ones. GitHub shipped ten fixes in a month with a dedicated team. You don't need ten. You need one or two, every sprint, visible to everyone.

Track the small stuff like the big stuff

Keep a running list of paper cuts raised and fixed. After three months, you'll have a record of trust earned in public. When the next pulse survey lands, your team will remember the list, not the slogan.

Trust Is Built Small

Big programmes feel like leadership. Small fixes feel like housekeeping. Your team sees it the other way round.

Every small thing you fix fast tells someone: I heard you, you matter, and I'll act. Every small thing you leave broken tells them the opposite, louder than any town hall.

So here's my question for you. What's the $40 oven on your team right now... and what's stopping you from buying it today?