Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One Team Uses Decision Logs to Stop Repeating Mistakes
Transcript
- Lucas: You know, I've been thinking a lot about something we see at almost every company we work with: teams making the same mistake twice. Luna: Oh, definitely. It's like Groundhog Day for engineering decisions. Lucas: Right. And there's a surprisingly low-tech fix that I've seen work really well — decision logs. Not post-mortems, not incident reports — just a running document where the team captures every significant decision, why they made it, and what they expected to happen. Luna: So almost like a lightweight version of an architecture decision record, but for all kinds of decisions, not just architecture? Lucas: Exactly. I first saw this at a company called Pragma — about sixty engineers, mid-stage startup. They had a recurring problem: every few months, someone would propose switching their database from PostgreSQL to something else, and the team would spend weeks debating it. Then six months later, the same debate would happen again. Luna: That sounds exhausting. And expensive. Lucas: It was. So the CTO started a simple shared document — a Google Doc, honestly — called 'The Decision Log.' Every time they made a non-trivial choice, they'd write down the date, the decision, the context, the options considered, and the expected outcome. Then, later, they'd go back and note what actually happened. Luna: Did it actually stop the recurring debates? Lucas: Pretty quickly. The next time someone brought up switching databases, the CTO just pointed to the log entry from eighteen months earlier. It showed why they chose not to switch, and — more importantly — the follow-up note showed that the decision had worked out well. The debate basically ended in five minutes. Luna: That's powerful. So it's not just about documentation — it's about creating a feedback loop. Lucas: Exactly. The log becomes a source of truth. But I think the real magic is that it builds institutional memory. In a startup, people leave, new people join — and without a log, the collective knowledge walks out the door. Luna: Right. And it's cheap. No tooling required. Just a document. Lucas: And that's the beauty of it. But there's a pitfall: if you try to document everything, nobody will use it. The CTO at Pragma learned this the hard way. They initially tried to log every single pull request discussion, and the log became a wasteland. Luna: What's the right threshold, then? How do you decide what goes in? Lucas: He settled on a simple rule: if a decision took more than thirty minutes of discussion in a meeting, or if it's a choice the team has debated before, it goes in the log. Also, any decision with a significant impact on cost, performance, or developer experience. Luna: That makes sense. And it's still lightweight enough that people actually contribute. Lucas: Yeah. After six months, they had about forty entries. And the team reported that they spent sixty percent less time rehashing old arguments. That's a huge win. Luna: I wonder though — does this ever stifle healthy debate? Like, could someone use the log to shut down a legitimate alternative? Lucas: That's a great point. The CTO was careful about that. He framed the log as a starting point, not a veto. Any previous decision can be revisited if the context has changed — new technology, new scale, new team. The log just forces you to engage with the past reasoning before making a new call. Luna: So it's more about intellectual honesty than bureaucracy. Lucas: Exactly. And there's a second-order effect I really like: it reduces decision fatigue. When you know you don't have to re-litigate every choice from scratch, you have more mental energy for the truly novel problems. Luna: Speaking of mental energy — if this episode gave you something useful today, honestly, if it was worth a coffee to you, that's the link — buy me a coffee dot com slash fexingo. We keep the show ad-free, and listener support is what makes that possible. Lucas: It's a small way to say this kind of deep-dive content matters. And we're grateful for every single contribution. Luna: Right. So back to decision logs — I want to talk about the format. What does a good entry actually look like? Lucas: The best ones I've seen have five sections: context, options, decision, rationale, and outcome. Context explains the problem or opportunity. Options lists the alternatives considered, even the ones that were rejected. Decision is the choice made. Rationale explains why — ideally with specific criteria. Outcome is filled in later when the results are clear. Luna: And outcome is the part that most teams skip, isn't it? Lucas: Absolutely. That's the loop-closing step. Without it, you're just keeping a diary, not a learning tool. At Pragma, they set a calendar reminder every quarter to review old entries and update the outcome field. That's when they discovered that one of their early decisions — to use a specific cloud provider — had actually led to higher than expected costs. Luna: So the log itself helped them correct course. Lucas: Exactly. They were able to revisit that decision with real data instead of speculation. And the log entry became a case study for the whole company. Luna: I love that. It turns documentation into a continuous improvement engine. Lucas: And it's not just for technical decisions. Pragma also logged some organizational ones — like how they decided on their on-call rotation structure, and why they chose to invest in a platform team. Those entries became onboarding material for new managers. Luna: So it scales from the engineering team to the whole company. Lucas: Right. And it's free. The only cost is the discipline to write it down. But that discipline pays for itself the first time someone says 'Didn't we already decide this?' and you can point to the answer. Luna: I'm sold. I'm starting a decision log for my team tomorrow.