The most underrated skill in engineering leadership:
Knowing when NOT to build something.
Every feature you add is something you now have to maintain, document, test, and explain to new engineers.
Say no more than you say yes. Ship less than your roadmap demands.
72 hours later: they had enough to operate.
Not enough to be comfortable. But enough.
The real fix took 3 weeks of documentation sprints.
The lesson: bus factor of 1 is not a technical problem. It's a risk management failure.
Don't wait for the bus to arrive.
Then: write everything down in real time.
Not a wiki. Not a Notion doc. A scratchpad that we could convert later.
Perfect is the enemy of done when you're in crisis mode.
Green flags when joining a startup as CTO:
→ Engineers can explain the architecture without a diagram
→ There's a runbook for at least one critical failure
→ The CEO heard the word "observability" before
Red flag: all three are missing and they're about to raise a Series B.
Myth: "We need to hire more engineers to ship faster."
Reality: most teams slow down when they grow because coordination overhead grows faster than output.
Better architecture enables small teams to ship at the speed of large ones.
What separates a $1M ARR startup from a $10M ARR startup technically?
Usually not the code.
Usually: documentation, observability, and on-call processes.
The product stays the same. The operational maturity changes everything.
I just finished my 30th technical audit of a startup.
Here's what I've never seen in a company that raised Series B:
→ No documentation
→ No runbooks
→ One engineer who knows everything
🧵
The common thread: operational maturity isn't a nice-to-have at Series B.
It's table stakes.
If you're heading into a raise and none of these exist — start building them now. Not after.
Investors notice.
And they never had a single point of failure in knowledge.
The lead engineer might know the most. But they're not the only one who can deploy, debug, or describe the system.
A Series A startup asked me to review their codebase before a fundraise.
First thing I found: no tests.
Not "not enough" tests — zero tests.
Second thing: their lead engineer didn't think tests were necessary "at this stage."
We had a long conversation.
Don't have them?
You have two options:
— Spend 3 months building them internally
— Bring in someone who's done it 10 times before
Either way, you need them before the room.
The 3 documents every startup should have before Series A:
1. System architecture diagram
2. Incident runbook
3. Security posture doc
Most have zero of these.
Investors are starting to ask for all three.
Unpopular opinion: you don't need a microservices architecture.
You need an architecture your team can actually maintain.
For most startups, that's a well-structured monolith.
Complexity is a cost. Make sure you're paying it intentionally.