Introduction to Technical Execution
Technical Execution
This is the chapter most new EMs think they'll be great at. You spent years shipping software. You know what good execution looks like. You've seen projects go off the rails and you know why. How hard can the execution side of management be?
Harder than you think — because execution through other people is a completely different problem than execution yourself.
The Core Problem
When you were an IC, if something needed to get done, you did it. The feedback loop was short. You wrote the code, you saw the result, you adjusted. Managing execution means your feedback loop is much longer and much more indirect. You're not the one writing the code — you're the one making sure the right code gets written, by the right people, in the right order, with the right information.
That requires a different kind of work: setting up the processes and cadences that give your team clarity, making decisions when information is incomplete, removing blockers before they compound, and staying technical enough to be useful without becoming the bottleneck.
What This Chapter Covers
Seven lessons — the largest chapter because execution is where most new EMs spend most of their time:
- Meeting Cadences — the default rhythm that keeps the team aligned without over-meeting
- Collecting Feedback — the feedback loops that tell you whether things are working
- Systems Thinking — how to build repeatable processes instead of solving the same problems repeatedly
- Decision Making — a framework for the decisions you weren't trained to make
- Technical Contributions — how to stay in the technical conversation without taking over
- Bringing UX, Product, and Engineering Together — cross-functional execution without chaos
- Delegating — the hardest one: actually letting go of IC work
By the end of this chapter you'll have a clear operating system for running your team week-to-week.