Teams
How organizations work and what they are capable of building or producing can be described by this observation:
“Organisations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organisations.” — Conway’s Law
This observation, or “Conway’s Law”, indicates that how an organisation structures the people in it and their collaboration directly dictates what they can build or produce. Which then ties into the idea that:
“Teams [are] the means of [software] delivery.” — Team Topologies
How an organisation structures the teams will determine the quality, effectiveness, adaptability, and speed of what the organisation builds or produces. This is why we at the Seedcase Project want to be intentional about how we structure our teams, which leads to the following organisation design principles.
While many of these principles don’t strictly apply to our current situation of being a 4-person group, we want to establish the foundation for how we want to work if or when we grow.
However, within our current group, we do have established different teams with different focus areas.
Make teams based on projects and their needs
To achieve the idea that teams are the means of delivery, we need to create teams based on what a project or product needs to be successfully completed or “delivered”. In this case, a project is something with a defined endpoint with a defined goal and usually includes some type of product. For instance, a project could be the first minimum viable product (MVP) of a new product or the implementation of an expanded set of functionality in an existing product.
The team that is created for a project must have the necessary expertise to fulfill the needs and requirements of the project. The team should be designed before fitting people into it.
This team is now tied to that project until the project ends. The team then disbands and converts into another team for another project. Often the team stays the same in terms of the people within it, but it doesn’t have to.
Teams are responsible for the full lifecycle of their project
To effectively and practically complete a project, the team must be responsible for the full length of it, from start to end. This includes determining needs, planning, designing, developing, testing, deploying, and assessing usage. This also includes being responsible for the ongoing maintenance of the product that the project focuses on.
This also means that the team needs to have the necessary autonomy to make and act on decisions that help with completing the project. There should be as little administrative overhead and bureaucracy as possible.
Teams have tasks and responsibilities, not individuals
View teams as the primary unit of work. Individuals are part of the team, not the other way around. Individuals fit what is needed for the team. We build teams to contain individuals with the necessary expertise to fit what the team needs. But if the expertise is not available, individuals within the team must learn and develop the necessary expertise.
Teams should be cross-functional
Related to the principles above, in order to fulfill the needs of the team and be responsible for the full lifecycle of a project, the team must be cross-functional. By that we mean that individuals in the team must be competent in all the aspects of the lifecycle of the project. This doesn’t mean that everyone is an expert in all areas, but that everyone should be competent in all areas. Individuals are still encouraged to specialize in specific areas, but not at the expense of competency in all areas.
Minimise the cognitive load of teams
A team is made up of individuals, who each have real, physical constraints in what they can do and how much they can do it. This is often referred to as cognitive load and capacity. A team is effective when the cognitive load is balanced between being challenging but not overwhelming.
Teams should be long-lasting and stable
Teams become productive when the individuals in them feel comfortable, safe, secure, and are able to trust one another. This is hard to achieve if people in the teams are constantly coming or going. Therefore, we aim to create teams that are long-lasting and stable. This doesn’t mean that teams are unchanging, but that they are stable enough to build trust and comfort between team members.
This also means that projects need to be scoped large enough to allow a longer lasting team. Alternatively, the people that make up the teams already know each other and are comfortable enough with each other that a stable team dynamic happens quickly.
Keep teams relatively small to minimize communication overhead
The most effective team size for creative knowledge work is between 3 to 8 people. More than that and the benefit of working as a team diminishes. This is largely due to the fact that collaboration and communication have a cost, which increases substantially with each added person. Keeping a team small also keeps the collaboration and communication cost low while gaining the benefits of working together to complete tasks for a project.