Cybernetics Organization

Many problems in delivery software come from accidentally unclear boundaries between different teams and their responsibilities. This is often shadowed by software architecture with high coupling between its different parts (even if on paper the architecture was supposed to be highly modular and extensible). We should think of team first — software architecture based org design, we are a tech company who use technology to drive business success, not the other way around.

Software is less of a “product for” and more of an “ongoing conversation with” users. To make this ongoing conversation effective and successful, organisations need a continuity of care for its software.

Operate organization using practices from . Fast flow software delivery requires restricting communication between teams. Team collaboration is important for grey areas of development, where discovery and expertise is needed to make progress. But in areas where execution prevails—not discovery—communication becomes an unnecessary overhead.

Team Topologies

Domain Driven Design

Involve technical people in organisation design because they understand key software design concepts such as APIs and interfaces, abstraction and encapsulation.

1. Assign each domain to a single team.
2. A single team (considering the golden 7-9 team size) should be able to accommodate 2-3 “simple” domains.
3. A team responsible for a complex domain should not have any more domains assigned to them – not even a simple one.
4. Avoid a single team responsible for two complicated domains, split them into two sub teams of five people.
5. Avoid reorganization for the sake of management convenience.
6. Detect and track inter-dependencies between teams, iterate organisation design to minimise communications.

Types of Team

The four fundamental team Topologies are stream aligned, enabling, complicated subsystem and platform. These are designed to reduce ambiguity around organizational roles.

Stream-aligned Team

A team aligned to a single, valuable stream of work; this might be a product or service. Further, the team is empowered to build and deliver customer or user value quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.

Characteristics

• Able to quickly incorporate feedback from customers while monitoring their software in production.
• Each service is provided through an API, either for internal or external consumption; teams do not interfere or make any assumptions on another team’s services architecture or technology.
• Address code quality issues (tech-debt) to ensure that changing the code remains safe and easy to do.

Enabling Team

An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. Such teams cross-cut to the Stream-aligned and have required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.

If an enabling team does its job well, the team that it is helping should no longer need the help from the enabling team after a few weeks or months; there should not be permanent dependency on an enabling team. For example, the enabling team could set up a walking skeleton of a deployment pipeline or a basic test framework combining automation tools.

Enabling Team versus Communities of Practice (CoP)
The members of an enabling team work on enabling activities full-time, whereas a CoP is a more diffuse grouping of interested individuals from across several teams, with an aim to share practices and improve working methods on a weekly (or monthly) basis.

Characteristics

• Enabling Stream-aligned to increase autonomy by growing their capabilities with a focus on their problems first, not the solutions per se.
• Help Stream-aligned to acquire missing capabilities, taking on the effort of research and trials, and setting up successful practices.
• Actively avoid becoming “ivory towers” of knowledge, dictating technical choices for other teams to follow, while helping teams to understand and comply with organisation-wide technology constraints.
• Proactively seeks to understand the need of Stream-aligned, establishing regular checkpoints.
• The enabling team should plan for its own extinction from the very first day to avoid other teams becoming dependent.

Complicated-Subsystem Team

A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem.

Characteristics

• Reduce cognitive load of Stream-aligned teams working on systems that include or use the complicated subsystem.
• Do not expect to embed necessary specialist in all the Stream-aligned teams that make use of the subsystem.
• The decision is driven by team cognitive load, not by a perceived opportunity to share the component.

Platform Team

The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as compelling internal products. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.

Characteristics

• Reduce the cognitive load of Stream-aligned by offloading lower level detailed knowledge (e.g, provisioning, monitoring, or development), providing easy-to-consume services around them.
• Tracking cloud infrastructure costs by team or service to regulate demand, which helps to avoid everyone asking for premium level.
• Relies on fast prototyping techniques and involves Stream-aligned members for fast feedback on what works and what does not.
• Lead by example: using the services they provide internally (when applicable), partnering with Stream-aligned and Enabling teams, and consuming lower level platforms (owned by other platform teams) whenever possible.
• Deep understanding that adoption for new services is not immediate, but instead evolves along an adoption curve.
• Has a strong focus on usability and reliability for their services (treating the platform as a product), and regularly assesses if the services are still fit for purpose and usable.

Three Types of Interaction Mode

When considering the relationship between any teams, a key decision is whether to collaborate with another team to achieve an objective or to treat the other team as providing a service. What must be avoided is the need for all teams to communicate with all other teams to achieve their ends.

Collaboration

Means working closely together with another team. The collaboration team mode is suitable where a high degree of adaptability of discovery is needed, particularly when exploring new technologies or techniques. This mode requires good alignment and a high appetite and ability for working together between teams.

• A team should use collaboration mode with, at most one other team at a time.
• Example: Stream-aligned teams work with complicated-subsystems; Stream-aligned teams working with platform teams.
• Require high interaction and mutual respect.
• Great at situations where discovery is more important than delivery.

X-as-a-Service

The X-as-a-Service team interaction mode is suited to situations where there is a need for one or more teams to use a code library, component, API, or platform without much effort. During later phases of systems development where predictable delivery is needed (rather than discovery of new approaches), X-as-a-Service works best.

• The team responsible must have a strong sense of responsibility toward both consumers (developer) and the viability of the thing they are providing.
• The service they provide should be straightforward to use, test, deploy and/or debug; and the documentation on how to use should be clear, well-written, and up to date.
• A team should expect to use X-as-a-Service interaction with many other teams simultaneously, whether consuming or providing a service.
• Example: Stream-aligned teams and complicated-subsystem consuming Platform-as-a-Service from a platform team.
• Require developers undergo some training on core user-experience (UX) and developer-experience (DevEx).
• Great at situations where predictable delivery is more important than rapid discovery.

Facilitating

The facilitating team interaction mode is suited to situations where one or more teams would benefit from the active help of another team facilitating (or coaching) some aspect of their work. This is the main operating mode of an enabling team and provides support and capabilities to many other teams.

• A team should expect to use the facilitating mode with a small number of other teams simultaneously, whether consuming or providing the facilitation.
• Example: A team facilitating might find that the logging service provided by the platform is quite difficult to configure. The facilitator then helps the team on implementation and facilitates some improvements to the logging service from the platform.

Software Boundaries

Considerations for redesign organisation includes several factors:

Business Domain

Initiate exploration phase via collaboration between business experts to focus on core complexity and opportunities given business domain. Most of our software responsibility should map to business domain bounded context. A bounded context is a unit for partitioning larger domain (or system) models into smaller parts, each of which represents an internally consistent business domain area.

Regulatory Compliance

Regulatory requirements can often provide hard borders for software. They often require organisations to adopt specific mechanisms for auditing, documenting, testing, and deploying software. For instance, the Payment Card Industry Data Security Standard (PCI DSS) establishes a set of rules around requesting and storing credit card data. Compliance with PCI DSS should fall on a dedicated Complicated-subsystem team for card data management, but these requirements should not apply to entire payment functionality.

Change Cadence

Splitting off the parts of the system that typically change at different speeds allow deployment changes more quickly. The business needs the speed of change, rather than monolith systems imposing a fixed speed for all.

Team Location

Teams distributed geographically and across different time zones are obviously not co located. But even teams with members working in the same office building on different floors or in different physical spaces can be considered geographically separate. Working across different time zones aggravates these communication delays and introduces bottlenecks when manual approvals or code reviews are needed from people in different time zones with little working-time overlap.

Risk

Regulatory compliance is a specific type of risk, other examples include marketing driven changes with a higher risk profile (focusing on customer acquisition) versus lower risk profile changes to revenue-generating transactional features (focusing on customer retention). The number of users can also drive acceptable risk. For instance, a SaaS product might have millions of users in the free tier and only a few hundred users in the paying tiers. Changes to popular features in the free tier might fall into a higher risk profile.

Performance Isolation

Performance should always be a concern for every system; it should be analysed, tested, and optimised where possible. However, parts of applications subject to peaks of demand at a large scale require a level of scaling and fail-over optimisation not necessary for the rest of the system. Splitting off such a Complicated-subsystem team based on particular performance demands helps to ensure it can scale autonomously, increasing performance and reducing cost.

Technology

Technology is often (historically) the only type of boundary used when splitting up teams. Consider how common it is to have separate teams for frontend, backend, data tier, etc. However, this typically introduces more constraints and reduces flow of work rather than improves it. That is because the separate teams are less autonomous, as product dependencies remain while each team has less visibility on the work as a whole, and inter-team communication paths are slower than intra-team. There are situations where splitting off a Complicated-subsystem team based on technology can be effective, particularly for systems lacking an open, supportive community of users. For example, IDEs, build tools, testing tools, etc.

User Personas

As systems grow and expand their feature sets, the internal or external customer base also grows and diversifies. Some groups of users will rely on a given subset of features to get their job done. In products with tier pricing, the subset is built in by design (higher paying customers have access to more features than lower or non-paying customers). In other systems, admin users have access to more options and controls than regular users. The effort required to remove dependencies or coupling between features is compensated with a sharper focus on customer’s needs and experience using the system, which result in higher customer satisfaction and improve the organisation’s bottom line. In fact, such a structure can also improve the speed and quality of customer support - it becomes easier to map issues to a given Complicated-subsystem team and Stream-Aligned team.

Putting all together as an example

Consider a team called Consumer Onboarding. The development since inception span over 6 months supported by a group of enablers, new joiners and support from platform teams.