Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Code Reviews to Find Org Design Problems
Transcript
- Lucas: When a new CTO joins a company that's shipping too slowly, the usual first move is to look at the roadmap, or the team structure, or maybe the deployment pipeline. But there's a less obvious diagnostic tool that one CTO I know swears by: the code review. Luna: The code review? As in, looking at individual pull requests to figure out org problems? Lucas: Exactly. She joined a company with about 200 engineers — decent size, good talent, but feature velocity had been declining for six months. The obvious suspects — tech debt, test coverage, deployment frequency — all looked okay. So she started reading PRs. Not the code itself, but the metadata: who reviewed what, how long it sat, how many comments, what kinds of comments. Luna: That's... actually pretty clever. What did she find? Lucas: The first signal was that certain PRs had anywhere from six to ten reviewers. That's way too many. In a well-structured team, a PR should need maybe two or three reviewers max — one domain expert, one for style, maybe a second domain expert if it crosses boundaries. But here, every PR that touched even a shared utility would get pulled into a review vortex. Luna: So that suggests unclear ownership. Nobody knows who's responsible for that utility, so everyone feels like they should weigh in. Lucas: Right. And it gets worse when you look at comment patterns. She noticed a handful of senior engineers who left the same kinds of comments over and over — 'this pattern is inconsistent with the style guide', 'why aren't you using the internal library for logging' — things that should have been caught by automated linting or a pre-commit hook. Those comments weren't adding value; they were noise. Luna: But they also signal a trust issue. If the team doesn't have reliable automation, or if the style guide is too vague, then review becomes a manual gatekeeping exercise. Lucas: Exactly. And that gatekeeping creates bottlenecks. The data backed it up: the average time from PR creation to merge was five days. For a company with 200 engineers, that's brutal. A 2024 study on PR latency and Conway's Law found that teams with coupled ownership — meaning multiple teams responsible for the same module — saw PR cycle times three times longer than teams with clear boundaries. Luna: So she used the PR data to map the coupling. Who reviews whose code most often, where do the long delays happen, which modules attract the most reviewers. Lucas: Precisely. She visualized it as a graph: nodes were teams, edges were cross-team review volume. The picture was stark. One shared service library was being reviewed by four different teams, none of whom felt they owned it. And there was a team called 'Platform' that was supposed to own it, but they were reviewing it less than the others — which told her they'd effectively abdicated. Luna: So what did she do? Reorg based on the PR graph? Lucas: Not a full reorg. She made two surgical changes. First, she merged the two teams that were most tightly coupled — they were effectively one team already, just with different managers. Second, for that shared library, she made the Platform team formally accountable, and she required that any PR touching it must have at least one Platform reviewer, but no more than two total. She also added a linter rule that enforced the style guide points that kept coming up in comments. Luna: And the result? Lucas: Within two months, the average PR cycle time dropped from five days to under two. Not just because of the structural changes, but because the team no longer had to wait for a crowd of reviewers. The automation caught the trivial stuff, and the remaining reviews were focused on what actually mattered — logic, security, architecture. Luna: I love that she used the reviews themselves as the data source. It's like using the exhaust fumes to diagnose the engine. Lucas: Exactly. And there's a broader principle here: any process that generates structured metadata — review assignments, comment counts, cycle times — can be mined for org signals. The challenge is that most managers look at the code review as a quality gate, not a telemetry feed. But if you step back, it's a rich dataset about how work flows through your organization. Luna: What are some other signals you've seen in practice? I'm thinking about PRs that sit idle for days with no comments — that could be a sign that reviewers are overwhelmed or that the PR is too large. Lucas: Both. A PR that's over 500 lines is statistically more likely to get a cursory review or get ignored. One study showed that PRs over 1,000 lines have a 40 percent chance of receiving no meaningful comments — just a rubber stamp or silence. And silence is dangerous because it looks like approval but often means nobody had time to properly review it. Luna: So a high volume of silent approvals might indicate that your senior engineers are too busy to do thorough reviews. That's a capacity problem, not a process problem. Lucas: Exactly. And if you see that pattern concentrated in one team, it's a signal that team is overworked. The CTO I mentioned also looked at 'reviewer churn' — how often a reviewer is assigned but then removed or replaced. That turned out to be a strong indicator of unclear ownership. If a PR starts with one reviewer and then gets reassigned twice, it usually means nobody knows who should be the primary reviewer. Luna: That's a really practical heuristic. I'm going to start looking at my own team's PR dashboards differently now. Lucas: If today's tech conversation gave you something usable — maybe a new way to look at your own team's PRs, or a fresh lens for org design — that's exactly the kind of thing that keeps this show ad-free and sustainable. A couple of dollars a month at buy me a coffee dot com slash fexingo genuinely makes a difference in keeping these conversations going. Luna: Yeah, I know a lot of our listeners have mentioned that the practical angles are what they come back for. It's nice to know that even a small contribution helps us keep the focus on real cases and real numbers. Lucas: So back to the code review as an org sensor: what I find most powerful is that it's already happening. You don't need to schedule a survey or set up interviews. The data is being generated every day, and it's free for the taking. Luna: But you do need the right tooling to surface it. Most code review tools have dashboards, but they show averages — average time to merge, average comments per PR. The signals she used were more granular: distributions, outliers, patterns across teams. Lucas: Right. She exported the PR data and built a simple script to tag each comment by category — style, logic, architecture, security. That's not hard to do with a bit of regex, and it gave her a heatmap of what kinds of issues were burning the most review cycles. The top category was style — 40 percent of all comments. That's a huge waste. So she invested in automated formatting and linting, and within a month style comments dropped to under 10 percent. Luna: That's a 30 percent reduction in review load just from automation. And that freed up senior engineers to focus on the harder stuff. Lucas: Exactly. And that's the virtuous cycle: less noise in reviews means faster merges, which means more time for actual development, which means feature velocity goes up. The CTO told me that after six months, the team was shipping about 30 percent more features per sprint, and developer satisfaction scores went up because people hated the long review waits. Luna: Do you think this approach works for small teams too? Say, a ten-person startup? Lucas: I think it's even more useful for small teams, because the signal to noise ratio is higher. With ten people, if one person is reviewing everyone's code and they're the bottleneck, it shows up immediately in the PR data. And you can fix it — maybe that person needs to delegate, or maybe they need to stop reviewing style and only review logic. The patterns are the same, just at a smaller scale. Luna: One thing I'd add: this works best if your team already uses pull requests. Some teams do trunk-based development with direct commits. In that case, you'd need a different sensor — maybe deployment frequency or build breakage. Lucas: Fair point. But even teams that use trunk-based development often have some form of code review, even if it's post-commit. And the same analysis applies — look at who reviews whose code, how often, and what kinds of comments get left. The principle is universal: any structured feedback loop leaves a trace. Luna: I think the takeaway for me is that org design doesn't have to be abstract. You can ground it in actual work artifacts. And code reviews are one of the richest artifacts we have. Lucas: Absolutely. The next time you're frustrated with slow reviews or unclear ownership, don't guess. Pull the data. It's already there, and it's probably telling you exactly what's misaligned.