The new-CTO onboarding problem: when nobody can tell you why

The scene

It's a Tuesday. You've been at the company six weeks. The board observer drops into the engineering channel and asks, in passing, why the team is on Postgres rather than something Mongo-shaped — surely the document model fits the product better? The CTO before you spent eight months sparring with Claude over exactly that question. You know this because you found a folder in a shared drive titled thinking/db-pick-2025-q1/ with one Markdown file in it called SCRATCH and three lines: "trade-offs are real, will revisit, see chats." There are no chats.

You buy yourself two days by saying you'll write up the rationale. You spend an evening DM-ing the previous CTO, who is friendly and has very little to add ("oh man, that was a long thread — Postgres won on operational simplicity I think? Let me dig"). You spend the following morning reverse-engineering the call from the actual schema and the migration commit messages. The answer you ship is plausible. It's also half-invented. Six months from now someone will ask you why you're still on Postgres and you'll have less to say than you do now.

This isn't a one-off. This is the modal new-CTO experience in 2026.

Why it's everywhere now

Five years ago a new CTO inherited a stack whose rationale was at least partially in email — a long, threaded conversation with one or two co-founders or a tech lead, archived in Gmail, searchable. Today the same call would be made in a private chat with Claude or ChatGPT, with the founder typing things like "tell me what I'm missing about going Mongo here" and the model responding with a long structured trade-off analysis. The output is often better than the email-thread version. It's also entirely invisible to the rest of the company. The model doesn't archive into the corporate Slack. The transcript doesn't get pasted into a wiki — it's six pages long and full of half-thoughts the founder doesn't want anyone to see. It lives in one person's chat history. When they leave, it leaves with them.

The other major shift is volume. A single L5+ engineer using ChatGPT or Claude through a typical week will produce 15–30 conversations, of which maybe 3–6 contain a real fork in the road. Multiply by twelve months and a five-person team and you're looking at roughly 1,500 durable engineering decisions per year that exist only inside personal AI chat histories. The pre-LLM era didn't generate that volume of recorded thinking; it just generated decisions, with the thinking lost to the void. The volume of recorded thinking is up. The accessibility of it is down. That's the gap.

Why ADR ceremony doesn't fix it

The standard answer is "you should have been writing ADRs." Architecture Decision Records — short, structured Markdown files in docs/decisions/0042-use-postgres.md — are a real discipline that real teams use. Here's a fully worked Postgres-vs-MongoDB example so you can see what one looks like. They're great for the decisions that get formalized.

The trouble is that the formalized fraction is small. In our experience reviewing engineering teams' decision histories, somewhere between 10% and 20% of durable architecture and product decisions end up as written ADRs. The other 80–90% happen on a Wednesday at 11pm during a debug session, surface as "let's just go with X" in a Slack thread the next morning, and get implemented before anyone files a record. The decisions that do become ADRs tend to be the ones that were already easy — the ones with a clear winner and a small risk surface. The ones that haunt you in onboarding are precisely the ones the team didn't have time to write up because they were genuinely hard.

ADR tooling like npryce/adr-tools does the right thing for the formal layer. It's just not enough on its own. You need a second layer that catches the informal thinking — the kind that happens in chat — and turns it into a record retroactively.

Why the Notion wiki doesn't fix it either

The Notion answer is a "Decisions" database with eight properties — date, owner, options considered, chose, rejected, why, status, supersedes. There's a good template for it. The Notion answer is what every well-run engineering org tries first, and the failure mode is the same one every well-run engineering org hits: the database stays 80% empty. The page exists. The schema is right. People mean to fill it in. They keep forgetting because the friction-of-recording is higher than the perceived-cost-of-not-recording, until six months later someone is onboarding and the cost flips.

This isn't a discipline failure. It's a tool-shape mismatch. Decisions are made in chat; the wiki sits in a different tab; the round-trip is 4–6 minutes per decision; the engineer skips it. The fix isn't more discipline. It's removing the round-trip.

What actually works: extract from where the thinking happened

The good news for the new CTO is that the thinking is recorded — just not where you'd look. ChatGPT and Claude both let users export their full conversation history as a one-click ZIP. The ChatGPT walkthrough takes about five minutes, end to end; the Claude one is similar. The artifact you get back is a conversations.json file holding every message the user has sent, with timestamps.

You don't read the file. You run a pass over it to extract the decisions. There are two ways to do this. The cheap one is regex: scan each conversation for patterns like "we'll go with", "let's pick", "decided to", "X over Y", "the answer is", and capture ~40 tokens of context. The expensive one is an LLM pass: feed each conversation into a small model with a JSON schema asking for {title, chose, rejected, rationale}[]. The regex approach is noisier but free and runs in seconds. The LLM approach is cleaner and costs ~$0.001 per conversation. From a year of one engineer's chat history, both yield somewhere between 20 and 80 durable decision records. The signal is real and the manual review takes an hour, not a week.

This is the entire premise of WhyChose. The extractor is open source — MIT-licensed, ~500 lines of Node, zero runtime dependencies, runs locally — so you don't have to take our word for any of this. Run it on your own export this afternoon. The hosted product wraps the same engine with team sharing, search, and Notion/Linear export, but the engine itself is free to read and run.

What an extracted decision looks like

Here's a real record (the names have been changed) of what comes out of the extractor when run over one of the author's own ChatGPT conversations from last year:

{
  "title": "Chose Postgres over MongoDB for primary store",
  "date": "2025-03-14",
  "chose": "Postgres 16 with JSONB columns for the document-shaped data",
  "rejected": "MongoDB 7 (rejected) and CockroachDB (rejected as overkill at our size)",
  "rationale": "Operational simplicity dominates at our team size — one of us has prod Postgres ops experience and zero of us has prod Mongo ops experience. JSONB covers the document use case for the next 18 months with no measured query-perf hit. Revisit if write volume crosses ~5k/s sustained or if schema-on-read becomes the dominant pattern.",
  "tags": ["stack", "database"],
  "source_chat_id": "8c4a2e1f-...",
  "source_message_index": 47
}

This is the artifact your successor — or your board observer — needs. Not a defensive write-up of the chosen path, but a record of what was on the table, what was rejected, why, and the conditions under which the call should be re-opened. The source_chat_id + source_message_index let anyone click through to the original conversation if they want to challenge the summary. That's the audit trail.

Your first 90 days as the new CTO: a three-line version

1. Week 1. Ask the outgoing engineering owner to export their ChatGPT and Claude history before their access is revoked. Make it part of the offboarding checklist alongside laptop return and SSO removal. The export takes 30 minutes; the cost of not having it is months of reverse-engineering. If the offboarding has already happened, ask anyway — the data is the user's, not the company's, and most ex-CTOs are happy to share once asked.
2. Weeks 2–3. Run the extractor over the export (locally, on your laptop — no transcript leaves your machine). Get back 30–80 decision records. Spend an afternoon scanning them. Discard the noise. Tag the survivors by topic: stack, schema, pricing, hiring, migration.
3. Weeks 4–12. File the surviving decisions as ADRs in your repo (or as rows in your Notion database, whichever your team uses). Now when the board observer asks why Postgres, you can link them to the actual reasoning, with the actual rejected options, with the actual conditions for revisiting. Same for the next ten questions. You buy back six months of context in an afternoon of work.

The harder version of this problem

The real problem isn't onboarding once. It's that this is going to keep happening — to you, to whoever inherits the stack from you, to every CTO downstream. The fix isn't doing this exercise at handover; it's making decision-history capture a continuous practice. Treat the chat history the way the team treats the codebase: as an asset of the company, with a regular extraction cadence (we recommend quarterly) and a place where the durable records live. Going forward you don't have to be the new CTO — you can be the CTO who set this up so the next one isn't blindsided.

That's the longer-term promise. For today, the win is concrete: an afternoon of work, a one-click export, an extractor pass, a few dozen records you can actually point at when someone asks why.

Related questions

Further reading

• A worked ADR example: Postgres vs MongoDB — what a single decision record looks like end-to-end.
• How to export your ChatGPT history (2026) — the five-minute walkthrough.
• How to export your Claude conversations — the Anthropic equivalent.
• Decision log template (Free, Copy-Paste) — the simpler shape if your team isn't on ADRs.
• How to document architecture decisions — the 3+1 rule, what to record and what to skip.
• The open-source extractor — read the source, run it locally, no signup.
• adr-tools vs WhyChose — when each is the right tool.