Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses a Decision Log to Make Every Call Auditable
Transcript
- Lucas: So there's a tool that CTOs swear by, and it costs nothing. No subscription, no integration with Jira, no AI. It's a plain shared document — sometimes a wiki page, sometimes a Google Doc — called a decision log. Luna: I've heard of architecture decision records, or ADRs. Is that what you mean? Lucas: Close, but broader. ADRs are typically for specific architectural choices — why we chose Postgres over MySQL, that kind of thing. A decision log covers everything: hiring a new vendor, changing the on-call schedule, deciding to deprecate a feature. It's a running, timestamped history of every meaningful call the team makes. Luna: And people actually keep up with this? That sounds like overhead. Lucas: It can feel that way at first, but the payoff shows up fast. I talked to a CTO at a company called Streamline — about 80 engineers — and she told me the decision log is the single most important artifact they created in the last two years. They started it after a particularly painful incident where three teams spent two months building a feature that leadership had decided to kill six months earlier. Nobody remembered the conversation. Luna: Ouch. So decision amnesia. Lucas: Exactly. The decision had been made in a hallway conversation between the VP of Product and the CTO. No email, no ticket, no minutes. Just a verbal agreement that never got documented. The feature made it onto a roadmap, got scoped, got coded, and only at the launch review did someone say, 'Wait, didn't we decide this was dead?' Luna: So the log fixes that by making every decision visible and dated. Lucas: Right. The format she uses is dead simple. Each entry has a date, a one-line decision statement, the context — what problem were we solving — the alternatives that were considered, and the expected outcome. Then, later, they can go back and check: did the outcome match expectations? If not, that's a learning signal. Luna: So it doubles as a feedback loop. Lucas: Exactly. It's not just a record — it's a tool for calibration. Over time, you can see patterns. Maybe your team consistently overestimates the impact of infrastructure changes. Or you notice that decisions made in the last hour of a Friday meeting are almost always revisited. The log surfaces those patterns. Luna: Do you have a concrete example of a log entry? Lucas: She showed me one from last October. Decision: 'We will adopt Tailwind CSS as our primary styling framework, phasing out Bootstrap over three sprints.' Context: the team was spending too much time overriding Bootstrap defaults, and design handoff was slow. Alternatives: keep Bootstrap, write custom CSS, use a css in js solution. Expected outcome: reduce styling-related tickets by 40 percent and speed up UI implementation by one day per feature. Luna: And did it work? Lucas: They checked six months later. Styling tickets were down 35 percent, not quite 40, but implementation speed improved. And because it was logged, the team could discuss why the number was off without re-litigating the whole decision. The log depersonalizes the conversation — it's not about who was right, it's about what the data says. Luna: That's really smart. I imagine it also helps new hires ramp up. Lucas: Huge. The CTO said onboarding used to involve a lot of 'well, we tried microservices two years ago and it didn't work' — but nobody could explain what 'didn't work' meant. Now the new engineer reads the decision log entry from 2024: 'Migrate auth service to standalone microservice. Context: monolith scaling issues. Alternatives: split billing separately, keep monolith, go full service mesh. Expected outcome: reduce deployment time by 50 percent. Outcome achieved: 30 percent reduction, but increased operational complexity. Conclusion: partial success, recommend revisiting after 2025.' That's so much more useful than hallway lore. Luna: It turns institutional knowledge into something concrete. I love that. Lucas: The discipline really matters. She told me they have a rule: any decision that involves spending more than ten thousand dollars or affects more than one team must be logged within 48 hours. There's a Slack bot that reminds people. And if a decision is reversed, the reversal itself becomes an entry, with a reference back to the original. Luna: Does the log ever get used against people? Like, 'See, you said this would work and it didn't'? Lucas: That's the risk. She was explicit that the culture matters more than the tool. The log is not a gotcha — it's a learning tool. They frame it as 'we were all wrong together' or 'the context changed.' She actually had to fire someone once who kept using the log to blame teammates. But that person was already a cultural problem. Luna: So it's a mirror for the team's maturity. You have to be ready for that transparency. Lucas: Absolutely. And it scales in interesting ways. As the company grew from 30 to 80 engineers, the log became a reference for the whole engineering org. Product managers started consulting it to understand why certain features were prioritized. The CEO even reads the weekly digest. Luna: A digest? Tell me more. Lucas: Every Friday, a script pulls the new entries from the past week and sends a one-page summary to the entire company. No detail, just decision, context, expected outcome. It takes thirty seconds to scan. That single habit stopped the 'nobody told me' syndrome cold. Luna: That's brilliant. It's like a release notes for decisions. Lucas: Exactly. And it's not just for tech decisions. They log policy decisions too — like changing the remote work policy or the expense approval threshold. The log becomes the company's memory. Luna: I'm sold. I'm starting one for my team tomorrow. Lucas: I think you should. And if you want to see how they structured theirs, they actually open-sourced the template. It's just a Markdown file with a table. The CTO said the hardest part wasn't the format — it was the habit. For the first month, they had to nag people every day. Luna: But once it became routine, it paid for itself in avoided confusion. Lucas: Exactly. And on that note — if today's tech conversation gave you something usable, a couple of dollars a month genuinely helps keep these shows ad-free and independent. Buy me a coffee dot com slash fexingo is where that works. No pressure, but if you've gotten value from episodes like this, it makes a real difference. Luna: Yeah, it's true. Even small contributions add up and let us focus on finding stories like this one. Lucas: So back to the decision log — one last thing she mentioned that I thought was clever. They added a 'revisit date' field. If a decision has an expected outcome that should be measurable in six months, they set a reminder to go check. That turns the log from an archive into a project management tool. Luna: That's a great idea. It closes the loop. You don't just log and forget — you actually follow up. Lucas: Right. And that follow-up is where the real learning happens. The log becomes a feedback system for the organization's decision-making quality. She told me they now run a quarterly review where they look at all decisions from the previous quarter and categorize them: good outcome, mixed, or missed. Then they discuss what they can improve. Luna: That's practically a decision post-mortem. I wonder how many companies do that. Lucas: Fewer than you'd think. Most teams are so focused on shipping features that they never step back to examine how they decide what to build. A decision log forces that reflection. It's a low-cost, high-leverage practice — and it costs nothing but a bit of discipline. Luna: I think that's the kind of thing that separates teams that just grow from teams that get smarter as they grow. Lucas: Couldn't have said it better. And that's the episode — go start your log.