A founder CTO doing Year 1–5 has four real jobs simultaneously — this system stops the urgent from eating the important every single week.
## The Problem It Solves
At year 1–5 as a founder CTO, you are: shipping code, reviewing architecture decisions, hiring/managing engineers, and sitting in product/business meetings. None of these have natural forcing functions to stay proportional. Without a weekly rhythm, you default to whatever is loudest — which is almost always the wrong thing.
## The Four Jobs and Their Time Budgets
These are starting allocations. Adjust quarterly based on team size. The point is making the tradeoff explicit rather than letting it happen to you.
| Job | What it actually is | Target % of week |
|-----|--------------------|-----------------|
| **Builder** | Coding, architecture review, technical decisions | 40% (shrinks as team grows) |
| **Manager** | 1:1s, hiring, unblocking engineers | 25% |
| **Operator** | Incidents, infra, security, compliance | 20% |
| **Strategist** | Tech roadmap, build-vs-buy, investor/board tech questions | 15% |
## The Weekly Structure (40-hour baseline)
**Monday — Set the week (1 hour)**
- Review what shipped last week vs. what was planned. If the gap is >30%, that's a system problem, not an execution problem.
- Pick your ONE technical decision that must be made this week. Write it down.
- Check if any engineer is blocked. Unblock them before lunch.
**Tuesday/Thursday — Deep builder work (3 hours each, protected)**
- No meetings before noon on these days.
- This is when you code, review PRs that require real judgment, or write technical specs.
- If you've been in a meeting by 10am on a Tuesday, your calendar is running you.
**Wednesday — People (2 hours of 1:1s)**
- 30-minute 1:1s with each direct report.
- Three questions you should be able to answer after Wednesday: Who is blocked? Who is unhappy? Who is growing faster than their role?
**Friday — Close loops (1 hour)**
- Update the technical decision log — what got decided, what's still open.
- Spend 20 minutes on the thing you've been avoiding all week. It doesn't disappear.
- Write 3 sentences on the state of the system: what's getting better, what's getting worse, what you're ignoring.
## The Artifacts That Make This Work
Three documents, updated weekly. Each lives in a single shared location (Notion or a markdown file in your repo):
**1. Technical Decision Log** — one row per significant decision: date, decision, who made it, what we'll know in 90 days to evaluate it. Not an architecture doc — a log.
**2. Eng Health Tracker** — four columns: Deploy frequency (are we shipping?), Incident count (are we breaking?), P1 ticket age (are we fixing?), PR review latency (are we reviewing?). One row per week. If you can't fill this in in 5 minutes, your observability is broken.
**3. The Skip-Level Notes Doc** — after every skip-level conversation (quarterly), write what you heard. Founders who lose touch with their IC engineers get blindsided. This doc is the early warning system.
## When to Throw This Out
This system is for steady-state. During a fundraise, a major incident, or a team crisis — compress everything into survival mode for 2–4 weeks, then return to the cadence. Founders who stay in survival mode permanently burn out their teams within 18 months.