Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Automated Technical Decision Making
Transcript
- Lucas: I was talking to a CTO last month — runs a SaaS company, about 80 engineers — and she told me something that stopped me cold. Luna: I'm listening. Lucas: She said her team was spending roughly 15 percent of every sprint just debating architecture decisions. Not coding, not reviewing — arguing. What database? What API pattern? Should we use a queue or just a webhook? Luna: Fifteen percent — that's like one day per developer per two-week sprint, gone. Lucas: Exactly. And the crazy part is, most of those decisions had already been made before, just not written down in a way anyone could find. So she built something she calls an 'automated decision record' system. And it's not about writing more docs — it's about making decisions machine-checkable. Luna: Okay, I need to hear how that works. Because every team I've seen tries to document decisions and the docs rot on a wiki page. Lucas: Right. The classic problem. So here's the approach: every significant technical decision — say, using PostgreSQL over MySQL, or adopting a particular event schema — gets written up as a lightweight Request for Comments document. Not a novel. A few paragraphs, the decision, the rationale, and a set of machine-readable tags. Luna: Tags like what? Lucas: Things like 'database', 'messaging', 'authentication'. Also a status: proposed, accepted, deprecated. Then she wrote a small linter that runs on every pull request. If your PR introduces a dependency on MySQL, the linter checks: has the team explicitly accepted MySQL? If not, it flags the PR and links to the RFC process. Luna: So the automation doesn't block you — but it surfaces the decision gap immediately. Lucas: Exactly. It's like a type system for architecture. The linter doesn't say 'no', it says 'hey, this hasn't been decided yet — here's the template for the RFC.' And the RFC itself is a pull request into a decisions repository. So you get a history, review, and approval all inside GitHub. Luna: I love that it's encoded in the same workflow developers already use. Lucas: That was the key insight. She told me they tried a wiki page and a Slack channel before. Both failed because they were outside the development loop. But once the linter started flagging decisions in PRs, adoption went from 20 percent to 90 percent within two months. Luna: And did the arguing drop? Lucas: Dramatically. She measured it. Before the system, they averaged about 12 minutes per developer per day on decision-related Slack threads. After, it was under 2 minutes. That's about 40 hours a week saved across 80 engineers. Luna: Worth a coffee, honestly. Lucas: If today's tech conversation gave you something usable, that's the link — buy me a coffee dot com slash fexingo. Luna: Yeah, it's how we keep this thing ad-free and focused on real engineering practices. Lucas: So back to the decision records — the other thing she noticed was that onboarding new engineers got faster. New hires could read the accepted RFCs and understand why the architecture was the way it was, without having to track down senior devs. Luna: That's a huge hidden benefit. I bet it also reduced the 'tribal knowledge' problem where only three people know why we use Kafka instead of RabbitMQ. Lucas: Precisely. She said her time to first pr for new hires dropped from two weeks to four days. And the interesting thing is that the linter didn't just enforce decisions — it also surfaced stale ones. If a decision was accepted but everyone kept working around it, that was a signal the decision was wrong. Luna: So the system actually helps you evolve the architecture. Lucas: Right. They added a 'deprecation' workflow. If the linter sees a pattern that contradicts an accepted decision too often, it files an issue suggesting the decision be revisited. That turned the system from a rigid enforcer into a living governance tool. Luna: What was the hardest part of implementing this? Lucas: She said the initial pushback was from senior engineers who felt the linter was 'bureaucracy.' The framing mattered — she called it 'decision support' not 'decision enforcement.' And she let teams opt in at first. One team tried it, saw the benefit, and the others followed. Luna: Classic change management. Let the results speak. Lucas: Yeah. And she also made sure the linter's messages were helpful, not shaming. They wrote them with a friendly tone: 'Looks like you're using a new database — mind creating an RFC so we can discuss?' Luna: That's smart. Developers hate being yelled at by a bot. Lucas: Exactly. The linter even had a link to a template. So the path of least resistance was to do the right thing. And once the RFCs were there, they became a reference point for code reviews. Reviewers could say, 'Per RFC-42, we decided to use the repository pattern here.' Luna: That must have sped up code reviews too. Lucas: It did. Review time dropped by about 20 percent. Because a lot of review comments used to be about 'why did you do it this way?' Now the answer is already documented. Luna: What about decisions that are too small for an RFC? Lucas: Good question. She had a threshold: if it takes less than a day to revert, it doesn't need an RFC. The linter only flags things that have architectural impact — like adding a new service, choosing a database, or introducing a new communication protocol. Luna: So it's not for every variable name choice. It's for the stuff that matters. Lucas: Exactly. And the system had a nice side effect: it made architectural decisions visible to non-technical stakeholders. Product managers could look at the RFC repo and see what decisions were being made and why. That improved trust. Luna: I can see that. Instead of 'the engineers are just building whatever they want,' there's a transparent record. Lucas: Right. And she told me the most surprising metric was that defect rates dropped by about 15 percent in the first six months. Because decisions were thought through and documented, there were fewer last-minute 'oh, we should have used a different approach' reworks. Luna: That's a strong ROI for what's essentially a linter and a folder of markdown files. Lucas: It's a great example of how a small investment in process — if it's the right process — can pay off across the whole engineering org. And the best part is, it's open source. She released the linter and the template on GitHub. We'll link it in the show notes. Luna: Nice. So any team can try this out without a big vendor pitch. Lucas: Exactly. And I think the deeper lesson is about reducing cognitive load. When developers don't have to re-litigate the same decisions, they can focus on the novel problems. That's where the real value is. Luna: I'd love to hear if any listener implements this and sees similar results. Lucas: Same. And if you do, hit us up — we might do a follow-up episode with your story.