Common Design Patterns
There are several common patterns for defining organisational and team design structures.
Functional Design, where the structure is based around specific functions, such as marketing, finance, or operations. Each function has its own team or department, and people are grouped by their area of expertise. This pattern is common in traditional organisations.
Geographic Design, where the structure is based around geographic locations. Each location has its own team or department, and people are grouped based on their physical location. This pattern is common in organisations with multiple offices or branches.
Product Design, where the structure is based around specific products or services. Each product or service has its own team or department, and people are grouped based on their contribution to that product or service. This pattern is common in organisations that focus on innovation and product development.
Role-Based Design, where the structure is based around specific roles or job functions. Each role has its own team or department, and people are grouped based on their job responsibilities. For example, an organisation might have separate teams for software developers, quality assurance analysts, and product managers.
Virtual Design, where the structure is based around people who work together remotely, often across different locations or time zones, using digital communication tools. Virtual teams are becoming increasingly common as more organisations adopt remote work policies.
Temporary Design, where the team is formed to achieve a specific objective within a defined timeline and with specific deliverables. These teams are temporary and are disbanded once the outcome has been delivered (or the estimated timeline is exceeded).
Cross-Functional Design, where the structure consists of individuals from different functional areas or areas of expertise who are grouped together and responsible for delivering specific outcomes. This pattern is common in agile organisations that focus on flexibility and adaptability.
Hierarchical Design, where the structure is based on a hierarchy, with clear lines of authority, decision-making power and a chain of command. Hierarchical teams are common in traditional, fixed mindset organisations.
Matrix Design, where the structure is based around combining several patterns. For example both functions and products, or functions and geography. People are grouped based on their expertise, but also work across different products or services. This pattern is common in large, complex organisations.
Flat Design, where the team structure is based on has minimal or zero hierarchical layers. Every person on the team has an equal say and role in the team. Flat team design is typically observed in startups or small organisations where agility, flexibility, and creativity are critical to success.
Self Forming Design, where the structure of the team is decided by a group of individuals who come together voluntarily to work on a particular outcome. In this type of team design, people themselves determine the team’s structure, and are often also responsible for managing their own work and decision-making.
Fixed Mindset Team Design
There is no such thing as a fixed mindset team design.
A fixed mindset refers to a traditional mindset, where people stick to what they know best, opting for familiar paths rather than investigating new opportunities. A fixed mindset essentially means a predetermined view of the world and are unwilling to change it, whereas a growth mindset refers to an agile mindset, being open to new ideas and different ways of doing things. These mindsets can influence how people approach challenges and can have an impact on team dynamics and team topologies.
Organisations who operate under a fixed mindset organise their team topologies in a hierarchical manner. There is a clear chain of command with each level of management responsible for the team below them.
The top of the hierarchy is typically the executive or leadership team, followed by middle management, and then individual teams or departments. Within each team or department, there may be further levels of hierarchy depending on the size and complexity of the organisation.
In this type of organisational structure, decisions are often made at the top and trickle down through the levels of management to the individual teams. Communication is typically vertical, meaning that information flows up and down the chain of command.
While this traditional approach provides a clear structure and direction for the organisation, it can also be slow to adapt to changing circumstances and can result in a lack of autonomy and empowerment for individual team members.
There are some common anti-patterns used by fixed mindset organisations to structure their team topologies.
Command-and-control, based on hierarchical structures where senior managers make all the decisions and dictate how things should be done. Junior employees are expected to follow orders without question, and there is little room for creativity or innovation.
Silo centric, where different departments or teams operate independently and do not collaborate or share information with each other. This can lead to a lack of communication and coordination, and can prevent the organisation from achieving its goals.
A focus on rigid job roles, not skills, where people are assigned specific job roles and are expected to stick to them without deviation. There is little room for cross-training or development, which can limit peoples’ ability to learn new skills and grow within the organisation.
Fixed performance metrics that are defined a year in advance which discourages innovation and creativity, as people become hesitant in taking risks or iterating their ways of working or patterns as it means deviating from the established metrics.
These anti-patterns create a rigid, inflexible organisational team topologies and cultures that stifle experimentation and limit the organisation’s ability to adapt to change.
Scaled Agile Framework (SaFE)
All I will say is if you are thinking of implementing the Scaled Agile Framework (SaFe) then my recommendation is don’t. Not really much more I want to say about that supposed Agile Methodology.
Growth Mindset Team Design
Growth mindset refers to an agile mindset, being open to new ideas and different ways of doing things. These mindsets can influence how people approach challenges and can have an impact on team dynamics and team design.
Just like there is no such thing as a fixed mindset team design, there is no growth mindset team design.
We can find team design patterns from organisations or patterns that are recognised as being founded on growth and agile mindsets and these patterns can help us create our own team design given our unique context.
Team of One
A “team of one” is a team design where there is effectively no team. A single person is responsible for handling multiple tasks and responsibilities typically assigned to a team. This can be common in small organisations or startups, where resources are limited, and people must wear multiple hats to get things done. In such cases, the person needs to be highly adaptable, self-organised, and skilled in various domains to complete the work.
A Team of One is characterised by a number of patterns:
Prioritisation, the person prioritises tasks based on their importance, urgency, and impact on the organisation. This helps ensure that the most critical work is done first.
Time management, efficient time management is essential for a “team of one” to prevent burnout and ensure productivity. The person should set realistic goals, allocate time for each task, and monitor progress to stay on track.
Skillset, the person must have a diverse skill set or be willing to learn new skills quickly. This might include technical skills, such as programming, design, or testing, as well as soft skills, like communication, problem-solving, and collaboration.
Tools and automation, to increase efficiency, a “team of one” should leverage appropriate tools and technologies for task management, communication, and collaboration. Automating repetitive tasks can also save time and reduce the likelihood of errors.
Continuous learning, the person should constantly be learning and improving, staying updated with industry trends, and adapting to new challenges.
Communication, effective communication is crucial for a “team of one” to keep stakeholders informed about progress, challenges, and any changes in priorities.
Seeking support: Even though it’s a “team of one,” the person should seek help, advice, or mentorship from colleagues, or peers.
A “team of one” team design does not typically survive as a long-term solution for an organisation. It can lead to burnout and may not be sustainable for complex data work. As the organisation grows, it becomes essential to design a team with diverse skills to scale the work done as the organisation scales.
Valve Flatland
Valve Corporation, a video game developer and digital distribution company, is known for its unique organisational structure, which has been described as a “flat” or “self-organising” team design. Rather than having a traditional hierarchy of managers and supervisors, Valve operates with a “flat” structure where every team member has a great deal of autonomy and decision-making power.
These teams or groups are referred to as “cabals”.
“Cabals are really just multidisciplinary project teams. We’ve self-organized into these largely temporary groups since the early days of Valve. They exist to get a product or large feature shipped. Like any other group or effort at the company, they form organically. People decide to join the group based on their own belief that the group’s work is important enough for them to work on.”
Valve Handbook for New Employees https://www.valvesoftware.com/en/publications
Cabals are made up of individuals with different skills and expertise, and are self-organising and self-directed. Each Cabal has a high degree of autonomy and decision-making power, and is responsible for setting its own goals and priorities.
<<<For reference, read the article on cabals by Ken Birdwell. It describes where cabals came from and what they meant to us early on:
http://tinyurl.com/ygam86p.>>
The Valve team design pattern is characterised by a number of patterns:
Flat hierarchy, Valve operates with a non-hierarchical, flat organisational structure. This means that there are no formal job titles, and team members have the autonomy to choose the projects they work on.
Self-organisation, Valve team members are encouraged to work on projects that interest them and to form and reform teams as needed. There are no formal job titles or promotions, and individuals are free to move between teams and projects as they see fit.
Decentralised decision-making, rather than having managers make decisions, decisions are made through consensus-building and peer review. Any team member can propose an idea or project, and it will be evaluated by the other team members involved.
Open communication, Valve team members are encouraged to share information and collaborate with each other. There are no private offices or cubicles, and everyone works in a shared workspace.
Continuous feedback, feedback is encouraged and valued, with an emphasis on open and honest communication. Valve uses a 360-degree feedback system where team members receive feedback from their peers, subordinates, and superiors.
Scrum Team
Scrum is a set of agile patterns which include a team design pattern. The team design of a Scrum team is designed to be cross-functional and self-organising, which enables the team to adapt quickly to changing requirements and continuously improve their processes.
The Scrum team design pattern is characterised by a number of patterns:
Product Owner, the Product Owner is responsible for defining the product’s vision, prioritising the product backlog, and making sure the team is working on the most valuable tasks. They are the primary stakeholder and represent the voice of the stakeholders and the customers.
Scrum Master, the Scrum Master is a servant-leader who helps the team follow the Scrum framework, coaches them on Scrum practices, and removes any obstacles or impediments that may hinder the team’s progress. The Scrum Master is responsible for helping the team work in an agile way of working.
Development Team Members, the Development Team consists of people responsible for delivering a potentially releasable increment of the product at the end of each iteration. The team is cross-functional, which means it includes all the necessary skills (e.g., developers, testers, designers) to complete the work. The team is also self-organising, meaning they plan and manage their work without the need for external supervision.
This design pattern promotes collaboration, transparency, and adaptability, allowing the team to rapidly respond to changes in requirements and continuously deliver high-quality software.
The Development team members should be comprised of T-shaped skilled people
<<<link to t-shaped skills chapter>>>
Amazon two pizza teams
The concept of the “2 pizza team” can be traced back to the early days of Amazon, when CEO Jeff Bezos implemented this approach as a way to encourage effective communication and collaboration within the company.
https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html
The idea behind the 2 pizza team is simple: teams should be small enough that they can be fed with just two pizzas. In other words, teams should be kept to a size where everyone can sit around a table and easily discuss and collaborate on their work.
Bezos believed that small teams were more agile and able to move quickly, and that larger teams were prone to communication breakdowns and inefficiencies. He implemented the 2 pizza team rule as a way to ensure that teams at Amazon were small enough to stay focused and effective.
Since its inception, the 2 pizza team concept has gained widespread popularity and has been adopted by many other organisations as a way to improve teamwork and collaboration. While the exact size of a 2 pizza team may vary depending on the specific needs and goals of the team, the core idea remains the same: teams should be small enough to facilitate effective communication and collaboration.
Spotify aka The ‘Spotify Model’
The team design and way of working patterns developed within Spotify and published by Henrik Kniberg & Anders Iversson were a series of videos and blog articles which provided a snapshot of Spotify’s approach to software engineering and people management in 2014. They were titled “Spotify engineering culture” but somehow came to be known as the “Spotify Model”.
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
https://engineering.atspotify.com/2014/09/spotify-engineering-culture-part-2/
The Spotify model is a set of team and organisational design patterns designed and employed by the music streaming company, Spotify, to foster an agile and efficient working environment. It is built around the design patterns of cross-functional, self-organising, and autonomous teams, known as “squads.” The patterns gained attention for their innovative approach to promoting collaboration, flexibility, and a strong company culture.
When describing the Spotify patterns, often the team design patterns are described in isolation.
These team design patterns are (as described in 2014):
Squads, small, cross-functional teams consisting of around 6-12 members. Each squad is responsible for a specific aspect of the product or service and has the autonomy to decide how to work together to achieve their goals. Squads are designed to be self-sufficient, meaning they have all the necessary skills and resources to complete their tasks.
Tribes, where squads that work on related areas or share common objectives are grouped together into larger organisational units called tribes. Each tribe is led by a Tribe Lead, who ensures alignment and coordination among the squads.
Chapters, where within a tribe, individuals with similar skills or roles form a chapter. The chapter lead, who is a line manager, focuses on personal growth, career development, and providing guidance to chapter members.
Guilds, which are informal, company-wide groups that bring together people with shared interests or skills, such as software engineers, data scientists, or designers. Guilds allow members to share knowledge, best practices, and collaborate on common challenges across the entire organisation.
However the success of the team and organisational design in Spotify at that time was also reliant on the team’s way of working, the culture across the organisation and the organisational strategy.
<<<no Nonsense Agile Podcast content>>>
Software Team Topology
Team Topology is a set of patterns for organising and designing teams within an organisation to optimise their collaboration and communication. It was introduced by Matthew Skelton and Manuel Pais in their book “Team Topologies: Organizing Business and Technology Teams for Fast Flow” (2019). The main idea is to create a structure that enables teams to effectively work together, respond to changes, and continuously deliver value.
The Team Topologies patterns are designed to optimise communication, minimise cognitive load, and create an environment where teams can rapidly respond to changes and deliver value effectively. By understanding and applying these concepts, we can design adaptive, efficient, and resilient team structures.
Team Topologies suggests four fundamental team types:
Stream-aligned teams, these teams are focused on delivering end-to-end value to specific customer or user segments. They are cross-functional and work on a continuous stream of work items related to their specific user or customer group.
Platform teams, these teams build and maintain platforms or services that provide capabilities to other teams. They enable stream-aligned teams to deliver their work faster and more efficiently by providing reusable components and services.
Enabling teams, these teams provide expertise and support to stream-aligned teams, helping them adopt new technologies, practices, and ways of working. They act as catalysts for change and improvement across the organisation.
Complicated subsystem teams, these teams deal with highly complex and specialised areas of the system that require deep expertise. They may work on specific components or subsystems that are too intricate for a stream-aligned team to handle efficiently.
In addition to the team types, Team Topologies emphasises the importance of interaction modes, which describe how teams should interact and communicate. There are three main interaction modes:
Collaboration, working together closely for a specific purpose or to solve a particular problem.
X-as-a-Service, one team provides a service to another team, with a clear service-level agreement (SLA) and a focus on minimising interaction overhead.
Facilitating, one team helps another team by providing guidance, training, or other support, with a focus on improving the capabilities of the recipient team.
unFIX
unFIX is a set of patterns that help with scaling team design, introduced by Jurgen Appelo. The patterns have been inspired by innovative companies including Haier and Tesla, various agile scaling frameworks, and books such as Team Topologies, Dynamic Reteaming, and Organization Design.
The unFIX team design pattern is characterised by a number of patterns:
Crews, a Crew is a team that usually consists of three to seven people and team members are mostly dedicated to their Crew. There are seven kinds of Crews.
Value Stream Crew, a Value Stream Crew has end-to-end responsibility for a value stream. Its members are responsible for everything, from the moment they receive a customer (user) request to the moment they deliver value to the customer (user).
Facilitation Crews, sometimes you need people whose sole purpose is to help other Crews do a great job. Such teams have no value stream of their own. Instead, they ensure that the Value Stream Crews in the Base can operate smoothly. Examples would be a team of Scrum Masters or agile coaches.
Capability Crews, sometimes, you have a few people with hyper-specialised skills and you do not have enough of them to put one of them in each Value Stream Crews. A Capability Crew consists of a group of people with these advanced skills. Their goal is to assist the other Crews when their skills are needed. The Capability Crew members will (temporarily) work on a Value Stream Crew, but they are considered guest members. The situation is very similar to having external consultants with special knowledge working on a Value Stream Crew for a short period of time.
Platform Crew, your federated governance pattern may mandate that Value Stream Crews should share a common architecture and infrastructure to do their work. The goal of a Platform Crew is to offer shared services to the other Crews. Often, the services will be of a technical kind, including architecture and infrastructure, but it’s also possible for them to be human services, such as learning and development.
Experience Crew, the Experience Crew is a customer-facing “front team” whose goal is to optimise the entire customer journey and user experience in the case of touchpoints across multiple products and various channels. It provides a holistic customer experience as an organisation.
Partnership Crew, the Partnership Crew has an almost identical role as the Experience Crew, except while the Experience Crew focuses on customers and users, the Partnership Crew keeps its focus on vendors, partners, freelancers, employees, and gig workers.
Governance Crew, the Governance Crew is the leadership team. It consists of several Chiefs who are the leaders of everyone in the Base. In the case of a Base being one entire company, the Governance Crew is the executive team.
Base, all Crews operate from a Base of between a handful to a few hundred people. This Base has a number of Crews of the seven standard Crew types organised around one or more value streams. The Base acts like a fully grown, independent business. It contains all the necessary skills to design, develop, and deliver products, from Design Thinking to DevOps and from Lean Startup to Lean Manufacturing.
Forums, a Forum is a group consisting of people from various Crews. The name Forum indicates that its primary purpose is for like-minded workers to get together, talk, and make decisions together. There could be a DevOps Forum, a UX Forum, a Growth Hackers Forum, etc.
