The real job of a Head of Engineering

After two and a half years as Head of Engineering at FinanceOps, I can describe the job in one sentence: make the engineering organization’s throughput predictable and its quality sustainable.

Not hero-shipping features. Not writing the most code. Not attending the most meetings. Not being the smartest person in every technical discussion. The job is building a system of people, processes, and technology that delivers reliably without depending on any single person. Including you.

Generate a realistic engineering desk scene with terminal diffs, code review panes, model output snippets implied visually, charcoal and violet palette, 16:9, no robots, no sci-fi holograms, no text overlays.

Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “Architecture debt is usually a decision-quality problem first.” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.

Editorial supporting image for the section "What the Job Is Not" in the article "The real job of a Head of Engineering". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "The real job of a Head of Engineering". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: slate, amber, off-white paper, low-contrast office shadows. Mood: measured, confident, strategic, scarred enough to sound calm while saying hard things. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No staged handshake photos, no smiling meeting stock imagery, no motivational poster energy, no text overlays.

What the Job Is Not

The job descriptions for Head of Engineering are consistently wrong. They describe a senior individual contributor with management responsibilities. Lead technical architecture. Write critical code. Review every PR. Mentor every engineer. Define the technology roadmap. Manage the team. Coordinate with product. Report to the CEO.

If you try to do all of these things, you will do all of them badly. The first lesson of the role is identifying what only you can do and delegating everything else. Not delegating because you are too busy. Delegating because the organization needs people other than you to be capable.

Things that are not your job, even though they feel like they should be:

• Writing the most critical production code. If the most critical code requires the Head of Engineering to write it, you have a team capability problem, not a coding problem.
• Reviewing every pull request. If every PR needs your approval, you are a bottleneck, not a quality gate. Build review capability in the team.
• Being the technical decision-maker for everything. If every architecture decision waits for your input, you have not built decision-making capability in your team.
• Solving every production incident. If you are the first responder for every outage, your on-call rotation is broken and your team is not growing.

What the Job Actually Is

The job has three components. Everything else is a distraction.

1. Throughput predictability. Can the business rely on engineering to deliver what it commits to? Not faster. Not more. Predictably. When product asks for a feature by March, can engineering say yes or no with confidence? When the CEO asks for a timeline, is the answer based on data or on hope? Predictable throughput means the business can plan around engineering, not around uncertainty.

2. Quality sustainability. Is the quality of engineering output sustainable over time, or is it degrading? Are incidents increasing? Is deployment confidence decreasing? Is developer velocity slowing? Sustainable quality means the team can maintain their current output level for years without burning out, accumulating debt, or creating reliability crises.

3. Organizational capability. Can the team function without you? Can they make decisions, resolve conflicts, handle incidents, and deliver features when you are on vacation? If the answer is no, you have not built an organization. You have built a dependency.

The Metrics That Matter

I measure my own performance on four metrics:

• Commitment reliability. What percentage of sprint commitments were delivered on time? Not story points completed. Commitments met. The business cares about predictability, not velocity.
• Incident trend. Is the six-month incident trend flat, declining, or increasing? Declining is the target. Flat is acceptable. Increasing means quality is not sustainable.
• Decision autonomy. How many decisions required my direct involvement versus being made by the team? The goal is a declining trend. More team-made decisions means the organization is growing in capability.
• Retention. Are engineers staying? If the team turns over faster than the industry average, the environment is not sustainable regardless of what the other metrics say.

The Hardest Part

The hardest part of the job is not technical. It is emotional. The Head of Engineering role requires giving up the identity that earned you the role. You got here by being a great engineer. Now the job is making others great. You got here by solving hard problems. Now the job is creating an environment where others solve hard problems.

The temptation to jump in and write the code is constant. The code would be faster if you wrote it yourself. That is true and irrelevant. If you write it, the team does not learn. If the team does not learn, the organization does not grow. If the organization does not grow, you become a permanent bottleneck. The short-term speed gain costs long-term organizational capability.

Create an editorial workflow image showing AI-assisted engineering under human oversight: pull request, checklist, quiet confidence, cobalt and graphite palette, 1:1, no futuristic clichés.

This is the phase where individual scars finally turned into repeatable operating principles. I cared less about sounding clever and more about leaving behind a system that stayed sane without me in the room. That is how I build lifeos and bisen-apps too.

The real job of a Head of Engineering is to make yourself unnecessary. Not unemployed. Unnecessary for the day-to-day operation of the engineering organization. The team delivers without you. The decisions get made without you. The incidents get resolved without you. You become the person who sets direction and builds capability, not the person who does the work.

The Two and a Half Year View

Two and a half years into this role, I am closer to this ideal than I was at the start, but not there yet. I still get pulled into incidents that the team should handle independently. I still make architecture decisions that a senior engineer should own. I still write code occasionally when I should be coaching someone else to write it.

The progress is measurable, though. My calendar has more one-on-ones and fewer code reviews. More strategy sessions and fewer debugging sessions. More coaching conversations and fewer keyboard hours. The direction is right even if the destination is not reached. The job is the direction, not the destination.