Post Facto — Seven Reasons Engineers Hate Their Managers in the Age of AI

Post Facto

A Blog by Holly French

Seven Reasons Engineers Hate Their Managers in the Age of AI

1. Information-gathering is becoming more siloed

When I first joined Fieldwire, I joined as an engineering manager who had no previous experience contributing to Fieldwire’s codebase. I was a blank slate. No historical knowledge of product decisions, no context on tech debt that hung around, no sense of tech design plans that were implemented or scrapped. And for me, the best way to learn more was to ask around. Sometimes I’d ask people to point me to documentation, RFCs, or old JIRA tickets, but sometimes I’d just ask people to talk me through it directly. It’d mean we’d have an extra-long 1-1, a nice coffee walk, or an extra team huddle.

But now, with AI and our handy dandy Confluence MCP, it’s easier to just talk to Claude all day. I’m thrilled I can bug my devs less and I can just talk to Claude, right? I can ask Claude a half-baked question, and it can pull out years of context around old RFCs, tech debt projects, and product specs. It’s more efficient, right?

But as we’ve onboarded new engineering leaders at Fieldwire, I’ve noticed a more troubling side-effect here. While once the hard work of EMs and staff devs was to talk to people, get historical knowledge, and build consensus, it’s often mostly done with Claude now. Two years ago, if another staff eng was doing research for a big initiative, I’d probably have known, because we’d all have been asking around about it. But now, we’re all sitting inside our own Claude silos. We ask Claude a bunch of questions, get pretty good answers, and are able to churn out pretty polished design diagrams, RFCs, and documentation. But often it comes at the loss of the middle part - the friction of reconciling conflicting answers from the devs we’re working with, the exercise of excavating historical context that isn’t sitting in confluence, and the act of building coalitions before churning out a polished document.

Sure, we’re able to churn out pretty good design docs now, but we’re doing it without the messy coalition-building, historical digging, and collaboration that makes these docs even more robust. And for ICs, that means less opportunity to bring their insights and opinions to org leaders.

2. Deadlines are more arbitrary

I’d like to think I’m the type of manager who pushes back when someone sets unrealistic goals for my team. As an IC, I know the feeling when an exec tells me “coding up an A/B test for this signup flow should only take a week” because he made a few PRs on that part of the codebase a couple years ago. I don’t want people on my teams to feel that.

That said, AI has supercharged the setting of arbitrary productivity goals. I’ve heard (and, honestly, seen) all too many horror stories of an exec who vibe codes a super slick prototype on a weekend, shows it to the product org, and uses that prototype as proof that it shouldn’t be too difficult to ship a fully-fledged product in just a couple sprints. But this often doesn’t include the work of wrangling messy third-party SDKs, understanding business edge cases, setting up good reporting and analytics frameworks, and all the other software development things.

Sure, a vibe-coded prototype can often prove out something tangible, and it can speed up early development decisions, but without consulting the devs who will be involved, it increases the trust gap between engineers and their managers.

3. Metrics are used in ambiguous ways

As a self-professed metrics-obsessed engineer, I love to measure all things dev-experience, but I know to take these all with a grain of salt. I like to keep track of how long PRs stay in review, but I know some PRs take longer than others to review. I measure the size and rate of change of my bug backlogs, but I know our team has seasons of driving down bugs and also pushing out features quickly.

But suddenly, teams have these new metrics dashboards popping up. AI made it easy to count lines of code, PR volume, token usage, and AI-generated code accepted. Some teams are more heavily measuring the things AI inflates. I know I’m not alone in resenting being graded on gameable numbers.

4. AI rewards context switching

AI rewards context switching. By way of example, a top dev on my team currently has 2 RFCs open, a backend PR open, as well as separate iOS and Android PRs in the works. Claude is great at cruising through these different workstreams, and this dev’s commit numbers this month are through the roof.

The problem? Engineering managers are fundamentally supposed to be GOOD at context switching. An EM’s day is typically a mix of team meetings, 1-1s, PRs reviews, checking in on random Slack DMs, doing roadmap planning. For me, that’s a skill that I had to develop. Took a year or two, but I think I’m pretty good at context switching now. For ICs? I’m not so sure. Code reviews are more...