Pixar is a really interesting company. They started doing research on computers and images, turned into a technology company and then moved to their aspiration of creating animation feature films. The book Creativity, Inc. [1] tells their story starting from its inception by George Lucas, then the acquisition by Steve Jobs until their association with Disney. The author, Ed Catmull, former president of Pixar Animation, explains that just after they released Toy Story they created a Pixar University, initially meant to deliver training on their proprietary software but soon after they included other topics.

They introduced a course to teach everybody in the company to draw, even though they already had people who could draw beautifully. They did it because they thought there is something underlying the process of drawing that everybody needed to understand. They taught workshops based on the 1979 book by Betty Edwards Drawing on the Right Side of the Brain [2] to improve observation skills. Edwards’ book uses the concepts of right and left brain, being the left verbal and analytical and the right more visual and perceptual. Part of the process of learning to draw is learning to see, and in order to achieve this, you need to shut down your left side of the brain.

For example, when you try to draw a chair, you know it has four legs and you’ll try to represent that mental model from your head, regardless of whether you see the legs or not. People who draw better can set aside their preconceptions. It is important to disconnect from language and logic when we are drawing and focus only on what we are seeing now.

There are different ways to train for this. One is placing the model we are trying to draw upside down so that the student cannot recognise the object and sees just only shapes. The left side of the brain will not step in because it sees no familiar references. The right side of the brain will work only on sizes and relative distances of what is seen.

Another technique is to ask students to draw “all that is not the object”. To draw the contours, the surroundings, the boundaries that define what is not the object to draw: the negative space. In the example, when drawing the negative space of the chair, the student is not going to use their mental model of the chair and the proportions are going to be taken more easily, focusing only on what’s in front of them. There is not going to be any meaning added to what is seen, suspending all previous knowledge, all judgement, and all the impulses that can distort their vision.

As fascinating as it is, this is not about drawing, but about being able to see “what is not there”.

Shaping the organisation

In Team of Teams [3, Ch. 138] the author mentions the acronym MECE (pronounced mee-see), which stands for “mutually exclusive and collectively exhaustive”. A MECE breakdown has the intention of dividing a whole into a series of categories that do not overlap but together cover everything. An org chart has the intention of being a MECE structure: nobody assumes there is going to be something left uncovered and there is a lot of effort in clarifying responsibilities that do not overlap.

Even though that is the intention, eventually you will find elements in the organisation that are not covered or that have duplication. From there, you can delineate the negative space of the organisation.

Going back to the org chart, the hierarchy clarifies the assignment of responsibilities, useful when there is arbitrage needed. If something is not clear at the team level, the Team Leader can step in to clarify. When something is not clear between teams, the supervisor of the group of teams can solve the dispute. But when the differences are in something that is not in the defined responsibilities of any team, the negative space, it is hard to tell looking at the org chart who has to help with the problem and the question may be left forgotten until it becomes a serious problem. Who owns it? Who has to coordinate? Should the CEO intervene? That would not make sense.

Mechanical solution

An approach to solve this problem, presented in a different way, suggests eliminating the space in between the teams. The book Team Topologies [4] suggests that the organisation should be structured in a way that the smaller actor is the team (not the individual), teams interact in clearly defined modes (collaboration, as a service or as facilitators) and there are four types of teams: stream-aligned teams (the preferred type), enabling teams, complicated subsystem teams and platform teams.

Authors of this solution obviate the structures above the teams, the management, and external companies. Their promise is that any dependency between multiple teams is solved through a platform.

I agree they provide a very valid thinking tool and a good vocabulary to talk about teams and their relationships. Even I accept that their solution could improve certain organisations, but I don’t think it’s applicable in all environments.

It is complex

Maybe we are asking the wrong question. We are trying to find the pieces that form an organisation and put them together to build the whole puzzle. We are thinking about the organisation as if it was a machine and we need to find the solution. Where is the missing piece?

General McChrystal, trying to improve adaptability over efficiency, found that anti-MECE organisations worked better. The redundancy of responsibilities creates inefficiencies that allow adaptability and efficacy [3, p. 139]. “Great teams are less like ‘awesome machines’ than ‘awesome organisms’.”

An old parable goes like this: Three blind men, who have never come across an elephant, try to learn what it is by touching it. One of them says “it’s like a tree”, while hugging its leg. Another one says “I have the real facts and it is wide and broad, like a rug”, touching the ear. The third man, reaching out the trunk says, “you all are wrong, it is like a snake”. All of them were wrong and all of them were partially right [5].

A system is more than the sum of its parts [6, p. 11]. I tend to use the language of machines and factories when talking about teams, input and output. It’s easy to understand but I am perpetuating the image of the machine.

While we find a better language (living organisms? gardens?[7]) we can talk about the negative space to think on how to improve the way we work.

Toni Tassani — 11 April 2022

This article was originally published on 1 March 2021 on the Ocado Technology intranet.

The term team is a confusing one and we should do better clarifying what we mean when we use it. In the book Team Topologies [1, p. 32] they explicitly define it as:

In this book, “team” has a very specific meaning. By team, we mean a stable grouping of five to nine people who work toward a shared goal as a unit. We consider the team to be the smallest entity of delivery within the organization.

The Cambridge Dictionary definition says something like “a number of people who do something together as a group”. Other definitions include “to achieve their goal”. These definitions work also for company or organisation, as well as for team. And we easily use the term for a group that “does the work” and we also use it for a “senior leadership team”. In fact, one of the best sellers on team performance, The five dysfunctions of a team [2], is about a leadership team. Why don’t we talk about “a team of Team Leaders” or a “team of Engineering Managers”?

In Team of Teams [3] General McChrystal describes how a military organisation became more adaptive, using the term team without defining it. In Superteams [4] Khoi Tu uses the term team to describe groups and organisations as disparate as Pixar (a company), the Red Cross (an NGO), a Ryder Cup team (a team of golf players), SAS (a military unit), the Northern Ireland peace process participants, Ferrari F1 and The Rolling Stones. Team is a flexible term.

Groups of people

There are many possible compositions for groups of people doing something together. Talking about sports, we understand a basketball team, an American football team and a judo team will work in different ways. Some sports require all participants working together like in basketball, others require specialised teams like defence and attack in American football and in other sports participants work in isolation or in turns, and then they sum their score, like in judo or bowling. Even in sport, team has different meanings.

Research on team performance has shown that the team construct is not always the best solution to solve problems [5, Ch. 2]. The same author, social psychologist Richard Hackman, identified the optimal conditions for an effective team [6, Pt. II]:

• Create a real team
• Set a compelling direction
• Provide an enabling structure
• Establish supportive context
• Arrange for expert coaching

The same author also identifies different types of collaboration that could fall into a wide definition of team [5, Ch. 2]:

• Community of interest
• Community of practice
• Emergent collaboration
• Coacting group (work in parallel, but do not have collective accountability)
• Distributed team
• Project team and task force
• Semi-permanent work team

The agile literature has made prevalent other concepts like high-performance teams, the Tuckman model of group formation [7] (the forming, storming, norming, performing, adjourning litany), and stable teams, even though now there are voices questioning some of the ideas [8].

Self-organisation is another widespread concept. Hackman talks about four levels of self-management [6, Ch. 2]: manager-led, self-managing, self-designing and self-governing. The 2020 Scrum guide [9, p. 5] has changed “self-organizing” to “self-managing”. According to the Scrum guide revision history, they mean self-organizing for “choosing who and how to do work” while self-managing for “choosing who, how, and what to work on”. Other authors include other aspects for self-managed, like managing their budget, scheduling or rewards [10]. The concept of self-management is also an essential part of Teal Organisations [11, p. 61] and aligned with Empowered Product Teams [12].

Software teams

In many software organisation, a team is a group of people organised together to achieve a mission. These groups are formed in a way to be as autonomous as possible, with all the required skills. They prefer not to have highly specialised teams that are dedicated to perform just specific parts of missions, like a front end team, a documentation team or a testing team, because they could easily become a bottleneck. So these organisations combine together people with different skills: programming, analysis, interaction design, documentation, machine learning, etc.

Some companies call these teams product teams. A similar construct is defined in Team Topologies [1] with the name stream aligned teams. In The Connected Company [13] they prefer the name pods.

In some organisations teams also have a product manager, someone who is dedicated to ensuring that the team is working on the most valuable thing. Finally, teams also have a team leader.

Leading what?

The team leader is a people manager for some of the engineers in the team, usually excluding specialisations like UX or Data Science, and also excluding the product manager. Supposedly, the Team Leader leads a team. Then, what is the team?

We have a Team Leader who is managing a group of people who are part of a group, along with other people who are managed by people outside that group. Sometimes they refer to the people managed by the team leader as the team, and other times they refer to the whole group contributing to the mission as the team. However, sometimes they use expressions like “the team and the product manager” excluding the latter from the team. Wouldn’t it be great for them to have a sense of belonging generated from the language used for all the contributors to the mission?

Do groups of people need someone leading them? It seems they hold this belief.

First Team

Can we belong to more than one team? We can belong to more than one group of people, that’s for sure. We may be part of our reading club, our sports club, the neighbours, the hospital volunteers, the Fridays partygoers and our church, and all of these can be different groups without causing issues.

In Spotify [14], they also explored the possibility of belonging to multiple groups that they represented with chapters and guilds and, as they wanted to refine the meaning of team, they decided to use the term squad. There are also communities of practice and book clubs. We do belong to multiple groups.

Example 1: Shelly, a software engineer in team PrioratWine in Barcelona, and is interested in Domain Driven Design may belong to the following “teams”:

• PrioratWine Team
• DDD community of practice
• Meetup organisers
• Runners club

Example 2: Alex, Team Leader in the same team, may belong to:

• PrioratWine Team
• Facilitators community of practice
• Board gamers
• The team of Team Leaders in his area

They have a sense of belonging to different groups, there may be multiple overlaps. It seems reasonable that multiple Team Leaders and Engineering Managers can work together to pursue a common goal. That would be a team.

If you can belong to multiple teams it is very important to clarify which one is your first team.

Toni Tassani — 28 March 2022

This article was originally published on 15 February 2021 on the Ocado Technology intranet.