The IC-to-Director Pipeline

Seven years at MoneyView. Five role changes. IC → Lead → Engineering Manager → Senior EM → Director of Engineering. This isn't a post about how to climb the ladder. It's about what actually changes at each step — and what surprises you when you get there.

IC → Lead: The Multiplier Shift

As an IC, your output is your code. Quantifiable. git log --author="you" --oneline is a reasonable proxy for your impact. As a lead, that mental model breaks immediately.

Your output is your team's code. The hardest part isn't delegation — it's accepting that "good enough, shipped by the team" beats "perfect, shipped by you alone." Your instinct is to jump in and fix things. Every time you do that, you make yourself a bottleneck and make the team weaker. You stop being the best coder in the room and start being the person who makes the room better at coding.

Concretely: I started spending 30% of my time on code reviews that weren't blocking anything — they were teaching tools. The PR comments were for the author's growth, not for the codebase. I introduced architecture docs before implementation, not after. The cost was my own throughput. The return was three engineers who could own systems end-to-end instead of one.

The lead role is also where you encounter your first real organizational friction. You want to build X, stakeholders want Y, and your team has the capacity for half of either. You learn to negotiate, to say no in ways that don't create enemies, to document decisions so the "why" doesn't disappear when someone asks six months later.

Lead → Manager: The Context Switch

You start spending 60% of your time in meetings, and it feels wrong. It feels like you've stopped doing the work. That feeling is wrong.

Those meetings ARE the work. Aligning stakeholders, unblocking your team, shaping roadmaps — this is how engineering gets done at scale. The code you write drops to near-zero, and that's okay. What you're writing now is org design, hiring strategy, and career development plans.

The tool that helped me most in this transition: weekly 1:1s with a structured template. Not status updates — those should happen async. 1:1s are for career direction, blockers that don't surface in standups, and calibrating on how each person measures their own success. Engineers measure themselves in surprising ways. Some care deeply about technical complexity. Others care about product impact. Others care about peer respect. Knowing this lets you give them the kind of work that actually motivates them.

The mistake I made early: I kept thinking in terms of my own contributions. I'd have a slow week and feel unproductive, not realizing the team had shipped three critical things because I'd spent that week hiring, and hiring is how you scale the team's output by orders of magnitude.

At MoneyView, this was the phase where the scale of the product started mattering. Bugs weren't "a user hit an error." They were "a million users hit this edge case." The engineering quality bar shifted from "does it work?" to "does it hold under load, degrade gracefully, and recover automatically?"

Manager → Senior Manager: The Portfolio View

You're no longer managing a team. You're managing multiple teams, which means you're managing managers. This is a completely different skill.

Managing managers means you're now responsible for their growth, not just their teams' output. A new EM who's struggling needs coaching on their management style, not help with their sprint planning. Your ability to give that coaching depends on how well you've internalized the lessons from your own transition.

You also start building cross-team intuition. You notice where teams are stepping on each other. You design processes that help them coordinate without needing your constant involvement. You become a context router — you know which person on which team has the right context for any given problem, and you make introductions.

The feedback loop on your decisions gets longer. A hiring call you make today affects the team's capability six months from now. A technical direction you set today shapes the architecture for two years. You learn to be more deliberate and to document your reasoning, because by the time the impact shows up, you'll have forgotten the original context.

Senior Manager → Director: The Strategy Layer

The biggest shift: you stop solving problems and start choosing which problems to solve.

Every problem that reaches your level has already been filtered. Your team handled the bugs. Your managers handled the resource conflicts. What reaches you are the genuinely hard things — organizational design questions with no right answer, technology bets with multi-year horizons, hiring for roles that don't fully exist yet.

Your decisions have months-long feedback loops. You're operating on a different clock cycle from your team. They're in sprints. You're in quarters. That mismatch requires constant translation — taking the long-term direction and breaking it into sprint-level context your teams can actually use.

At this level, you're also spending significant time outside engineering. Product roadmaps, investor conversations, cross-functional planning. You're representing engineering's capabilities and constraints to people who don't think in systems. You're representing business priorities to engineers who think in systems. You're a translator in both directions.

What I didn't expect: how much of the Director role is about organizational health. Culture compounds. A small norm set in a team of 10 becomes a massive force in a team of 50. You're not just building software — you're building the environment in which software gets built. How that environment handles failure, disagreement, experimentation, and learning shapes everything downstream.

What Stays the Same

Through all five transitions: curiosity, systems thinking, and the deep satisfaction of watching something you built serve millions of people.

The context for applying those skills shifts at every level. As an IC, systems thinking means designing clean abstractions. As a Director, it means organizational design. But the underlying mental model — understanding how pieces connect, where the leverage points are, what breaks under load — that transfers completely.

The career ladder isn't a ladder. It's a sequence of role changes that require learning entirely new skills while retiring the ones that made you good at the previous role. The engineers who struggle with management are usually the ones who were the best ICs — their technical skill was their identity, and giving it up feels like losing themselves.

It's not loss. It's just a different kind of building.