Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Cognitive Load Theory to Structure Engineering Teams
Transcript
- Lucas: You've probably felt it: you're an engineer on three different projects, context-switching five times a day, and by Friday you've shipped almost nothing. There's a CTO I talked to who says that's not a time management problem — it's a cognitive load problem with how the team is structured. Luna: I've definitely been there. And 'cognitive load' is a term you hear a lot in learning theory, but less in engineering org design. How does it translate? Lucas: Right — it comes from educational psychology, specifically John Sweller's work in the 1980s. He broke cognitive load into three types: intrinsic — the inherent difficulty of the task itself; extraneous — the unnecessary overhead around the task; and germane — the mental effort devoted to learning and schema formation. Luna: So for an engineering team, intrinsic load is the actual complexity of the code and domain they own. Extraneous is all the friction around it — bad tooling, unclear requirements, too many meetings. And germane is the learning they need to do to get better. Lucas: Exactly. The CTO I spoke with — let's call her Sarah — runs engineering at a mid-sized SaaS company, about 120 engineers. She realized her teams were drowning in extraneous load because they each owned parts of six or seven different services. No team had a clear bounded context. Lucas: So she did something that's straight out of the Team Topologies book by Matthew Skelton and Manuel Pais: she mapped every service to a bounded context, then assigned each context to exactly one team. No shared ownership. Luna: That sounds clean in theory, but what about services that are really complex? A single domain might have too much intrinsic load for one team. Lucas: Exactly the question she faced. Take their payments system — it handled authorization, settlement, reconciliation, fraud detection. That's four different subdomains with different cognitive demands. So she split it into four teams, each owning one bounded context. The key heuristic she used: if a team's average pull request review cycle exceeds 48 hours, the cognitive load is too high. Luna: Forty-eight hours — that's a really concrete number. Did she see an improvement? Lucas: Dramatic. Before the reorganization, the team that owned the whole payments monolith had a lead time of about two weeks for any change. After splitting into four bounded-context teams, the authorization team — the highest-traffic one — got lead time down to two days. Their cognitive load dropped because they only had to hold the authorization domain in their heads. Luna: And the extraneous load from context-switching between fraud and settlement? Gone. Lucas: Gone. But there's a subtlety: Sarah didn't just split teams and walk away. She also created a platform team whose job was to reduce extraneous load for the stream-aligned teams. That platform team owned the CI/CD pipeline, the shared monitoring stack, and the internal developer portal. Luna: So the stream-aligned teams could focus on their intrinsic load, and the platform team absorbed the extraneous load of infrastructure. That's exactly the topology that Skelton and Pais recommend. Lucas: Right. And this connects directly to Conway's law — you know, 'organizations design systems that mirror their communication structure.' By aligning team ownership with bounded contexts, Sarah made sure the system architecture and the org structure matched. That reduced a huge source of extraneous load: the mental overhead of coordinating across teams that didn't have clear boundaries. Luna: I want to ask about the assessment itself. How do you actually measure cognitive load on a team? It's not like you can put a brain scanner on every engineer. Lucas: She used a combination of things. First, a simple survey: 'On a scale of 1 to 5, how often do you feel you have to hold more context than you can comfortably manage?' Second, she looked at objective signals — the 48-hour PR cycle heuristic, the number of active Jira tickets per engineer, the frequency of production incidents related to misunderstanding a service boundary. And third, she did what she called a 'team cognitive load mapping session' where the team drew their own architecture and annotated where they felt the most mental strain. Luna: That's a lot more granular than just looking at velocity charts. Did any teams push back on the split? I can imagine some senior engineers feeling like they were losing ownership of the 'whole' system. Lucas: Some did. One engineer had been the go-to person for the entire payments system for four years. He felt demoted when his scope narrowed to just authorization. But Sarah framed it as a depth versus breadth trade-off: 'You can now be the world's best authorization architect, or you can be mediocre at six things.' He ended up embracing it — and his team's incident rate dropped because he could focus. Lucas: There's also a germane load angle here. With lower extraneous load, teams had more capacity to learn. The authorization team started doing regular 'learning spikes' — time-boxed experiments with new technologies relevant to their domain. That's pure germane load, and it directly improved their system's resilience. Luna: If today's tech conversation gave you something usable — maybe the 48-hour heuristic or the idea of mapping bounded contexts to teams — we want to mention something about how this show stays on the air. We deliberately don't run ads on these conversations. If you want to support that choice, the link is buy me a coffee dot com slash fexingo. No perks, no tiers, just helping us keep this ad-free. Lucas: Yeah, and that support genuinely lets us dive deep into topics like cognitive load without worrying about sponsor messaging. Appreciate anyone who chips in. Luna: So back to Sarah's story — she also used Wardley mapping to decide which contexts should be built in-house versus bought or outsourced, based on how evolved the practice was. For commodity capabilities like authentication, she used an off-the-shelf provider. For core differentiators like the fraud model, she kept it in-house. Lucas: That's a smart way to manage intrinsic load: don't let your teams carry the cognitive burden of building something that's not strategic. Outsource the commodity stuff, and let your engineers focus on what gives you competitive advantage. Luna: Let's talk about the downsides. Did any of the new teams end up with too little cognitive load? Like, if a bounded context is too narrow, engineers might get bored or siloed. Lucas: That happened with one team that owned a very stable, rarely-changing reporting service. Their intrinsic load was low, but they felt disconnected from the product. Sarah's solution was to give them a 'rotation' — every quarter, one engineer from that team would join a stream-aligned team for a sprint. That kept germane load flowing. Luna: So the principle is: balance intrinsic load so it's not overwhelming and not under-stimulating. That's basically the Yerkes-Dodson law — optimal performance at moderate arousal. Lucas: Exactly. And the same principle applies to the platform team. If the platform team has too much extraneous load — too many requests from stream-aligned teams — they become the bottleneck. Sarah had to protect their time by enforcing a 'self-service first' policy: any request that could be automated had to be automated before the platform team would take another request of that type. Luna: That's a forcing function. It pushes the platform team to reduce their own extraneous load — and everyone else's — simultaneously. Lucas: Right. And the results were measurable. After six months, the company's overall lead time for changes dropped by 60 percent. The number of production incidents related to miscommunication between teams fell from an average of three per week to one per month. And engineer satisfaction scores on the 'cognitive load' question went from 2.3 to 4.1 out of 5. Luna: Those are compelling numbers. But I imagine this isn't a one-and-done exercise. As the product evolves, bounded contexts shift. Lucas: Sarah treats it as a quarterly review. Every three months, the team does a cognitive load assessment again, and they re-map the contexts if needed. She also uses the 'team cognitive load heat map' — a simple red yellow green visual of each team's load — in her quarterly planning review. It's become an input to the prioritization process. Luna: So cognitive load isn't just an engineering health metric — it's a strategic planning tool. Lucas: Exactly. And that's the key insight: most CTOs treat team structure as static or change it reactively after a crisis. Sarah treats it as a dynamic system that needs constant tuning based on cognitive load signals. It's a much more humane way to run engineering, and it produces better outcomes. Luna: I think the 48-hour PR heuristic is something any team can try tomorrow. Just measure your current PR cycle time, and if it's over 48 hours, start asking whether the team's cognitive load is too high. Lucas: That's a good takeaway. And if your team is split across multiple services, ask whether each service truly needs to be owned by that team, or whether you could carve out a bounded context that reduces the mental surface area. It might feel like shrinking scope, but it actually expands what the team can achieve. Luna: Before we go, any recommended reading beyond Team Topologies? Lucas: I'd point people to John Sweller's original papers on cognitive load theory — they're surprisingly accessible for academic work. Also, Ruth Malan's work on team topologies and domain-driven design. And of course, the DDD blue book by Eric Evans, especially the part about bounded contexts. Luna: Good recommendations. Episode 89 — cognitive load theory for engineering teams. Lucas, thanks. Lucas: Thanks, Luna. And thanks to everyone who supports the show at buy me a coffee dot com slash fexingo.