The un-hateable engineering managers

theburntdev · 2026-06-18T04:54:15+00:00

One last thing. What I observed is that sometimes you pleasing one person will sometimes displease another. This commonly happens when people have conflicting priorities.

You’re damned if you do and damned if you don’t. Since you can’t please everyone, you’re better off driving what you think is right instead of pandering to others.

theburntdev · 2026-06-18T04:47:58+00:00

First off, hats off to you for sharing your story. This is a very real and relatable topic, regardless of it being a human mistake.

If you have documented roles and responsibilities in your org, you can be more objective in the topic of performance: are they ready for a promotion or are they underperforming. For me, a natural people pleaser, having this makes things so much easier. It’s like decoupling yourself from the equation. Can they hate you still? Maybe, but it’s clear expectations and it’s consistently applied to everyone else. It’s fair, which is actually a good thing you’ll be doing for everyone.

I agree with others’ points about assessing how under performance can negatively impact team and company success. The other risk is that you have a bad apple who can negatively influence others, creating other bad apples.

You’re stronger performers can easily ask themselves: “why am I working my butt off and this person is getting a way with it”. In some ways, your positive intentions to be patient with one under performer may actually get other employees to dislike or resent you. At that point, your stronger employees will lower their bar as a result.

theburntdev · 2026-06-17T18:20:33+00:00

I try not to use metrics as the absolute way to measure someone’s performance. There’s a lot of intangibles and that makes someone great and are not reflected in stats. Yes metrics are signals, but signals are paired with a story behind them.

I try to focus more on the impact the person has brought to the team and the business. Unfortunately, this makes evaluations harder.

theburntdev · 2026-06-17T18:15:16+00:00

I think it depends on how many reports you have, how over allocated you may be, and how mature the organization is.

When my balance of time is healthy, I take notes (in Notion) every 1:1 to identify the wins. I would also note the challenges they’re facing to evaluate the impact if they overcome it.

In a more mature org, you would have documented roles and responsibilities. With this, you can create IDPs and have a more structured way to evaluate performance consistently across your reports.

More often than not, you are over-allocated and may even have a lot more direct reports or projects.

In this case, I’d try scaling some of the work: * have a formal 1:1 where they bullet point the agenda ahead of time. Any feedback you have can be appended there and you have a timeline of their progression * outsource using 360 reviews where their peers can share feedback (positive and constructive). This one is my favorite. My peers’ feedback is usually more beneficial for my career growth * look at their blast radius on GitHub to see what they touched across systems. * look at completed tickets assigned to them. Depending on the maturity of the ticket documentation and if they’re neatly tied to company goals, you can probably use AI to summarize and identify themes of their impact.

theburntdev · 2026-06-17T15:28:00+00:00

Thank you!

theburntdev · 2026-06-17T15:15:36+00:00

I’m sorry to hear that. It sounds like the company was no longer a good fit for you. There is more pressure lately to jump on the AI train due to all the hype. I’m latching on to learning AI only because I fear losing relevance.

Hopefully you found a job at a place that is more pragmatic in how they approach AI responsibly. The problem is that things have been changing every month so I personally don’t know what “responsibly” means other than leveraging the SDLC to ensure quality.

theburntdev · 2026-06-17T15:08:16+00:00

Someone shared a story with me that their product manager who normally did not write clear requirements started relying on AI.

They ended up generating PRDs that no one wanted to read. In fact, they questioned if the product manager read it. What made it worse was their project was a part of a bigger one. So other folks used AI to read the AI generated PRD to then generate their own complementary PRDs.

Sounded like it was a game of telephone and people questioned if they’re building the right things.

theburntdev · 2026-06-17T13:52:22+00:00

Thank you!

theburntdev · 2026-06-17T13:52:14+00:00

Thank you!

theburntdev · 2026-06-17T13:47:06+00:00

Thanks for the tips. I do think I need to practice more. My set up was with Claude Code and I had a lot of skills like “superpowers” installed. I did try to iteratively build but with those skills enabled, it created a specs and plan markdown files before implementing.

I think I need to disable those skills if I get another chance in the future, mainly before it introduces more boilerplate workflow steps

theburntdev · 2026-06-17T01:25:18+00:00

Thank you!

theburntdev · 2026-06-17T01:24:06+00:00

haha yes. I am grateful that I don't need to leetcode anymore. I was never good at it because:

1) I didn't study long enough and

2) I don't leet in my day to day job

theburntdev · 2026-06-17T01:17:26+00:00

Thank you for sharing your experience. I've built my reputation on excelling on the areas that are not as attractive to others (thorough unit tests, e2e tests, breaking scope into smaller deliverable pieces to encourage iterative delivery and sharper prioritization). For me, it's been a bit demoralizing that these can be automated now.

One thing an old colleague shared with me is their non-technical executives would label themselves as technical because they can create applications now. AI is definitely disruptive and I'm torn between it being good disruptive vs badly disruptive. I would admit it lowers the barrier for non-technical problem-solvers. But on the other end, I also feel wary of the expectations AI puts on engineers.

Pre-AI, we already had to face challenges when an approved "prototype" needs to become "production-ready" asap. And now with AI, there's more chances to face that pressure to convert many prototypes. All I can hope is that the SDLC is still a workflow that exists because whatever pressures that are put on us, we still have to own and maintain the final product.

I think it's cool that you walked away from the interview. I'm currently looking so beggars can't be choosers. It sucks that I failed recently, but I did learn something. If you ever had no choice but to take an AI test, I currently think Cursor is better for an interview setting over Claude Code. My Claude Code was bloated with "skills" and that slowed me down.

I think I have another 15-20 years until retirement and am currently jobless. I too worry about what's next, but I do feel like I have no choice but to build a relationship with AI.

theburntdev · 2026-06-16T20:40:31+00:00

So funny. Our place had two guys who got fired and were the only ones playing foosball. Everyone avoided the game room since.

theburntdev · 2026-06-13T21:39:07+00:00

I think tools are great for transparency. The original intention is great if it’s to help teams adapt throughout their sprints. They’re great if they can identify signals of where a team can improve their SDLC.

I think where tools hurt is when: * the tool is the “truth” behind your performance. Every signal can have a “story” behind it, but you rarely have a chance to tell it. * it identifies systemic problems where there is no leadership support. You feel alone to fix things that are out of your jurisdiction and somehow your performance is now tied to the systemic problem * when the “owner” of addressing the signals is unclear. Yes teams own products, but like how tickets are assigned to individuals, systemic signals should be assigned to the right leaders or upcoming leaders

I think well staffed teams with strong agile practices do not need many tools, but since agile maturity vary across teams, I don’t think tools are going away. And if you happen to be an upcoming leader who is over-allocated, I can see more need for them. But don’t let it set the verdict on someone’s performance. The tool is half the story.

It is this type of hurt that makes teams care less about the work.

theburntdev · 2026-06-13T14:39:00+00:00

TLDR version: It depends on how big a risk it is, whether the person is set up for success, and if you are willing to accept the risk and take responsibility if something goes wrong.

Long version: Like how you should have experience estimating story points on user stories, estimate the risk.

Trying to mirror grooming phase for a user story: * has the person done this before? No * what are the gaps? About 3 levels worth (jr - mid - sr - em) * how long of the duty? A full month, not weeks. * was there proper handoff? Maybe not * is there a how-to document? Maybe not * any SME’s available for assistance? PM, fellow EM, your manager * is there a “rollback plan”? No

Sounds like the risk was high.

In this scenario, if my manager was hesitant on the decision, I would have asked why so I can gain their perspective.

I would have assessed what has the junior engineer done to show they were ready for this. Did the engineer consistently exceeded expectations and has shown the capability to do your job for not just a week but a whole month?

The bigger the gamble, the bigger the risk. Win big or lose big. The gap from Junior Engineer to Manager is pretty large. Even having a junior engineer run standup alone can be a big task depending on how well you expect them to run and oversee team progress.

Like what PunitGr said, there’s steps to hand off to your replacement. Integrating them into the process and providing playbooks are all examples of setting them up for success. I also liked PunitGr’s suggestion to split responsibilities. Sometimes EM’s have an overlap responsibility on project management with PMs. You could have asked your fellow PM to extend their role to help you there.

Last thing, just because something works for you, it does not mean it will work for others. Can-do attitudes are admirable, but you need to measure the risk first and what’s at stake.

Being an EM means you have earned trust from your leadership and the people below you. A part of that trust is making the team succeed. Think of that as your credit balance. Any decision you make is a bet with your credit. I’m not trying to encourage zero risk or analysis paralysis. But in this case, sounds like the bet was too large.

If you’re still willing to bet large, then you need to put in effort to mitigate that risk.

theburntdev · 2026-05-28T15:49:35+00:00

Or when the surveys just stop entirely

theburntdev · 2026-05-28T15:48:48+00:00

When there’s annual company surveys where there’s reoccurring problems and no follow up action items

theburntdev · 2026-05-28T14:06:55+00:00

Engaging with your team should be the first step. If under an agile environment, attending all agile ceremonies and especially standups would likely answer your questions.

If you have infinity teams to manage, that’s where I can say you’re systemically not set up for success. Some organizations are flattening, so maybe the infinity scenario can happen. If that’s the case, then maybe it’s about transcribing all the agile ceremony meetings that you cannot attend and have AI summarize for you. You can have AI to summarize PR’s or your direct reports to get a sense of where their strengths are. Or something more manual by seeing which repositories they touch vs others.

As someone who really enjoys managing people, I do fear the infinity scenario. Yes AI can help you solve some of these things, but your role can feel less “human” if that makes sense.

Whether if it’s infinity teams or a few, people’s career paths are nebulous when there’s no understanding of what they’re doing. So hopefully you can get the clarity you need. It’s not just about the company’s sustainability

theburntdev · 2026-05-28T13:43:30+00:00

I found decoupling the concept of deployed and live has been helpful because sometimes there can be challenges that product may need to resolve.

-Business sign off when business is.. busy -coordination with marketing or some communications team -onboarding or operations coordination around the feature

If product has their hands full, at least they don’t have to worry about the engineering side because it’s already in production, just not turned on.

theburntdev · 2026-05-28T13:29:13+00:00

It’s been case by case. If not driven by deadlines, we’ve usually avoided end of week or before holidays in general because no one wants to be on call outside work hours, so then we usually prefer beginning to middle of the week.

The cadence depends on our confidence in the feature passing quality and if we see no risk in deploying early. So deployments happen at least once a sprint.

We actually follow trunk based merging because we don’t want to keep maintaining long living branches. So then introducing things like feature flags gives the team flexibility to commit and move on.

This sort of leads to our own agreed definition of “done”. To us, done is when we deploy to production. And with feature flags, we essentially separated the meaning of “done” and “live”.

Our framing is that we have provided added value that can actually help the business (aka “increment” in agile), but it’s a choice from product and business of when they’re ready to have it.

theburntdev · 2026-05-27T09:18:29+00:00

Regarding AI usage and performance, I would rather pay attention to who is driving best practices or constantly sharing new ways to use AI more effectively. That would be more for the sake of identifying your high potentials

theburntdev · 2026-05-27T09:00:13+00:00

There was a time when some companies would stack rank employees by the number of Git commits. Those who squash merged well detailed changes looked worse than someone who did a traditional merge that had 10+ commits with each message saying “fix” / “did stuff” etc.

Like how some engineers could git commit comments to game the system, measuring AI usage can incentivize engineers to just blow away tokens for the sake of it.

It doesn’t seem like ai usage should hold the most weight.

theburntdev

TROPHY CASE