Team Topologies Quotes

“The problem with taking the org chart at face value is that we end up trying to architect people as if they were software, neatly keeping their communication within the accepted lines.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“inter”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Fundamentally, we need to involve technical people in organization design because they understand key software design concepts, such as APIs and interfaces, abstraction, encapsulation, and so on. Naomi Stanford puts it like this: “departments and divisions, systems, and business processes . . . can be designed independently as long as interfaces and boundaries with the wider organization form part of the design.”13”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“How much awareness does the HR department have about software systems? Does the group of department leaders deciding how to allocate budget across teams know of the likely effects of their choices on the viability of the software architecture? Given that there is increasing evidence for the homomorphism behind Conway’s law, it is very ineffective (perhaps irresponsible) for organizations that build software systems to decide on the shape, responsibilities, and boundaries of teams without input from technical leaders. Organization design and software design are, in practice, two sides of the same coin, and both need to be undertaken by the same informed group of people. Allan Kelly’s view of a software architect’s role expands further on this idea: More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“If we accept that the self-similar force (between architecture and team organization) described by Conway is real, then we also need to accept that anyone who makes decisions about the shape and placement of engineering teams is strongly influencing the software systems architecture. There is a logical implication of Conway’s law here, in the words of Ruth Malan: “if we have managers deciding . . . which services will be built, by which teams, we implicitly have managers deciding on the system architecture.”11”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Loose coupling—components do not hold strong dependencies on other components ​•​High cohesion—components have clearly bounded responsibilities, and their internal elements are strongly related ​•​Clear and appropriate version compatibility ​•​Clear and appropriate cross-team testing”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Conway’s law tells us that we need to understand what software architecture is needed before we organize our teams, otherwise the communication paths and incentives in the organization will end up dictating the software architecture. As Michael Nygard says: “Team assignments are the first draft of the architecture.”7”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“As Fernando Cornago, Senior Director of Platform Engineering, and Markus Rautert, Vice President of Platform Engineering and Architecture, explained their IT department went from being seen as a cost center, with a single vendor providing most of the software (requiring frequent hand-offs) and only a few in-house engineers (doing more managing than engineering), to a product-oriented team organization. Adidas invested 80% of its engineering resources to creating in-house software delivery capabilities via cross-functional”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Developing and operating software effectively for modern, interconnected systems and services requires organizations to consider many different dimensions. Historically, most organizations have seen software development as a kind of manufacturing to be completed by separate individuals arranged into functional specialties, with large projects planned up front and with little consideration for sociotechnical dynamics. This led to the prevailing problems depicted in Figure 1.2 on page 12.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“If the organization has an expectation that “everyone should see every message in the chat” or “everyone needs to attend the massive standup meetings” or “everyone needs to be present in meetings” to approve decisions, then we have an organization design problem. Conway’s law suggests that this kind of many-to-many communication will tend to produce monolithic, tangled, highly coupled, interdependent systems that do not support fast flow. More communication is not necessarily a good thing.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow