I spent 13 years managing engineers, eventually 60 across multiple teams: explaining what to build, reviewing their output, pushing back on bad architectural decisions. Turns out those exact skills are what make AI collaboration work. The irony is that engineering managers who stopped coding full time years ago might be better positioned for AI than you thought.

TL;DR

The skills that made you a good engineering manager: clear communication, critical review, strategic delegation, architectural judgment, are exactly what AI collaboration requires. The years you spent thinking you were “just managing” were actually training for this.

Engineering managers can use AI effectively right now. You don’t need to “learn to code again” first. You need to apply the skills you already have to a new kind of collaborator.

The Skills That Transfer

What engineering managers do every day:

  • Explaining what to build
  • Discussing architectural trade-offs
  • Reviewing PRs with a critical eye
  • Reading PRs fast and finding issues
  • Critiquing wrong decisions
  • Deciding what NOT to build
  • Context switching between projects in 30-minute windows

These aren’t adjacent skills, they’re the same skills applied to a different collaborator. When I prompt Claude or Copilot, I’m doing what I did in every 1:1 with a developer: explaining the goal, providing context, setting constraints, reviewing output, giving feedback.

GitHub’s research backs this up: “Communication skills are important as developers navigate prompt engineering. The best AI prompts are clear, direct, and well thought out—and communicating with fellow humans in the workplace isn’t much different.”

That last part is the key. If you’ve spent years learning to communicate technical requirements clearly to humans, you’ve been training for AI collaboration without knowing it.

The Rookie Developer Mental Model

Gene Kim’s article on pairing vs delegation offers the best mental model I’ve found: “Treating the AI like a somewhat skilled but rookie developer is a helpful mindset: you can delegate grunt work to it, but you must review its output thoroughly and mentor/correct it when it goes off track.”

Engineering managers have been doing exactly this for years. The delegation patterns are identical:

  • Assess task complexity before assigning
  • Provide clear context and constraints
  • Set checkpoints for review
  • Give specific feedback, not just “this is wrong”

Camille Fournier’s The Manager’s Path distinguishes between micromanagement and effective delegation, allowing teams to encounter and learn from manageable challenges rather than shielding them from all difficulty. Same balance applies to AI. Over-constrain every prompt and you’ll spend more time writing instructions than the task would take. Under-specify and you get garbage. Engineering managers developed intuition for this balance through years of calibrating how much guidance each person needs. That intuition transfers directly.

Think about pair programming. The navigator guides strategy while the driver writes code. Engineering managers have been navigators for years, reviewing, guiding, course-correcting. Now the driver is AI, but the navigator role is unchanged.

When I started using Claude Code seriously, I noticed something strange: the rhythm felt familiar. Explain the goal, watch the implementation, catch the mistakes, redirect. It’s the same loop I ran with junior engineers, just faster and without the awkward “let’s schedule a sync” dance.

The FAAFO Framework

Gene Kim and Steve Yegge’s Vibe Coding book introduces the FAAFO framework for understanding AI coding’s value: Fast, Ambitious, Autonomous, Fun, Optionality. Your skills apply to all of them.

Fast: You know how to unblock work and remove friction. When AI gets stuck, you recognize the pattern: unclear requirements, missing context, wrong approach. You’ve debugged these problems with humans for years.

Ambitious: You have vision for what “could be built” that exceeds current team capacity. AI removes the constraint. That feature you shelved because it would take two sprints is now a weekend project.

Autonomous: You’ve spent years coordinating between teams, waiting on dependencies, aligning schedules. AI eliminates the coordination tax. You can iterate directly without waiting for someone else’s calendar.

Fun: Building beats managing. AI lets you return to creation. I stopped coding full time not because I couldn’t, but because the friction wasn’t worth it given everything else on my plate. AI removes that friction.

Optionality: You’re used to exploring multiple approaches before committing. “Let’s prototype both and see which works” is a natural instinct. AI makes this cheap.

The Maker vs Manager Schedule Advantage

Paul Graham’s famous essay divides work into maker schedule and manager schedule. Developers thrive on maker schedule, long uninterrupted blocks for deep creative work. Engineering managers are forced into manager schedule, days sliced into 30-60 minute chunks with constant context switching.

AI iteration cycles are short. You prompt, review output, refine, prompt again. Each cycle is 5-30 minutes. This maps perfectly to manager schedule, not maker schedule.

Anyone optimized for maker schedule finds this jarring. Deep flow states where you hold the entire problem in your head for hours, AI breaks that rhythm with constant interruptions to review, correct, re-prompt.

Engineering managers are already trained for it. You’ve spent years in back-to-back 30-minute 1:1s, switching between completely different projects, doing quick deep-dives then moving on. You load context quickly, make a judgment call, provide clear feedback, then move to the next thing. That’s manager schedule survival, and it’s exactly how AI collaboration works.

The context switching part is underrated. In a typical engineering manager day you might go from a security incident to a performance review to a roadmap discussion to a technical design review, all in two hours. Each context requires loading different mental models, asking the right questions, making judgment calls. AI collaboration is the same pattern. You might use AI for a Python script, then switch to reviewing its suggestions for a system design doc, then have it help debug a deployment issue. Different domains, different constraints, same rapid context-loading skill.

This also means you can work on multiple features in parallel. Start a feature, get AI generating code, switch to reviewing another feature’s output while the first one runs. It’s the same pattern as checking in on multiple engineers working on different projects, except the feedback loops are minutes instead of days.

That’s FAAFO’s Autonomy dimension in practice. Without AI, engineering managers coordinate with multiple devs on their own timelines. Lots of waiting, async communication, alignment meetings. With AI, you iterate directly in 30-minute chunks. No coordination tax. The manager schedule becomes a feature because you control the entire loop.

The Drift

The Vibe Coding book describes “the Drift,” the mental alignment between developer and AI collaborator where implementation matches vision. Engineering managers achieve this drift with their teams constantly. Getting a developer to understand your vision and execute on it is the same skill as getting AI to understand your intent.

Kim notes that AI eliminates two coordination taxes engineering managers know well: organizational friction (no waiting for dependent teams) and the mind-reading tax (your implementation matches your vision because you guide it directly). Every engineering manager has experienced the frustration of explaining something clearly, waiting a week for implementation, then seeing something that missed the point entirely. AI feedback loops are minutes, not days.

Achieving drift also requires what AI practitioners call “context engineering,” deciding what information the AI needs and how to structure it. Will Larson’s Staff Engineer describes exec communication as a limited-bandwidth problem: you have minutes, not hours, so every word carries weight. AI context windows work the same way. You can’t dump your entire codebase and hope for the best. You prioritize what matters, structure it clearly, cut the noise. Engineering managers have been doing context engineering for years, they just called it “prepping for the exec review.”

The Strategic Filter

AI is eager to help. Too eager. Ask it to build something and it will, even if building that thing is a terrible idea. It won’t push back and say “have you considered not doing this at all?”

Engineering managers develop a strategic filter through years of saying no. No to features that add complexity without value. No to solutions looking for problems. No to technically interesting work that doesn’t move business metrics. The hardest engineering manager skill is recognizing what not to build.

This filter applies directly to AI collaboration. AI will happily generate 500 lines of code for a problem that doesn’t need solving, or overcomplicate a solution that should be three lines. The judgment about what’s worth building, what’s overkill, what’s solving the wrong problem, that’s human work. Engineering managers have been practicing this judgment in every roadmap discussion, every backlog grooming, every “why are we doing this again?” conversation.

Same applies to problem-solving. Knowing which problems are worth solving, which are symptoms of deeper issues, which will resolve themselves if you wait, that’s pattern recognition built over years of managing technical teams. AI doesn’t have that context. You do.

Systems Thinking Over Syntax

Not knowing the latest framework syntax matters less than you’d think.

Engineering managers who stepped away from daily coding often retain deep knowledge of patterns, architectures, and principles while losing fluency in specific frameworks. You remember SOLID principles but forget React hooks. You understand distributed systems patterns but can’t remember the exact Kubernetes YAML syntax. You know when to use an event-driven architecture but haven’t touched Kafka configs in years.

That’s a good knowledge distribution for AI collaboration. AI is excellent at syntax, framework APIs, and implementation details, the stuff that changes every two years anyway. AI is mediocre at knowing when to apply which pattern, understanding the trade-offs between architectural approaches, recognizing when a design will create maintenance nightmares.

Engineering managers bring the judgment layer: “This should be event-driven, not request-response” or “This is a classic N+1 query problem” or “This abstraction is going to leak.” AI brings the implementation details: “Here’s the exact Kafka producer config” or “Here’s how to batch this in your ORM.”

Seeing multiple technology generations helps you recognize the underlying principles that transcend any specific implementation, and that breadth pairs well with AI’s syntax fluency.

Countering the “Engineering Managers Are Obsolete” Narrative

The threat is real. Gartner predicts 69% of manager workload automated by AI. Deloitte says half of middle management roles may vanish. DoorDash already runs 200,000+ drivers with no direct supervisors. Algorithms handle scheduling, ratings, and performance management.

But that’s the coordination role. Status reports, project tracking, basic decision routing. The engineering managers who survive are the ones who pivot to AI-human collaboration. The skills aren’t obsolete, they’re being redirected.

The old role: coordinate humans who code. The new role: direct AI that codes, with human judgment on architecture, quality, and priorities. Companies are moving away from command-and-control toward coaching, facilitation, and strategic oversight, recognizing that technology can’t replace the messy human parts where relationships and context matter.

Practical Tips for Engineering Managers

Use your delegation instincts. Assess task complexity before prompting, just like before assigning to a dev. Simple tasks get simple prompts. Complex tasks need context, constraints, examples.

Apply your review rigor. Don’t accept AI output you wouldn’t accept from a junior. Read the code. Question the approach. Push back on weird decisions.

Use your context switching. Your 30-minute deep-dive training is perfect for AI iteration cycles. You’re already wired for short loops.

Trust your architectural judgment. You know what good looks like, even if you haven’t written production code recently. That judgment is the valuable part.

Embrace the navigator seat. You’ve been guiding, reviewing, and course-correcting for years. The feedback loops are just faster now.

For Developers Building These Skills

If you’re a developer looking to strengthen these skills for AI collaboration:

Do more code reviews. Reviewing others’ code critically, quickly identifying issues, that skill transfers directly to reviewing AI output.

Mentor someone. Explaining concepts clearly to a junior dev is the same skill as writing effective prompts. Both require understanding what context the other person needs.

Take on cross-team work. Coordination and context-switching build the muscles AI collaboration requires. Volunteer for projects that span multiple teams.

Practice saying no. Push back on a feature that adds complexity without value. The strategic filter is a muscle you develop through use.

Get comfortable with short iterations. Set a timer for 30 minutes and ship something small. AI collaboration rewards quick feedback loops over long flow states.

These skills compound whether you use them with humans, AI, or both.