What I got wrong in my first year as Head of Engineering and what I would do differently

My first year as Head of Engineering at FinanceOps was the most instructive failure of my career. Not because things went badly. The product shipped. Customers signed. The team grew. By most external measures, it was a success. But internally, I made four mistakes that cost the organization months of momentum and nearly burned out two of my best engineers.

I am writing this for every engineer who just stepped into a leadership role and is about to make the same mistakes I did. You probably will anyway. But at least you will recognize them faster.

Generate a realistic hiring editorial scene with pull request diff, handwritten notes, laptop on a desk, soft overhead lighting, 16:9, no staged interview smiles, no stock-photo office feel.

Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “The real job of a Head of Engineering.” 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 "Mistake 1: Over-Hiring Before Establishing Culture" in the article "What I got wrong in my first year as Head of Engineering and what I would do differently". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "What I got wrong in my first year as Head of Engineering and what I would do differently". 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.

Mistake 1: Over-Hiring Before Establishing Culture

I hired four engineers in my first three months. The team went from two to six. I was excited about the velocity increase. What I did not account for was that there was no culture to hire into. No established ways of working. No code review norms. No decision-making framework. No on-call rotation. No shared understanding of quality standards.

Each new hire brought their own norms from their previous company. Six engineers with six different ideas of how engineering should work is not a team. It is a committee. I spent more time resolving conflicts about process than building product. The resolution was always a compromise that nobody loved.

What I would do differently: hire one engineer. Establish the ways of working with three people total. Document the norms. Then hire the next three into a culture that already exists. The hiring pace should match the culture-building pace, not the headcount budget.

Mistake 2: Saying Yes to Every Cross-Functional Request

Product wanted features. Sales wanted demos. The CEO wanted investor metrics. Compliance wanted audit trails. Support wanted admin tooling. I said yes to all of them because I did not want to be the bottleneck. I wanted engineering to be seen as responsive, collaborative, and customer-oriented.

The result was predictable. Engineering was working on twelve things simultaneously and finishing none of them. Feature delivery slowed. Quality dropped. The team was context-switching so frequently that nobody had the focused time to do deep work. My attempt to not be a bottleneck had turned the entire team into a bottleneck.

What I would do differently: say no by default and yes by exception. Every sprint has a theme. One to two major deliverables. Everything else waits. The CEO, product, and sales may not like hearing “not this sprint.” But they like missed deadlines even less.

Mistake 3: Underinvesting in Developer Experience

In my first year, developer experience was not on the roadmap. CI pipeline speed was not a priority. Local development setup was painful. Documentation was sparse. On-call tooling was manual. I prioritized customer-facing features over internal tooling because customer features generated revenue and internal tooling generated nothing visible.

The invisible cost was developer velocity. A 20-minute CI pipeline meant engineers checked out during builds. A painful local setup meant onboarding took a week instead of a day. Missing documentation meant senior engineers were constantly interrupted by questions they had already answered.

What I would do differently: allocate 20% of engineering capacity to developer experience from day one. Not when it becomes a problem. From day one. The compound return on a fast CI pipeline, good documentation, and smooth onboarding pays for itself within two quarters.

Mistake 4: Staying Hands-on Too Long

I wrote production code for the first nine months. Not because the team needed it. Because I needed it. My identity was tied to being a great engineer, and the Head of Engineering role felt uncomfortably abstract. Writing code felt like real work. Managing people felt like overhead.

The cost was that every hour I spent coding was an hour I was not spending on the leadership work only I could do. Building the decision-making framework. Establishing the culture. Having the difficult conversations about performance. Setting the technical direction. These activities have higher leverage than any code I could write, but they do not produce the same dopamine hit as a merged PR.

What I would do differently: set a hard limit of one day per week on hands-on-keyboard from month one. Use the other four days for the work that only the Head of Engineering can do. Accept the discomfort of the identity shift early instead of deferring it until the organizational cost forces it.

The Common Thread

Create an editorial desk scene about engineering hiring judgment: scorecards, code review notes, subtle authority, 1:1, natural shadows, no HR stock-photo look.

By the time I wrote this, the lesson was bigger than the tool or incident. The job had become setting defaults a team could trust, then proving those defaults in systems like lifeos and bisen-apps. That is leadership work, not just technical taste.

The common thread in all four mistakes was not trusting the team I was building. I over-hired because I did not trust a small team to be enough. I said yes to everything because I did not trust the team to push back. I underinvested in tooling because I did not trust that developer experience mattered. I stayed hands-on because I did not trust anyone else to write the code.

Trust is the foundational leadership skill. Not technical architecture. Not hiring. Not strategy. Trust. Trusting the team you built to be capable. Trusting the culture you established to guide behavior. Trusting the system to work without your constant intervention.

My second year was better because I made different mistakes. But the first-year mistakes were necessary. You cannot learn trust from a book. You learn it by watching what happens when you fail to extend it.