r/EngineeringManagers

So I finished writing reviews and the whole thing felt kind of off. For each person I'm basically trying to reconstruct six months from half-memory. For me that tends to be a couple screenshots, some PRs, and whatever I happened to write down at the time. Which isn't much. Recency bias is also really brutal.. someone who had a rough couple weeks in March but a solid year otherwise just doesn't come out right.

I dont think I can just chalk it up to being disorganized. I know the answer is supposed to be "keep notes," and I sort of do, a doc per report. But with all the other stuff going on it's kind of wildly inconsistent. It always feels like I'm either slacking on it or building a creepy dossier on my own team. Memory is not a system, I guess.

How do those of you with more than a handful of reports actually do this? without it turning into surveillance? Or if you've tried a lot of things, whatever has genuinely stuck for you, vs the stuff you set up once and never used again?

Smallish company, promoted from IC to leadership. I built a small team to improve our throughput. The daily reports from our team have lead the c suite to believe that we were being very productive, but one of them began watching over my team's shoulder, scrutinizing what they do every minute of the day. They've been making heavy use of AI, and I'm getting negative feedback from the team having downtime. I don't think this would've ever been an issue without AI, as they can fire away with minimal work on their end.

They're each tackling 1-2 somewhat moderately scoped tickets a day, and we're starting to drown from code review. Some of these tickets are taking like, 3-5 iterations to get right, and I'm concerned that handing them more complexity will result in total code review hell.

Is it normal to be scrutinized in this way? Other departments (such as support, QA, etc) would be happy to see their tickets turning over. It almost feels like they expect the engineers to be typing 24/7 and are missing the forest for the trees.

Maybe this is normal and the c suite pressuring engineering to be faster, cheaper and more productive is a tale as old as time?

Should I be keeping metrics to defend my team?

A useful engineering metric should help a team make a decision. An activity metric usually just makes work look measurable.

Commits, pull requests, tickets closed, review comments, and hours logged can describe activity. They cannot tell you whether the team reduced risk, improved delivery, clarified ownership, or built the right thing. Once these signals become targets, people naturally adapt their behavior to the dashboard.

I find it more useful to separate metrics into three layers:

Activity: What work happened?

Flow: How smoothly did work move through the system?

Outcome: What changed for customers, the product, or operational risk?

Activity can still be useful for diagnosis. A sudden change may reveal a blocked workflow, overloaded reviewers, or fragmented work. The mistake is treating activity as a proxy for individual performance or business impact.

For SaaS leaders, the practical test is simple: what decision would change if this metric moved? If nobody can name the decision, the metric may be reporting theater. If the answer is “we would ask better questions,” it may be a useful diagnostic. If the answer is “we would rank engineers,” it deserves much more scrutiny.

The hard part is that outcome metrics often move slowly and have many owners, while activity metrics are immediate and easy to collect. How have you designed engineering reporting that remains useful to leadership without turning observable activity into a performance score?

Not sure if other EMs have noticed this but a lot of engineers angle for management for reasons that have almost nothing to do with management and it worries me.

Most treat it as the obvious next rung. You've maxed out the visible IC ladder and management just seems like where you're supposed to go, so you chase it as a promotion, a status bump, a pay increase, without asking whether you actually want to do the thing itself.

Because a lot of folks picture management as senior engineering with authority. The reality is close to the opposite. You mostly stop coding. Your wins go invisible, a well-run team just looks like nothing went wrong. And you become the person who absorbs everyone else's problems: performance issues, conflict, burnout, the brilliant person who's quietly about to quit, roadmap chaos from above, usually with less authority than you imagined. It's a people job in an engineering context, not an engineering job with a bigger title. Plenty of great engineers try it and hate it and that's fine, it's just a different discipline.

What makes me skeptical is when someone wants in purely because the IC track stalled or the money's better, with no real interest in developing people. If someone got more satisfaction from unblocking their team than from their own commits, I'd take that seriously. I've gone as far as I can as an IC so I guess I'll manage is a different thing and a lot of people learn that the hard way, then feel trapped because stepping back feels like a demotion.

So where do other EMs land? Are you seeing this too?

I've been an EM for almost six years now and lately I've been thinking about going back to being an IC. Partly bc the market, but also bc I just miss building stuff. But when I actually sat down to figure out how I'd present myself for that, I realised that this is actually not as simple. As an IC back then I had a commit history, projects, stuff I could point at. As an EM I've got… what? "Teams I ran went well, nothing broke, trust me."

Someone on here some time ago described EMs as having "weak external signals"; your impact ends up living in your old manager's memory. There is barely any relevant artefacts and basically no portable proof.

So for anyone who's gone back and forth, or who hires EMs: what actually counts as proof you were good at this? Is there stuff people do while they're still in the role to leave some kind of trail or just something to show for in general? Right now I am starting to suspect there just isn't, and it's a remember-and-retell thing you redo every time you change jobs. However I would love to be wrong on that.

I work in a bigger tech company, and my new manager who is ex-Amazon asked me to mentor a mid-level engineer (I'm more senior) who is underperforming - I don’t know if the engineer is on PIP but my manager has started a confidential doc of expectations. I can (selfishly) view this 2 ways:

1. Manager trusts me to help the engineer
2. Manager is deliberately putting me in a tough position. This isn't mentoring someone to promotion; this is mentoring someone out of underperforming. If the mentee fails, will this look bad on me?

Would you seriously consider just saying “no” to mentoring?

I haven't established a trust yet with my new manager, and honestly have some doubts - but wanted to get community thoughts. Thank you!

If someone is working full time while going to school, and they have two Master Degrees in Engineering, and they want to pivot into engineering management, should they also get an MBA? What's your thoughts on someone having three master degrees (two in engineering, and one MBA)?

Yeah it sounds pretty bad. At least that is certainly the stance I would have taken back when I was a developer.

Recently I made a script that aggregates my engineers’ git activity (Commits, MRs, MR comments), Jira activity (story pints delivered, comments, tickets updated, created) and confluence (documentation activity). I don’t give this metric much weight, nor bring it up at all with most engineers, but I do use it to spot outliers.

It feels yucky and almost like a breach of trust.

Story points, at best, are a rough estimate of work delivered but more often than not are loose guesses without nuance. Git activity comes and goes (when planning projects or doing some research for example).

Nonetheless, trust but verify, right?
I have roughly 20 engineers reporting to me, with no leads in between them and myself as the manager. Our POs in the teams are pretty young and not too experienced - so I can’t lean on them too much either.

I found clear outliers in the metrics and am now doubting if these individuals are pulling their weight. We are talking about individuals with one commit in an entire month (and they gave a 1 hour workshop during that time but still..)

Am I uncovering people who have just silently quit? How does the community feel about looking at these simple activity metrics as a baseline indication?

To me it still feels like bad micro management - but what if it does show “top” engineers measurably.. not doing anything at all..

I'm 32 and just got fired from my first management position at an agency after 2 months. Before this position, I ran my own tech business for a couple of years and mostly worked as an IC.

The frustrating part is that the team was delivering results. The client was also very happy. The project I inherited mid-flight was already in rough shape when I joined, and I had to push a lot of decisions get things back on track because we needed to be functional for a couple of important events that served as our deadlines.

I cared a lot. Even though it was only a 10-week gig, I was doing 12+ hour days to get the product in order, aligning the engineering team and the client across two time zones, and handling everything else that came with it.

I was also dealing with a difficult high performer lead who was openly rude and a couple low performer team members who complained constantly for no good reason, and I think I let that affect the way I managed everyone else.

In the end, they banded together and complained to the COO, who decided to knowingly dump a negative feedback bomb on me two days before my wedding, when I was already very busy preparing us for launch.

I didn't take it well. I pushed back hard. What was supposed to be a 30-minute feedback meeting turned into a 2-hour rant from me, and afterward I even sent him an A4-page rant explaining my side of everything. I guess that was the final nail in my coffin.

That said, I do agree with some of the criticism. I was probably too hard on people. I'm not here to argue that I was treated unfairly. I can see my mistakes.

But I've been replaying this over and over in my head all week, despite having a conversation with the CEO during my exit interview. He told me I did 90% of things well and mainly needed to improve the way I give and receive feedback. He even laughed about me clashing with the COO and joked that we should probably "clean our chakras" together.

It hurts a lot because I cared so much and even when deciding to go i to PM i thought Im gonna be better than my past managers, but no work life balance and stress got to me. I also feel stupid because it was a very well paid gig but I let my principles to get in a way. I keep wondering whether I'm just not cut out for management or whether this is simply one of those painful lessons that many first-time managers go through.

I'd appreciate any seasoned manager or even some mature fatherly advice at this point.

Got a call from recruiter.
Any tips on how to prepare and what to expect. I am pretty hands-on but interviews are not purely about being hands-on, but also the format.

Any advice/experience on how to prepare for apple engineering manager interview. Specially for coding and system design (first thing first).

Checked online but it seems inconsistent across teams. So thought to check key areas apple generally ask to EM candidates.

I'm doing my B. Tech in AIML background , one thing i know in these 4 years that i don't want to do core coding like Software Engineer. I want to implement it in the real world, so do you what do you think, should i do Msc in Engineering Management for my career transition ? is is a good career option ?

I talked with a friend I highly respect today and discovered he's FULLY IN on agentic coding. Doesn't read ANY of the code; agents write and review everything and have access to everything so that they can write better code. It's as if code is a lower level thing that doesn't need to be checked as long as we check the higher level is working.

My experience so far with agents is: they are very helpful, but produce awful unmaintainable code. If left to roam free, you'll get code filled with bugs and that is very expensive to fix because nobody can understand. My friend said that the agents can fix the bugs that eventually come up.

If I'm being honest I haven't done any actual production "vibe coding" myself because I've seen the code that is created with that and it's terrible; but what if that doesn't matter? I agree that code quality for the sake of code quality doesn't matter at all; but we seek "good code" because that is the kind of code we understand and are sure won't break; and also because it's code that is cheap to refactor/evolve/extend/etc. Is "going all in on AI" inevitable?

Idk man... I don't think that's a good strategy, but I'm just wondering if I'm a skeptical living in the past

With AI, how are Engineering Managers dealing with “vibe engineers” in Lead roles?
People who can use AI to build impressive POCs, but don’t understand the complexity of turning them into real production systems.
They agree to aggressive timelines because “AI can build it,” without understanding architecture, scalability, security, testing, reliability, or the engineering effort involved.
At what point does this become a leveling/performance issue rather than an AI adoption issue?
And how do you deal someone being compensated as a Lead when their actual engineering fundamentals may not justify that level? Also, all other team mates over-compensating with leads incompetence.

In my first couple of years as an engineering manager, I took my PM’s word as given. They told me what to do, and I made sure the team did it. Nothing felt weird about it - they know the customers better, they understand the product better, and they have good ideas, right?

It took a few terrible calls by the PMs before I stopped working that way. Once I got into the details, I understood that in many cases product management is broken. So I slowly started to involve myself and my engineers on the product side.

For me, it was about 3 main things:

1. Be much closer to the data and metrics
2. watching user sessions and discovery calls
3. Actually talking with customers

I feel that even though it's not strictly my job, when the PMs are getting 'free rein', bad decisions are made.

I'm really curious if other EMs feel the same, and how did you get involved in those areas.

Hi everyone, I am a 15+ year developer, recently became a team lead/manager, because my previous manager left the company.

Recently I heard feedback (not directly from devs) that I micromanaged, unlike how the previous manager gave them freedom.

Background: I took on people management responsibilities, while continuing to work on high level dev work and guiding/mentoring the devs. I continue to do code reviews. Compare myself to our previous manager, he wasn't a developer, didn't understand the code and didn't do code reviews. In this way he gave freedom to developers to work on tickets. Our team consists of 1 junior, mids and seniors.

Is this an expected behaviour: from a developer to a manager? How much should i 'let go'? How do I communicate my style is different to my preview manager? If I see bad code that will likely cause a production incident, i shouldn't turn a blind eye, because eventually it will damage the dev team?

Thank you