In the last few months, I’ve shared 13 EM dilemmas on LinkedIn. Some of them got lots of interest (and criticism 😅).
Here are the 7 most interesting ones (I shared the other 6 in the end of the article):
Remote work problems
Too-involved developers
Finishing sprints early
Constantly late developers
Hiring juniors vs seniors
Developers talking shit about your own manager
The complaining enginner
The titles are links to the original posts.
1. Remote work problems
You sent a message to one of your remote devs (during working hours), and they answered only 3 hours later. What do you do?
Some say, “Just trust them, as long as they deliver, don’t micromanage.”
But managers know it’s more nuanced. Maybe a teammate is blocked, or you need input for a decision.
On the flip side, expecting 100% availability kills the biggest perk of remote work: flexibility. Picking up your kid, lunch with your partner, or a walk to clear your head.
Here's my answer from my Manager's ReadMe:
"Please, when you are not working for more than an hour during working hours, put ‘out of office’ in your calendar. No need to ask permission or share the reason. Same for 'focus time' - if you want to code without distractions, just put it in the calendar before you start. I’ll know not to bother you.The reason is that sometimes people depend on you, and it’s nicer for everyone to know when a response is expected."Is this micromanagement? Probably, for some people. Still, I believe it's much better to discuss such things openly with your team, instead of being frustrated and afraid of angering them.
Shai Nissim’s answer outlined a great approach:
2. A too-involved developer
You have an engineer who always takes on too many tasks and wants to be involved in everything - and then misses deadlines. What do you do?
Please, whatever you do, DO NOT kill their ambition and curiosity.
These people are internally motivated and love what they do. Their explorations often lead to real wins:
• Huge cost savings• Critical bug discoveries• Innovative ideas
If you push them to “just stick to the plan,” you’ll end up with frustrated, disengaged employees.
Yes, they need to learn their limits.Yes, they should be accountable.Yes, sometimes they need to focus.
Still, I’d work hard to find the right setup - fewer commitments, more space to explore. Talk to them. Explain your concerns. Ask what they think could help.
I’m considering a weekly corner where I’ll share more concrete dilemmas by real EMs, and how they solved them. I would love to know your thoughts (if you really answer ‘it depends’ please elaborate 😂):
3. Finishing a sprint early
One of your developers always finishes the sprint a few days early. What do you do?
Common answers:
Give them another ticket
Let them chill or explore
Ask them to help others
It’s trickier than it seems.
There are two camps:Camp 1 – measure time: “You work X hours, so here’s the next task.”Camp 2 – measure output: “You finished what you committed to? Do what you want now.”
Camp 2 sounds great, but in most companies it’s not realistic.
My take: split the gain.
If someone crushed it and finished early, they earned a break. I might ask them to help or take on something new, but with no pressure to finish it fast.
Even better: let developers be responsible for outcomes, not features - and let them decide themselves.
Nick Melis’s answer was my favorite:
4. A constantly late developer
One of your developers is constantly late to meetings. You've talked to them about it, and it didn't help. What do you do?
Early in my management career, I was super strict about being on time. I took it personally when people were late.
Then I met my wife, who taught me not everyone's brains work the same 😂
Some people are naturally organized. Others are more chaotic. Even with alarms and reminders, they’ll still be late sometimes.
I’ve learned that the fewer things I’m strict about, the easier life is for everyone.
So what if someone is late to the daily standup by 2-3 minutes?
On the other hand, if multiple people are late, it'll waste everyone's time, so it’s a tricky balance.
I loved Vladimir Dvorkin’s take:
5. Hiring - juniors vs seniors
Your team is overloaded with work, and you got permission to hire. You can afford 𝟭 𝘀𝗲𝗻𝗶𝗼𝗿 𝗳𝘂𝗹𝗹-𝘀𝘁𝗮𝗰𝗸 𝗱𝗲𝘃 or 𝟮 𝗷𝘂𝗻𝗶𝗼𝗿 𝗳𝘂𝗹𝗹-𝘀𝘁𝗮𝗰𝗸 𝗱𝗲𝘃𝘀. Which do you choose?
It's an interesting interview question I saw.
There is very limited data here, so of course, there is no right answer. My approach is very junior-oriented, as I have had some great experiences with them.
has a great take on it:
6. Talking shit about your own manager
You hear one of your developers talk shit about your own manager. What do you do?
Let's assume he said: "Bob makes such stupid decisions, he is so out of touch."
Tricky one.
Reprimanding sends a signal, but might also just push these conversations behind your back. Ignoring? Also, not an option. You’re part of the management team.
It depends on the people and context, but no matter what, you need to talk about it in the next 1:1.
Dig into the frustration. Listen.
Then, help bridge the gap. You’re the pipe between dev pain and leadership challenges.
summed it up well:
7. The constant complainer
One of your engineers constantly complains about everything - the PM, the tech debt, the new features, the on-call. You feel it hurts the team. What do you do?
Not mild stuff like “this codebase is hard,” but “our codebase is shit, we must refactor everything,” or “I’m sick of on-call, it’s not my job.”
In my opinion, there are 4 stages:
Do everything you can to listen. There’s usually truth in the complaints.
Try to fix 1–2 big issues together with them. Show you care and want change.
Talk about the behavior. What’s okay, what’s not, and how to raise issues.
If it keeps happening, let them go.
Don’t skip steps. If you jump to stage 3 without truly listening, even if they stop complaining, they’ll stay frustrated.
And if you label them “toxic” too fast, you might lose someone who actually cares.
Fredrik Svaren added nice nuance:
Additional dilemmas
Here are the 6 others:
It's 3 p.m. on a Thursday. A long meeting was suddenly canceled, and you have some free time. What do you do? (link)
Your team is chatting in the team chat, and one person makes a homophobic remark. The conversation stops. What do you do? (link)
One of your engineers tells you they signed with another company, and will leave in 30 days. What do you do? (link)
One of your developers leaves the office early, saying: "I'll continue from home." What do you do? (link)
A critical deadline arrives in a week and you figure out that your team won't make it. What do you do? (link)
You review an engineer's PR and see some terrible code. They admit Cursor wrote it, and they didn't even read it. What do you do? (link)
Weekly comic
Directly relates to dilemma #3 :)
Credit to !
What I enjoyed reading this week
The future of full-time employment is changing by . Loved the concept of ‘career optionality’!
7 Phrases I use to make giving feedback easier for myself by
