Eighteen months in: the five things I would tell myself on day one as Head of Engineering at a startup

June 30, 2025, marks eighteen months since I joined FinanceOps as Head of Engineering. In that time the team has grown from just me to four engineers. We have shipped a reconciliation platform serving banks and payment processors. We have survived production incidents, compliance audits, and investor pressure. We have made good decisions and terrible ones. If I could send a letter to myself on day one, it would contain five things that took me too long to learn.

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.

This phase is where the title finally started to feel expensive. It also builds on what I learned earlier in “Founder dynamics: when your technical opinion conflicts with the CEO’s investor promise.” Hiring, planning, founder conversations, and bad weeks in production all piled into the same calendar. A lot of the systems thinking I kept in lifeos and flowscape showed up here too: clarity is not paperwork, it is how you stop uncertainty from leaking into people.

Editorial supporting image for the section "Delegate Before You Are Ready" in the article "Eighteen months in: the five things I would tell myself on day one as Head of Engineering at a startup". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "Eighteen months in: the five things I would tell myself on day one as Head of Engineering at a startup". 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: tense but controlled, operational, carrying team and system weight at the same time. 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.

Delegate Before You Are Ready

I spent the first six months doing everything myself. Every code review, every deploy, every architecture decision, every production incident. I told myself I was the most qualified person to do these things, which was true and irrelevant. My job was not to be the most qualified person. It was to build a team that could operate without me.

The first time I delegated a code review, the reviewer missed something I would have caught. That felt like evidence that delegation was premature. It was actually evidence that I had waited too long. The reviewer needed practice that I had been denying them by hoarding all the reviews. Delegation is slower at first because you are investing in someone else building context. But the investment compounds. Three months after I started delegating, the team was reviewing code, deploying, and handling incidents without me as a bottleneck.

If you are a new Head of Engineering and you are doing everything yourself, you are not being responsible. You are being a single point of failure. Start delegating the first week, before you think the team is ready, because the team gets ready by doing the work.

Learn Compliance Before It Learns You

I came from a product engineering background where compliance was someone else’s problem. At a fintech startup, compliance is an architecture constraint that affects every technical decision. I learned this the hard way when our first compliance audit surfaced 23 findings, every one of which was a shortcut I had taken in the first year.

• Your API surface is a regulatory document. Design it like one from day one.
• PII in application logs is a finding that takes weeks to remediate and costs nothing to prevent.
• Audit trails for financial transactions cannot be bolted on later. Build them into the data model.
• Self-audit quarterly even if nobody is asking you to. The findings will be the same but the remediation cost will be lower.

The compliance officer who started reviewing my API specs was the best thing that happened to our engineering quality. Cross-functional review by people with different expertise catches a category of issues that peer engineering review misses entirely.

Your Cofounder’s Priorities Are Not Wrong, Just Different

My CEO made commitments to investors without consulting me. Sales promised features we had not built. Product prioritized client requests over infrastructure stability. For months, I treated these as failures of other teams to understand engineering constraints. The reframe that changed everything: they were not failing to understand my world. I was failing to translate mine into theirs.

When I started framing technical debt as a business risk register with revenue-at-risk numbers, my cofounder approved remediation sprints that he had been deferring for quarters. The information was the same. The language changed. Learning to translate engineering concerns into business terms is not a nice skill for a Head of Engineering. It is the core skill.

Tech Debt Compounds Faster Than You Think

Every shortcut I took in the first six months became more expensive to fix with each passing month. The TypeScript loose mode decision that seemed harmless at 5,000 lines of code required a six-month migration project at 40,000 lines. The missing database indexes that were fine with 10,000 rows caused an 80 percent CPU incident at 14 million rows. The hardcoded API keys that I planned to move to a vault “next sprint” were there for 14 months.

Tech debt does not accumulate linearly. It compounds. Each shortcut makes the codebase harder to change, which makes the next shortcut more tempting, which makes the debt grow faster. The best time to fix tech debt is immediately. The second-best time is today. The worst time is during a compliance audit or a production incident.

Your Job Is Not to Write the Best Code

This was the hardest lesson. I became Head of Engineering because I was a strong individual contributor. My instinct was to keep being the best coder on the team while also doing the leadership work. For six months, I wrote more code than anyone on the team. I also reviewed every PR, made every architecture decision, and handled every incident. The result was that I was the bottleneck on everything and the team could not function without me.

This is where the role stopped feeling like senior-engineer-plus. Every decision had a human system wrapped around it: founders, customers, auditors, tired teammates. The same systems thinking bled into lifeos and bisen-apps, where defaults matter more than heroics.

Your job as Head of Engineering is not to write the best code. It is to build a team that writes good code without you. If the team cannot ship a feature, handle an incident, or make an architecture decision while you are on vacation, you have not done your job.

The moment I knew I was succeeding was a Thursday in March when I was sick with the flu. I stayed in bed for two days. The team shipped features, resolved alerts, and deployed without me. The Slack messages I woke up to were status updates, not questions. That was eighteen months of painful lessons paying off.

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

---

Eighteen months is long enough to make every mistake at least once and short enough that the scar tissue is still fresh. These five lessons are not wisdom. They are things I learned by doing them wrong first. If you are at month one as a Head of Engineering at a startup, start delegating today, learn your compliance framework this week, buy your cofounder coffee and ask what keeps them up at night, and accept that your job changed the day your title did. The code will get written. Your job is everything else.