Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Decision Logs to Stop Repeating Mistakes
Transcript
- Lucas: So a few months ago I was talking to a CTO at a fintech company — about sixty engineers, growing fast — and she told me about something she introduced that cost absolutely nothing and, in her words, 'saved us from ourselves.' Luna: I love that framing. What was it? Lucas: A decision log. Not an architectural decision record — those are formal, structured, you write them before you build. A decision log is looser. You write down a decision after you make it. Date, what you decided, why, what alternatives you considered, and — this is the part most teams skip — what you expected to happen versus what actually happened. Luna: So it's like a retrospective for a single decision. I've seen teams do that ad hoc, but not as a habit. Lucas: Right. The habit is the whole point. At that fintech, they had a situation where the data team rebuilt their event pipeline three times in eighteen months. Three times. Each time a new engineer or a new team lead came in, looked at the existing pipeline, said 'this is messy, let's rewrite it,' and nobody could explain why it was built that way in the first place. Because nobody wrote it down. Luna: Ouch. That's a lot of wasted engineering hours. Lucas: Exactly. So the CTO started a simple shared Google Doc. One table. Columns for decision, date, context, alternatives, expected outcome, actual outcome — leave that last one blank until later. She asked every tech lead to add one entry per week. That's it. No more than fifteen minutes per entry. After six months, they had about twenty-five entries. And when someone proposed a rewrite, they checked the log first. Luna: Did it stop the third rewrite? Lucas: It did. Someone added an entry for the second pipeline design, and it clearly documented that the team had already tried a similar approach and it failed because of a specific throughput bottleneck. The new lead read it, said 'oh,' and went back to optimising what they had. That one entry probably saved six engineering-weeks. Luna: That's the kind of story that makes you want to start one tomorrow. But I wonder — does it scale? Like, if you have two hundred engineers, a Google Doc gets unwieldy fast. Lucas: It does. At that size you'd want something more structured — maybe a lightweight tool like a wiki or a Notion database. But the principle is the same. The format should be so simple that the barrier to entry is basically zero. If you require a template with five sections and a review board, nobody uses it. Luna: Right. It's like flossing — better to do a mediocre job every day than a perfect job once. Lucas: That's exactly the analogy I used when I tried this with my own team. We started a Slack channel called #decisions. Every Friday afternoon, whoever wanted to could post a decision they made that week. No more than five sentences. We got maybe three posts a week. But after a year, that channel was a searchable archive of why we chose certain vendors, why we picked one framework over another, why we deprecated a service. It saved a lot of 'wait, why are we doing this?' conversations. Luna: And you can search it. That's a huge advantage over tribal knowledge that walks out the door when someone leaves. Lucas: Exactly. The CTO I mentioned actually told me that after two years, they had about a hundred and fifty entries. And they started reviewing the log quarterly as a team. They'd pick three decisions from the previous quarter and ask: did the outcome match the expectation? If not, why? That turned into a really honest conversation about how they were making decisions under uncertainty. Luna: That's where the real value is, I think. Not just the archive, but the reflection. It's like a lightweight post-mortem that doesn't wait for an incident. Lucas: Yeah. And it trains people to think about decisions more carefully in the moment, because they know they'll have to write it down later. It creates a little bit of accountability without being bureaucratic. Luna: So if someone listening wants to start this next week — what's the minimal viable version? Lucas: One shared document. Three columns: decision, context, and expected outcome. Leave actual outcome blank. Every engineer adds one entry per week. That's it. Don't overthink it. Luna: And if the team is distributed across time zones, a shared doc works even better because it's asynchronous. People can add entries when they have a moment. Lucas: That's a great point. The async nature actually helps — you get more thoughtful entries than you would in a meeting. And because it's written, it's searchable. New hires can catch up on the last six months of decisions in an hour. Luna: I also love that it surfaces who made a decision. Not in a blame way, but so you know who to ask for more context. Lucas: Right. And you can tag them. We used @mentions in the Slack version. If someone had a question about a decision from six months ago, they'd ping the person who wrote it. That person felt valued because their reasoning was still relevant. Luna: Okay, I'm convinced. I think I'll start one with my team next week. Maybe just one entry to begin with. Lucas: Honestly, that's how it starts. One entry. Then another. And before you know it, you have a history that helps you stop repeating mistakes. Luna: And that's the kind of thing that keeps listeners like us coming back to the show. If today's conversation gave you something useful, and you want to help keep these episodes ad-free and open to everyone, you can support us at buy me a coffee dot com slash fexingo. Just a simple way to say thanks and keep the ideas flowing. Lucas: Yeah, we really appreciate it. No pressure, but if it's made a difference in how you think about your team, that link is there. And now — back to decision logs. One thing I didn't mention: the CTO also used the log to identify patterns. She noticed that decisions made during the last week of a quarter were more likely to be regretted. So they started a rule: no major architectural decisions in the last two weeks of a quarter. Luna: That's a smart meta-insight. You wouldn't see that without the data. Lucas: Exactly. And that's the kind of thing that makes a decision log more than just a record — it becomes a tool for improving how you decide. Luna: So to wrap up: start small, one decision per week, write it down, review quarterly. Got it. Lucas: And if you do, let us know how it goes. We'd love to hear about a decision log success story. Luna: Or a failure. Those are just as instructive. Lucas: True. Either way, thanks for listening.