Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Used a Decision Log to Make Every Call Auditable
Transcript
- Lucas: So there's this practice that a lot of engineering teams talk about but very few actually do consistently: keeping a decision log. I'm not talking about meeting minutes or some random Slack thread. I mean a structured, searchable record of every significant decision the team makes — the context, the alternatives, the reasoning, and who was involved. Luna: Right, like an Architecture Decision Record but applied more broadly. I've seen ADRs used for technical choices, but you're saying extending that to product and process decisions too? Lucas: Exactly. And the CTO of a mid-size SaaS company — about 80 engineers — she started doing this about two years ago. She told me the trigger was realising that the same debate about whether to migrate from PostgreSQL to a document store kept resurfacing every six months. New engineers would join, ask why they weren't using MongoDB, and the team would re-litigate the whole thing from scratch. Luna: That's incredibly wasteful. So she started logging the decision with the context, the trade-offs, and the conclusion — and then just pointed people to that entry. Lucas: Right. But what's interesting is that she didn't stop at technical decisions. She started logging product prioritisation decisions too. For example, why they chose to build an internal API gateway instead of buying one, even though the build would take three months. The log entry included the cost estimates from three vendors, the projected maintenance burden, and the decision criteria. Luna: And that becomes an audit trail. Six months later when someone asks 'why didn't we just buy that thing?', you have the answer with data, not just memory. Lucas: Exactly. But the real payoff came when she used the log to detect patterns. She went back over the last year of entries — about 200 decisions — and categorised them by type. What she found was that about 60 percent of their decisions were reactive: responding to an incident, a customer complaint, or a competitive threat. Only 40 percent were proactive. Luna: That's a pretty telling ratio. Did she do anything with that insight? Lucas: She started a quarterly review where the leadership team looks at the decision log and asks: 'Are we spending our decision-making energy on the right things?' They began deliberately allocating two proactive decisions for every reactive one. It changed their roadmap. Luna: I love that. It's like a lightweight version of a decision audit. But how do you avoid the log becoming just another documentation burden that nobody reads? Lucas: Great question. She kept it lightweight. Each entry is exactly one page in a shared wiki. It has five sections: date, decision, context, alternatives considered, and rationale. No more. She also made it a rule that any decision that affects more than one team must have an entry within 48 hours, or the decision is considered provisional. Luna: So there's a gentle forcing function. I can see that working for a team of 80, but what about a startup with five engineers? Does this scale down? Lucas: Good question. I think it does, but the bar for what counts as a 'significant decision' has to be lower. At a five-person startup, maybe you only log decisions that have a clear cost of being wrong — like choosing a tech stack or a pricing model. Not every daily choice. The CTO I spoke with started small too: just the database decision and one product pivot. Then the team saw the value and started adding more. Luna: Right, so it's a practice that grows organically. What about the concern that logging decisions slows you down, especially in a fast-moving environment? Lucas: The counterintuitive thing is that it actually speeds things up over time. She said that in the first three months, the log felt like overhead. But after six months, the number of repeated debates dropped by an estimated 40 percent. New engineers onboarded in half the time because they could read the log instead of hunting down the person who made a call two years ago. And when they did post-mortems after incidents, they could trace exactly which decisions led to the current state. Luna: That's compelling. And it also surfaces when a decision was made with incomplete information, so you can revisit it later. Lucas: Exactly. She had one case where they decided to use a particular caching layer based on a vendor's throughput claims. Six months later, when performance issues emerged, the decision log showed that they had accepted those claims without independent testing. So they knew exactly where to tighten their process. Luna: That's a really concrete example. So what's the one thing a CTO should do tomorrow if they want to start a decision log? Lucas: Pick one decision that keeps coming back — the one that people debate every few months — and write it up. Just that one. Use the five-section format. Share it with the team and say 'next time this comes up, we start here.' See how that feels. Then add another one the next week. The key is to start small and make it useful, not perfect. Luna: I like that. It's very un-sexy but incredibly practical. Sort of like flossing for your team's institutional memory. Lucas: Exactly. And speaking of things that are un-sexy but practical — we deliberately keep this show ad-free because we think that kind of straightforward, no-nonsense advice is worth sharing without interruption. If you find these conversations useful, the simplest way to support that choice is buy me a coffee dot com slash fexingo. Just a way to keep the signal clean. Luna: Yeah, it's a small thing that makes a big difference for us. Keeps everything focused on the content. Lucas: So back to decision logs: the other thing that surprised me was how the log became a tool for inclusion. When you write down who made the decision and who was consulted, you start to see patterns — like, are the same three people always in the room? Are junior engineers ever on the list? She used that data to make sure diverse perspectives were included. Luna: That's a really thoughtful layer. It turns a documentation practice into a culture tool. I can see that being especially powerful for remote teams where informal hallway conversations don't happen. Lucas: Absolutely. And it's one of those practices that costs almost nothing to start but compounds in value over time. The log becomes a map of how the organisation actually thinks. Luna: Alright, I'm going to start one. Just one decision this week. Lucas: That's all it takes. One decision, and then you'll see.