Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Cognitive Load Theory to Resize Teams
Transcript
- Lucas: Luna, I want to talk about a problem that almost every engineering leader I know has felt but can't quite name. Your team is, say, fourteen engineers. They're good. They ship code. But things feel sluggish. Pull requests sit open for days. The bus factor — you know, who'd be in trouble if someone got hit by a bus — is terrifyingly low. And the onboarding drag for new hires is brutal. Luna: Right, I think every manager has been there. It's that feeling that the team is too big to move fast, but nobody wants to admit it because breaking up a team feels like admitting failure. Lucas: Exactly. And there's a framework for thinking about this that most people don't use: cognitive load theory. It's not new — it comes from educational psychology, from a guy named John Sweller in the 1980s. But a CTO named Manuel Pais and his co-author Matthew Skelton brought it into software in their book 'Team Topologies.' The core idea is simple: every human has a limited working memory. You can hold about seven things in your head at once, give or take. But when a team has to hold the entire context of a large system, plus the business domain, plus the deployment pipeline, plus a dozen microservices, they're overloaded. And when a team is cognitively overloaded, they make slower decisions, they miss edge cases, and they burn out. Luna: So the argument is that we shouldn't size teams by headcount — we should size them by how much cognitive load the work imposes. That's a very different starting point. Lucas: Completely different. And a CTO I know at a mid-stage SaaS company — I'll call her Sarah, she asked to stay anonymous — she ran into this exact wall. Her team was building a platform for logistics optimization. Fifteen engineers, all in one squad. The codebase was a monolith that was being slowly decomposed into services. Every engineer had to know the entire business domain: routing, pricing, driver allocation, compliance, customer-facing APIs. And the work had slowed to a crawl. Luna: What were the signals? I mean, how did she know it was cognitive load and not just a bad manager or poor process? Lucas: Great question. She had three data points. One: code review latency. The median time for a PR to get a first review had crept up to almost 48 hours. Two: work-in-progress age. The average age of an open ticket was over three weeks. Three: the bus factor — she calculated it informally. She asked each team member which two parts of the system they felt confident modifying. Only two engineers were marked as essential for more than half the services. That's a bus factor of two. Luna: That's terrifying. If either of those two left or got sick, the team would basically stall. Lucas: Yeah. So what she did next is the interesting part. She didn't just say 'let's split into two teams.' She mapped every piece of work — every feature, every bug, every maintenance task — to the cognitive load it required. She used a simple framework: intrinsic load, which is the inherent complexity of the task; extraneous load, which is the overhead of context switching or bad tooling; and germane load, which is the productive learning that helps you get better. Luna: So she's applying the educational psychology categories directly to engineering work. How did that play out? Lucas: She found that the team was spending about 40% of its cognitive capacity on extraneous load — things like fighting with the CI pipeline, switching between the routing domain and the pricing domain, and attending status meetings that could have been async. Only about 30% was going to germane load — actually learning the domain and improving the architecture. So she made a decision: she split the team into three stream-aligned teams, each focused on one business subdomain: one for routing, one for pricing, one for driver compliance. Each team got five or six engineers. And she also created a small platform team of three people to own the CI/CD pipeline and the shared infrastructure, which removed that extraneous load from the stream teams. Luna: So the platform team basically absorbed all the extraneous cognitive load that was dragging everyone down. That's smart. What happened next? Lucas: Within two months, cycle time — the time from code committed to deployed — dropped by 40%. Code review latency went from 48 hours to under 6 hours. And the onboarding time for new engineers, which had been around eight weeks, dropped to four. Because now a new hire only had to learn one subdomain, not the entire system. Throughput, measured by story points delivered per sprint, increased by 37%. Luna: Those are big numbers. But I imagine it wasn't easy to get there. How did the team react to being split? Lucas: Mixed. Some engineers loved it — they finally felt like they could master a domain instead of being spread thin. Others missed the big-picture context. Sarah told me one senior engineer initially resisted because he felt like he was being 'demoted' from owning the whole system to just one piece. But she framed it differently: she told him that by focusing on one subdomain, he could become the world-class expert on it, and that his knowledge would be deeper and more valuable. He ended up becoming the tech lead for the pricing team. Luna: That's a good reframe. I think a lot of leaders underestimate how emotional team splits can be. People tie their identity to their scope. Lucas: Absolutely. And that's why cognitive load theory is useful — it gives you an objective framework to point to. You're not saying 'you're not good enough to handle the whole system.' You're saying 'the system has outgrown any one team's cognitive capacity, and this is how we're going to fix it.' It depersonalizes the decision. Luna: How about the platform team? Three people to own all the shared infrastructure — that sounds like it could become its own bottleneck. Lucas: It's a risk. But Sarah was careful to set boundaries. The platform team only owned things that were truly shared — the CI/CD pipeline, the deployment scripts, the monitoring stack, the artifact repository. They did not own any business logic. And they had a clear interface with the stream teams: they published their roadmap and accepted feature requests through a lightweight RFC process. Also, the platform team itself was sized for cognitive load — three people, one subdomain: infrastructure. That's a manageable load. Luna: So the same principle applies recursively. That makes sense. Lucas: Exactly. And this is where the Team Topologies framework really shines. It gives you four team types: stream-aligned, platform, enabling, and complicated-subsystem. Sarah only used stream-aligned and platform. But the key insight is that every team's cognitive load should be bounded by the team's ability to hold the full context of what they own. If you can't hold it, split it. Luna: It's almost like applying the single-responsibility principle to team design. Lucas: That's exactly what it is. And I think that's the big takeaway: treat your team boundaries like you treat your code boundaries. If a class is doing too many things, you refactor it. If a team is holding too many contexts, you refactor the team. Luna: So for a listener who's looking at their own team and suspecting cognitive load is the issue, what's the first step? Do the bus-factor calculation? Lucas: I'd start with a load map. Take every piece of work your team does over a month — every task, every meeting, every code review. Categorize it as intrinsic, extraneous, or germane load. Be honest. Then look at what percentage is extraneous. If it's more than 25%, you have a strong signal. Then ask: what would it take to carve out a platform team or an enabling team to absorb that extraneous load? You don't have to split the whole team overnight — you can start with a two-person platform squad and see if it helps. Luna: I like that. Start small, measure, iterate. Lucas: And the measurement part matters. After the split, Sarah tracked three metrics: cycle time, code review latency, and team satisfaction survey scores. All three improved. She also tracked bus factor and saw it go from 2 to 4. So she had data to back up the change when she presented it to her VP. Luna: That's a great example of making an org change evidence-based. I think a lot of CTOs make decisions based on gut feel, and this gives them a framework to be more rigorous. Lucas: Yeah. And I think it's worth saying that cognitive load isn't just about team size. It's about the complexity of the domain and the quality of the tooling. A team of six working on a highly coupled legacy system might be more overloaded than a team of ten working on well-encapsulated microservices. So it's context-dependent. But the principle holds: map the load, then design the teams to match. Luna: And if today's conversation gave you something useful to try with your own team, that's exactly why we make this show. We keep it ad-free and independent, and listener support is what makes that possible. If you find value in episodes like this one, you can support the show at buy me a coffee dot com slash fexingo. It helps us keep digging into the real decisions behind engineering leadership. Lucas: Absolutely. And speaking of digging into real decisions — let's talk about one more thing Sarah did that I think is underappreciated. After the split, she also changed how the teams did their planning. Instead of a full-team sprint planning with all fifteen people, each stream team did its own, and the platform team had a separate one. That alone saved about six hours of meeting time per sprint, which is extraneous load that got removed. Luna: That's a classic example of the hidden cost of large teams: meeting overhead scales quadratically. So by splitting, she not only reduced cognitive load on the work itself, but also on coordination. Lucas: Right. The coordination overhead is part of the extraneous load. And I think that's the final lesson: cognitive load theory isn't just about individual brain limits — it's about the system of communication that the org chart creates. Big teams create more communication channels, and each channel adds cognitive load. The optimal team size isn't seven plus or minus two — it's as small as possible while still having the full context of the subdomain. Luna: So maybe the real question every CTO should ask is not 'how many people do I need for this project?' but 'how many subdomains does this project contain, and what's the smallest team that can own each one?' Lucas: Exactly. And if you ask that question, you'll often find that the answer is 'smaller than you think.' That's the power of cognitive load theory applied to team design. It's a lens that cuts through the headcount politics and focuses on the work itself. Luna: I think that's a good place to leave it. For our listeners, if you want to dive deeper, the 'Team Topologies' book is a great starting point, but honestly, the first step is just the load map. Try it for a sprint and see what you find. Lucas: Yeah. And let us know how it goes. We're always interested in real stories from the trenches. Thanks for listening.