r/EngineeringManagers

Mid-level SE here looking for some candid perspective.

We often talk about technical output, but as EMs, what made a specific team member stand out and become someone you truly loved having on your team as a whole person?

* What specific qualities, attitudes or interpersonal habits made you favor working with someone over others? (e.g., how they communicate, handle pressure, support others, or take ownership)

* What non-technical habits or behaviors did the opposite and made someone difficult to work with?

* What advice would you give a mid-level engineer on building that kind of trust and rapport while stepping up to the next level?

Would love to hear honest stories or specific moments that shaped your view!

Thanks in advance!!

Small-team question. When most of the code was written by humans, review capacity roughly kept pace with output. Now one engineer with agents can open far more PRs than the senior reviewers can get through.

What I'm curious about:

- Did you change the review process on purpose, or did it break first and then you fixed it?

- Did you hire, reassign someone to review full-time, buy a tool, or build something?

- If you bought an AI review tool, was it worth it? I've heard "worthless" about one and "too expensive per PR" about another.

I've been building something for my own team and I'm trying to learn how others handled it before going further.

I’ve been doing the EM role for a long time and I’ve experienced a lot of situations, related to impostor syndrome, being too busy etc..

I never thought about any limiting beliefs until I was asked about by my coach.

I couldn’t give an answer and I’m still struggling about it. What’s your take on that?

Hey guys! I work at a small to medium sized firm. We have a couple repositories that are being merged to by multiple teams. Now these teams are all working in different development cycles. Often times, when one team is done with a feature and wants to release their changes, another team inevitably has changes in staging that are still in-progress. We’ve mostly managed to handle this through feature flagging but it’s not perfect and we sometimes have situations where people have to revert changes or we have to delay a release. How are you all handling this? Super-strict on the feature flagging? Feature branches? Scheduled releases? I’d love to hear what other companies are doing.

Some background: I spent years in QA and later worked as a Scrum Master, so I usually see code review from the "why is this ticket still not testable" side.

One pattern I keep running into: an MR rarely fails loudly. Nobody rejects it, nobody argues. It just sits there. The author has moved on to the next ticket, the reviewer opened it once and left a comment, then sprint planning happened. Two weeks later it has merge conflicts and nobody remembers the context.

Our board never showed this. The Jira ticket said "In Review", which looked perfectly fine.

So I'm curious how other teams catch this early:

- Do you track how long MRs stay open, or only cycle time after the fact?

- Is noticing someone's job (EM, tech lead, SM), or is it on the author?

- Do you have a rule of thumb for "this has been open too long"? Two days? A week?

Genuinely interested in what worked for you, and what didn't.

[removed]

[removed]

[removed]