Every piece of management advice I’ve read this year says the same thing: be more empathetic. Fine. What none of it tells you is where the line is.
I’ve been finding that line the hard way. I’m a developer who ended up leading a project team, not someone who trained for this, so most of what follows was learned by getting it slightly wrong first.
What empathy is actually for#
Empathy in a leadership role isn’t about being pleasant in meetings. It’s about letting how people actually feel carry real weight when you make decisions, give feedback, or decide how the team works. When people can tell their situation gets factored in, they relax, they speak up earlier, and the work genuinely goes better. That part of the standard advice holds up.
Too little hurts. So does too much.#
The failure everyone warns you about is the cold manager who treats people as resource allocations. That one’s real: ignore what’s going on in someone’s life and they go quiet, morale drops, and you find out about problems months late.
The failure nobody warns you about is the opposite. If you accommodate everything, boundaries blur. Deadlines turn into suggestions. And the people quietly holding the standard start to resent covering for the ones who aren’t held to it. I’ve caught myself over-accommodating because it felt kind in the moment — it wasn’t kind to the rest of the team.
Check-ins do most of the work#
What keeps me somewhere near the right balance isn’t a philosophy. It’s a recurring calendar slot. Regular one-on-ones mean small problems surface while they’re still small, instead of arriving all at once as a resignation letter.
Mine loosely cover the same ground each time: what’s blocking you, what’s gone well lately, how the team is working together, where you want to grow, and what I could be doing differently.
The most useful question I’ve found is a plain one: “Is there anything you need from me or the team to help with your tasks?” It sounds mundane. It isn’t. It signals that I expect to be part of the solution, and the answers are almost always concrete things I can actually fix — access to someone, a decision that’s been floating, an hour of pairing.
Being straight when the answer is no#
Check-ins generate requests, and you can’t grant them all. How you handle the ones you can’t is where trust gets made or lost.
What works for me: take the request seriously and say so, explain why it can’t happen right now, offer whatever partial alternative exists, say when you’ll look at it again — and then actually come back to it, even if the answer hasn’t changed.
None of that makes a “no” fun to deliver. But people handle an honest “no, and here’s why” far better than a vague “we’ll see” that’s never mentioned again.
That’s about as close to a formula as I’ve got: care about how people are doing, be honest about what the work needs, and check in often enough to notice when you’ve drifted too far in either direction.