LinkedIn Post Ideas for Engineering Managers

My best engineer quit. The exit interview rewired how I manage people, and I mean that literally, not as a figure of speech. She told me our one-on-ones had quietly become status meetings — I'd ask what she was working on, she'd tell me, we'd move on. Eighteen months of that, and she'd never once felt asked about her actual career direction. I hadn't noticed, because the meetings felt productive to me. They weren't productive for her, which is the only version of productive that matters in a one-on-one. I now open every one-on-one with a career or growth question first, status updates second if there's time left. Lost one great engineer learning this. Haven't lost another one to the same cause since.

Velocity is a vanity metric. I stopped reporting it to leadership, and here's what I track instead. Cycle time — how long from first commit to production, which actually reflects whether your process has friction. Deploy frequency, which correlates with psychological safety around shipping far better than story points ever did. Interruption load per engineer per week, because a team drowning in context switches will show declining velocity no matter how you game the estimation. Velocity gets gamed the instant it becomes a target — bigger story points, padded estimates, work broken into suspiciously round numbers. Cycle time is much harder to fake, because it's measuring the calendar, not a subjective point value someone assigned. Track what resists gaming. Report that instead.

How I run one-on-ones that my reports stop canceling — which used to happen constantly before I changed the format. No status updates. That information belongs in standup or Slack, not in the one dedicated hour I have with this person each week. A shared running doc, updated by both of us between meetings, so neither of us shows up unprepared or scrambling for an agenda. Every fourth session is explicitly career-only — no current-project talk allowed, just where they want to be in a year and what's in the way of that. Cancellation rate dropped from roughly a third of scheduled meetings to almost none within two months. People don't cancel meetings they actually get value from. That was the whole diagnosis.

We cut meetings 40% for one quarter, as a deliberate experiment. Here's exactly what happened to actual delivery. Before: average 11 hours a week in meetings per engineer, self-reported. After the cut: 6.5 hours. We killed a recurring status sync that had become theater, merged two overlapping planning meetings into one, and made a hard rule that any meeting without a written agenda got declined automatically. Story points completed: up 22% quarter over quarter. Self-reported focus time satisfaction in our survey: up significantly, the biggest single-quarter jump we'd recorded. The meetings we kept were the ones people actually valued — nobody complained about losing them. We made the change permanent after seeing the numbers. Cutting felt risky. The data made it easy.

An engineer everyone quietly wanted off the team turned out to be badly mis-staffed, not underperforming. He'd been stuck on frontend work for a year, consistently slow, consistently needing rework, and the narrative around him had calcified into 'not senior material.' I moved him onto a backend data pipeline project almost by accident, covering for someone on leave. Within three weeks he was shipping faster and cleaner than he ever had, and clearly enjoying the work in a way that showed in code review conversations. He wasn't underperforming. He was doing frontend work he'd never actually been good at or interested in, and nobody had asked the right question before labeling him a problem. Redemption stories like this happen more than firing-fast advice on this platform would have you believe.

Three mistakes I made in my first year as an engineering manager, named specifically instead of vaguely. Hoarding technical decisions because I was still the strongest engineer on the team and it felt faster to just decide myself. It was faster short-term and stunted my team's growth long-term. Shielding the team from all organizational context, thinking I was protecting their focus. I was actually leaving them unable to make good tradeoffs because they didn't understand the constraints I was operating under. Treating quiet, low-drama sprints as automatically fine, when sometimes quiet meant disengaged, not smooth. Every one of these came from good intentions applied without enough self-awareness. New managers: you'll make some version of these. The fix is noticing faster than I did, not avoiding them entirely.

AI coding assistants changed what I actually look for when evaluating senior engineers, and it happened faster than I expected. I used to weight raw implementation speed fairly heavily in senior hiring signals. That's compressed for almost everyone now, so it's a much weaker differentiator than it was two years ago. What separates strong seniors now: review judgment, specifically catching the subtle thing AI-generated code gets wrong. System taste, knowing when a fast AI-generated answer is architecturally wrong for this specific codebase even if it technically runs. And the willingness to slow down and verify instead of trusting confident-sounding output. I've updated our interview loop to test for exactly this, reviewing flawed AI-generated code instead of writing from scratch. It's revealed real gaps our old process missed entirely.

Inside our incident retro: the actual template, including the parts that get awkward. Timeline first, facts only, built before anyone speaks about cause — this is the part that keeps blame out of the room. Then: what went well, genuinely, even in a bad incident something usually did. Then contributing factors, plural, because incidents are rarely one root cause. The awkward part: when an exec joins, which happens on our worst incidents. I've learned to state the ground rules out loud before they arrive — facts and systems, not individual performance, and I've had to gently redirect a VP mid-meeting more than once. That redirect is uncomfortable every single time. It's also the exact moment that determines whether your blameless culture is real or just a slide in the handbook.

Seven signals I look for that tell me an engineer is ready for staff scope, beyond just strong individual output. Influence that extends past their own team — other teams adopting their patterns without being told to. Writing that travels, a design doc or postmortem people outside the immediate project reference months later. Glue work made visible: the unglamorous coordination that unblocks three other people, done consistently, not once. Judgment under ambiguity, making a good call when the requirements are genuinely unclear, not just when someone hands them a spec. Mentoring that produces visible growth in someone else, not just presence in the room. Pushback delivered well, disagreeing with a decision constructively instead of either silently complying or blowing up the room. Any one of these alone isn't enough. Several together, sustained, usually is.

Should engineering managers still write production code? Wrong answers welcome, but I want your actual practice, not the theory. My honest answer: rarely, and mostly small, low-risk pieces — a config change, a tiny bug fix, never anything on the critical path where my rustiness could bite the team. I've seen EMs who code constantly and their teams feel micromanaged because every PR gets second-guessed by someone who's also their boss. I've seen EMs who never touch code and slowly lose enough technical credibility that architecture conversations start happening without them. There's a narrow lane between those two failure modes, and I don't think anyone's found the exact right width of it. What's your actual practice — not the aspirational answer, the real one?