Get more done with less

This article is part of a series:

1. Team interactions must be designed for success

2. Get more done with less

3. Your teams are not call centers

---

If you know the enemy and know yourself, you need not fear the result of a hundred battles.

If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.

If you know neither the enemy nor yourself, you will succumb in every battle.

Sun Tzu, The Art of War.

In this most cliché quote from “The Art of War”, Sun Tzu warns of the dangers of going into battle without proper preparation. Most people take it at face value without questioning its meaning too much, but most people also haven’t read “The Art of War”.

If they had, they might remember that this famous quote is essentially the TL;DR of these five axioms:

• He will win who knows when to fight and when not to fight.

• He will win who knows how to handle both superior and inferior forces.

• He will win whose army is animated by the same spirit throughout all its ranks.

• He will win who, prepared himself, waits to take the enemy unprepared.

• He will win who has military capacity and is not interfered with by the sovereign.

If you look carefully at these statements, many parallels with today’s world emerge. We hire “armies” of engineers, only to fail at coordinating them effectively. We send them charging against vaguely defined objectives devoid of any strategy and tactics, and we’re shocked when they come back battered, burned out, and depressed.

So, as much as it is important to assemble competent teams, it’s equally important to know how to direct them. This doesn’t mean scheduling 120 standups per week; it means understanding the dangers ahead and planning how to tackle them.

Many of these “dangers” can be grouped under a singular umbrella term: Team Cognitive Load, which stems from the Cognitive Load Theory. The theory suggests a simple idea — the amount of information that one can hold in their brain at any given time happens to be quite limited.

It might seem moot, but many organizations completely disregard this knowledge.

So, before discussing team cognitive load further, let’s do a simple thought exercise. For each word in the following picture, read its color out loud. The color, not the word itself.

If you actually did the exercise, you’ve just experienced what it feels like when your cognitive load increases. While I’m sure you successfully pronounced all the colors correctly, I’m also sure you stumbled here and there, sometimes taking a few moments longer to say the proper color.

Know thine enemy

It just took adding one more variable, the mismatch between words and colors, to increase the cognitive load in the previous exercise. Just imagine how many things can go wrong when you consider a complex environment, like a team in an organization.

Teams suffer from cognitive overload just like individuals: when it becomes too much, even your best players will falter, and performance will inevitably decline.

Several forces silently contribute to increasing a team’s cognitive load, and while there are many, these are the most distinguishable ones. We have ordered them from the most ‘superficial’, easily detectable, to the most complex one, deeply rooted in how an organization is designed.

Tasks are assigned assuming zero existing workload

Imagine seeing someone carrying a heavy box up a flight of stairs. Would you toss more weight onto that box? Yeah, I didn’t think so. Then why is it that software tasks are assigned regardless of how much work currently exists?

Software complexity increases over time

The very nature of software development work leads to a progressive increase in complexity. As product requirements grow and change, the codebase must evolve to meet these new needs. While this isn’t inherently bad, it becomes a significant source of inefficiency if left unchecked.

Successful teams see their scope expanded

A team is particularly successful at managing a part of a system. Their manager signs them up to become responsible for other parts, thinking that they will be able to repeat their success.

“Congratulations on winning that marathon! Since you’re so good, next time, you shall run two at once!”

Domain complexity is ignored when assigning responsibilities

Due to a lack of proper organisational design, a single team might end up managing multiple complex domains. This often causes a team to fragment into many informal sub-teams, where specific tasks are picked up by those most familiar with each domain. However, the entire team is still expected to stay informed about everything all the time.

All these situations eventually lead to particularly cursed circumstances:

1. Wider blast radius when things go wrong. When a single team carries too many responsibilities, one problem can quickly multiply and get out of hand.

2. Constant context-switching. Managing multiple domains requires teams to jump between tasks, draining mental energy and lowering overall performance.

3. Broken communication lines. Fragmented expertise leads to challenges in communication and ownership, both internally and with stakeholders.

4. No time to grow. Teams stuck firefighting across domains rarely have the bandwidth to acquire new knowledge, or to review their own processes and improve their execution.

Team interactions are inefficient and overwhelming

Teams are often expected to welcome any sort of outside input or request with a smile, and those who try to regulate these interactions are seen as “bad team players.”

Nothing further from the truth.

In fact, not having clear, structured boundaries regarding cross-team communications is the perfect way to make everyone miserable.

A great example of this is organizations that overwhelm their teams with meetings by always including everybody in each one. On the surface, this might appear to be a useful approach. After all, how can more information be harmful?

Here’s how:

• Teams might feel like they’re pressured to know about everything at once all the time. This is a massive increase in cognitive load that no one can effectively withstand.

• Alternatively, once people realize that most communications are irrelevant to them, they simply stop caring altogether. Again, not ideal.

• Last but not least, there’s a phenomenon called Diffusion of responsibility, which states that the more people are aware of something, the less likely anyone is to take action. In other words, if you want something to never get done, make sure everyone knows about it.

The good news is that there are strategies that you can start applying right now to mitigate these issues and, eventually, minimize them.

A human-centric approach to org design

Like in therapy, the first step to solving a problem is recognizing you have one. Start by asking your teams questions like these (without any judgment): “Do you feel like you’re effective and able to respond to the work you are asked to do?”, or “How fast do you react to new work that is assigned to you?”.

While not a perfect measurement (after all, we’re entering the realm of human psychology), it’s sufficient to help you understand where you stand. It might be that your teams might not be feeling cognitive overload yet (especially if you’re at the beginning of a major project) or that they’re completely overwhelmed. Both options are entirely possible.

The second step of this journey is to start addressing problems from a team-first perspective. This is a good starting point for making sure that your organization is centered around humans rather than the technology they are working on.

Independent bodies of research found that team dynamics are a much better predictor of the team’s success than who’s on the team or how skillful they are. Therefore, to maximize your results, you should be looking forward to improving these dynamics as much as possible.

While several aspects should be considered when designing your teams, two of them are very easy to implement from the start.

1. Team size: smaller teams are more effective. A good rule of thumb is the two pizzas rule popularized by Amazon: a team should have no more people than what can be fed by two pizzas. Roughly 5 to 9 people. When teams are small, trust is much easier to build. Better trust, better results.

2. Team longevity: synergy takes time to develop. You can’t expect a group that just formed to have the same degree of effectiveness as a team that’s been working for months or even years. Therefore, don’t dismantle a team that works well together. Rather, make work flow to it. Which leads to the next step.

The third step is about defining clear boundaries about what each team should be dealing with.

Just like team interactions (check our previous article here), team cognitive load needs to be distributed intentionally and not left implied in technology choices and office politics.

In an ideal world, each team would be responsible for a single domain, but we don’t live in a utopia. However, we can still recognize that different domains can have different degrees of complexity and adapt accordingly: a team that owns a high-complexity domain should have no other responsibilities but that one. On the other hand, another team might be able to manage two or three low-complexity domains, as context switching between them requires minimal mental effort. Essentially, limiting teams' responsibilities allows them to perform their best.

The fourth and last step of this short guide is, again, about interactions across teams. How to make sure that your teams are not drowning in a sea of inefficient meetings, misunderstandings about each other’s responsibilities, fights over broken promises?

Team Topologies suggests a few strategies for this, including a simple, but powerful tool called Team APIs. This topic deserves a deeper dive, so we will discuss it in detail in the following issue. Stay tuned!