It Depends: 7 viral Engineering Management dilemmas

That got >2M views and heated debates on LinkedIn

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):

1. Remote work problems

2. Too-involved developers

3. Finishing sprints early

4. Constantly late developers

5. Hiring juniors vs seniors

6. Developers talking shit about your own manager

7. 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:

1. Give them another ticket

2. Let them chill or explore

3. 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.

Matt Watson

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.

Itzy Sabo

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:

1. Do everything you can to listen. There’s usually truth in the complaints.

2. Try to fix 1–2 big issues together with them. Show you care and want change.

3. Talk about the behavior. What’s okay, what’s not, and how to raise issues.

4. 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:

1. 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)

2. Your team is chatting in the team chat, and one person makes a homophobic remark. The conversation stops. What do you do? (link)

3. One of your engineers tells you they signed with another company, and will leave in 30 days. What do you do? (link)

4. One of your developers leaves the office early, saying: "I'll continue from home." What do you do? (link)

5. A critical deadline arrives in a week and you figure out that your team won't make it. What do you do? (link)

6. 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

Work Chronicles

!

Source: the great Work Chronicles newsletter

What I enjoyed reading this week

1. The future of full-time employment is changing by

   Elena Verna
   . Loved the concept of ‘career optionality’!

2. 43 things we've learned about hiring at PostHog by

   Charles Cook
   .

3. Gravity Maps: An Alternative to Org Charts by

   Benedikt Kantus
   .

4. 7 Phrases I use to make giving feedback easier for myself by

   Wes Kao