On Team Topologies and Deep Work: Delivering Value at Large Scale and Small Scale

This post is part of the Content Club, organized by Bryan Ross. The theme for February 2025 is “Team Topologies in the Real World”. Links to other posts in this group are at the end of this post.

I consider myself a big fan of the book Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais. It’s up there with the classic “Gang of Four” book¹ for me in that it’s a book that fundamentally transforms how you see the work that you’re already doing. I first read Team Topologies as a newish engineering manager, and came away from the book with both a new perspective on how work happens within an organization, as well as a new language and terminology that I could use to talk about it. I read Team Topologies again around the time I was leaving engineering management for a principal IC² role focused on building a new data platform, and again found it invaluable in helping me think through how value is created within, or by, a “platform team”.

Several months ago, Matthew Skelton made a post on LinkedIn announcing that he was starting a video podcast, and seeking nominations/suggestions on people to interview. I happened to see that post soon after it was published, and added a few suggestions of my own in the comments. At the time I had recently finished reading Cal Newport’s book Deep Work: Rules for Focused Success in a Distracted World (I’d actually read three of Newport’s books in the month prior, and would go on to read two more in the next two months). Newport has written several popular books about knowledge work and personal productivity topics³, while also being employed at Georgetown University as a professor of computer science.

In my LinkedIn comment I said that “I think that there is a lot of philosophical alignment between [Newport’s] writing on productivity at the individual level and Team Topologies at the organization level”. Before seeing Matthew’s post and making that comment, I don’t believe I had really thought much about these parallels, but the more I thought about it the more that I thought there was something there. At this point I’ve been noodling on this idea for four months, so it’s past time I tried to put into words why I think these two systems are similar, and why they complement one another so well.

Let me first make an analogy, to plainly state the premise: Deep Work is to individual value creation what Team Topologies is to organizational value creation. There are (at least) four ways in which this analogy manifests: a focus on managing cognitive load, on making implicit processes explicit, on designing the environment, and on doing less work (less work, but higher-value work).

Cognitive Load is the Bottleneck

Team Topologies and Deep Work are both in the vanguard here, both early adopters of the term “cognitive load” in the modern knowledge-work domain. There’s a limit to how much information you can hold in your brain at one time. If you have ever been interrupted while working on a task that required concentration, you’ve surely seen this play out at the small scale - you probably lost your train of thought, or had to spend time rebuilding your mental context before you could re-engage with that task after the interruption. Both Team Topologies and Deep Work treat the management of cognitive load as a fundamental concern. Team Topologies even leverages the constraints on cognitive load to help define team sizes and team boundaries:

When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.⁴

Newport similarly references research on deliberate practice and cognitive capacity to help define an individual’s capacity for cognitively demanding work: around an hour a day for a novice, as high as four hours a day for an expert.

In both frameworks, understanding cognitive load, both in its general effects and its specific limit, is an important factor, as the total cognitive capacity available (whether distributed across members of a team or concentrated in an individual) represents a firm limit on the system.

Structure Enables Focus

Both Team Topologies and Deep Work emphasize the importance of making implicit processes explicit. Team Topologies provides a “Team API” concept, a formally specified contract for the way that teams interact with one another. The team interaction modes at the heart of Team Topologies (Collaboration, X-as-a-Service, Facilitation) are also examples of this.

Similarly, Newport provides a number of structured work rituals and practices: a time-block planning system to break up the day into discrete blocks (each with a specific focus/goal), and an end-of-day work shutdown ritual (to help empty “working memory” into a durable tracking system) are two examples. (And of course when an implicit process is made explicit, cognitive load is reduced. You no longer have to remember it all - you can refer to it instead).

Environment Design can Facilitate Value Creation

One of the things that unites these two frameworks is that they don’t focus on the simpler question “how do we get better?” but instead go one step further and ask “how do we make ‘better’ happen naturally?”. One way to do this is to consider the environment in which work happens. Any given environment is more conducive to certain kinds of work than to other kinds, and by changing things about that environnment, we can make it more conducive to the kind of work that we want to see more of.

Team Topologies references Conway’s Law frequently:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.⁵

In fact Team Topologies uses what is perhaps my favorite term ever used in a business book, the Reverse Conway Maneuver: if Conway’s Law holds that organizations produce architectures that mirror their communication structures, than if you reshape the organization so that it has particular communication structures, it will naturally produce architectures with that same (desired} arrangement. (Skelton and Pais did not create this term, and Team Topologies is about much more than doing reverse Conway maneuvers, but it is a powerful example of desigining an environment to facilitate the creation of value).

An individual can’t do anything as dramatic as a reverse Conway maneuver, but Deep Work does still provide a number of strategies in the area of environment design. Many of these revolve around creating time and space that is conducive to deep work (to uninterrupted focus), perhaps by removing a cell phone to a different room during work hours, or by setting aside a particular working location for deep work time. Newport also suggests ways to get buy-in from a manager on how much time is spent on “deep” vs “shallow” work (this also falls under “making implicit processes explicit”).

For both Team Topologies and Deep Work, the question “how does work get done?” is something deserving of attention and optimization. Newport approaches this for himself as an art form that can be mastered:

I am going to be constantly evolving and optimizing my systems. I am going to treat the act of how I actually organize and execute my work as an art form that I am trying to master, and not just as an aside.⁶

Do Less Work, but Better Work

A fourth element shared by Team Topologies and Deep Work is a focus on sustainability. It’s not enough to do good work, or to do the right work, but that work also needs to be done in a manner which is sustainable.

Deep Work holds that it’s the focused, cognitively demanding work that really “moves the needle” in our careers, and as stated earlier, there’s a real limit on how much of that kind of work we can do. If you’re a concentration expert, you might be able to do twenty hours of deep work in a week. Rather that working long hours and doing more “shallow” work⁷ (answering emails, responding to questions, etc), focus instead on optimizing your deep work schedule, so that you can spend more time doing that kind of work.

Team Topologies tells us that a team shouldn’t take on too many responsibilities - they should own a well-defined domain and focus on excelling within it. The idea of teams owning a domain is well-established in the literature, but Team Topologies goes further than just “ownership”, to “care”:

Team ownership helps to provide the vital “continuity of care” that modern systems need in order to retain their operability and stay fit for purpose.⁸

Looking at a teams’s domain (or an individual’s) through the lens of “care” is, in my opinion, extremely powerful. “Care” incentives us to act sustainably - to ensure that we are giving our code regular attention (not just waiting until something breaks), that we are reserving slack capacity to account for unplanned work that may be needed, and so on. If you’re running pedal-to-the-metal to add as many features as you can, you’re not giving yourself the capacity that is needed for care. Create capacity for care.

Conclusions

Team Topologies by Matthew Skelton and Manuel Pais, and Deep Work by Cal Newport, complement each other well. Team Topologies is concerned with value creation by teams operating within a larger organization, while Deep Work is concerned with value creation by individuals in a knowledge-work field. The same basic advice is applicable in either framework, at either scale:

Pay attention to cognitive load
Define clear working agreements that make implicit processes explicit
Invest in creating an environment that is conducive to value-creating work
Operate sustainably with care for the long term

Cognitive Load is the Bottleneck#

Structure Enables Focus#

Environment Design can Facilitate Value Creation#

Do Less Work, but Better Work#

Conclusions#

Other Posts on “Team Topologies in the Real World”#

Cognitive Load is the Bottleneck

Structure Enables Focus

Environment Design can Facilitate Value Creation

Do Less Work, but Better Work

Conclusions

Other Posts on “Team Topologies in the Real World”