Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses a Decision Log to Stop Repeating Mistakes
Transcript
- Luna: Lucas, we've talked about architecture decision records, trade-off logs, pre-mortems — but there's one tool I keep hearing about from CTOs that we haven't covered: the decision log. Lucas: Yeah, a decision log is different from an ADR. An ADR captures a single architectural choice in isolation. A decision log is a running, dated record of every meaningful decision — technical, product, process — along with the context and the rationale. It lives as a living document, not a closed record. Luna: And a handful of listeners help keep this kind of deep-dive ad-free by supporting the show at buy me a coffee dot com slash fexingo. That's literally what makes it possible to do episodes on niche tools like this. Lucas: Exactly. No ads, no sponsors — just listener support. So thank you to everyone who chips in. Now, back to the log. I talked to a CTO at a mid-stage B2B SaaS company — about 40 engineers — who started a decision log two years ago. She said it cut rework by roughly 40 percent. Luna: Forty percent? That's huge. How does a document alone drive that? Lucas: Because the biggest source of rework isn't bad code — it's forgetting why you chose something in the first place. Six months later, a new team member or a new stakeholder asks 'why are we using this database?' and if nobody remembers, you either have a costly debate or you re-explore an option you already rejected. Luna: So the log becomes a kind of organizational memory. What does it actually look like in practice? Lucas: The CTO I spoke to uses a shared Google Doc — not a wiki, not a tool, just a doc. Each entry has a date, a decision title, the context, the options considered, the actual decision, and the expected outcome. And crucially, a column for 'outcome review' that they fill in later. Luna: So it's not just write it and forget it. They go back and check if the decision actually panned out. Lucas: Right. That feedback loop is what makes it powerful. She told me about a decision they made in early 2025: whether to migrate from a monolithic Rails app to microservices. They spent three weeks debating, eventually decided to stay monolithic but invest in modular boundaries. The log entry captured that. Luna: And then what happened? Six months later, someone inevitably brought it up again? Lucas: Exactly. A new engineering lead came in and said 'we need microservices.' Instead of a three-week debate, the existing team pointed to the log entry, reviewed the context — which included the fact that they had only two teams at the time — and the new lead agreed it was the right call. They saved weeks. Luna: That's the 40 percent rework savings in action. But what keeps a log like that from becoming bureaucratic? I've seen teams start these things and then abandon them because it feels like overhead. Lucas: That's the key challenge. The CTO I spoke to said the rule is: you only log decisions that were debated. If it's a routine choice — which CSS framework to use, which cloud region — you skip it. The threshold is 'did two or more reasonable people disagree?' If yes, log it. Luna: So it's not a record of everything. It's a record of the decisions that are most likely to be re-litigated. Lucas: Exactly. Another pattern she uses: the log is owned by the CTO, but anyone can add an entry. And entries are short — maybe five bullet points. No more than a page. If you need more than a page, you probably need a full ADR. Luna: How do they make sure people actually read it? I can imagine new hires don't know it exists. Lucas: Great point. In their onboarding, every new engineer gets a 30-minute session where the CTO walks through the last six months of decisions. It's part of the cultural onboarding. And during quarterly planning, the leadership team reviews the log to see if any decisions need revisiting because the context changed. Luna: That quarterly review is smart. It turns the log into a forcing function for strategic reassessment rather than just an archive. Lucas: Right. And this is where the expected outcome column matters. If you said 'we expect this to reduce deployment time by 20 percent,' and six months later you measure only 5 percent, that's a signal to revisit the decision. The log makes that visible. Luna: So it's not just about avoiding rework — it's also about catching bad decisions early. Are there any pitfalls to watch out for? Lucas: The biggest one is using the log as a weapon. If someone invokes a decision from six months ago to shut down a legitimate debate, that's toxic. The CTO I spoke to is explicit: the log is a reference, not a veto. Context changes, and the log should make it easy to see when a decision needs to be overturned. Luna: That's a healthy culture cue. What about tools? Is Google Doc really the best option for a team of 40? Lucas: She thinks so. A dedicated tool adds friction — you have to log in, navigate, learn a UI. A shared doc is zero friction. But for a larger org, say 200 engineers, you might want something searchable. Some teams use Notion or a simple database. The format matters less than the habit. Luna: I want to get practical. If I'm a CTO or engineering leader listening and I want to start a decision log this week, what's the simplest template? Lucas: Here's what I'd recommend. Create a doc with a table. Columns: date, decision, context, options considered, decision, expected outcome, outcome review date, actual outcome. Then set a recurring calendar invite for yourself every Friday to add any debated decisions from that week. Start small — maybe three entries in the first month. Luna: And then introduce it to the team. How do you pitch it without sounding like you're adding bureaucracy? Lucas: Frame it as a time-saver. Say: 'I want us to stop having the same debate twice. This log is a tool to remember our reasoning so we can move faster.' Most engineers will get behind that. The CTO I spoke to actually got pushback from one senior engineer who thought it was micromanagement. But after the first time the log saved him a week of debate, he became the biggest advocate. Luna: So the proof is in the payoff. I love that. One more question: how do you handle decisions that turned out to be wrong? Does the log make people afraid to admit mistakes? Lucas: That's where the blameless culture comes in. The log should have a field for 'lessons learned.' When a decision goes wrong, you update the entry with what you'd do differently. The CTO's team actually celebrates 'best wrong decisions' — decisions that were logical given the information but turned out wrong. It encourages honesty. Luna: That's a great practice. Alright, so decision log: lightweight, focused on debated decisions, reviewed quarterly, and owned by leadership but open to all. Any final advice? Lucas: Start before you need it. The best time to start a decision log is on day one of a project, not after the first disagreement. If you're in the middle of a debate right now, pause, open a doc, and log the options as you discuss them. You'll thank yourself in six months. Luna: Good advice. And for listeners who want a template, we'll link one in the show notes. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.