Team Topologies: Organizing Business and Technology Teams for Fast Flow

“an engineer would switch teams about every 9 to 12 months.”

when a single team owns the system or subsystem, and the team has the autonomy to plan their own work, then that team can make sensible decisions about short-term fixes with the knowledge that they will be removing any dirty fixes in the next few weeks.

Every part of the software system needs to be owned by exactly one team. This means there should be no shared ownership of components, libraries, or code.

Outside teams may submit pull requests or suggestions for change to the owning team, but they cannot make changes themselves. The

Outside teams may submit pull requests or suggestions for change to the owning team, but they cannot make changes themselves.

Note that team ownership of code should not be a territorial thing. The team takes responsibility for the code and cares for it, but individual team members should not feel like the code is theirs to the exclusion of others. Instead, teams should view themselves as stewards or caretakers as opposed to private owners. Think of code as gardening, not policing.

For teams to work, team members should put the needs of the team above their own. They should:

For teams to work, team members should put the needs of the team above their own. They should: Arrive for stand-ups and meetings on time. Keep discussions and investigations on track. Encourage a focus on team goals. Help unblock other team members before starting on new work. Mentor new or less experienced team members. Avoid “winning” arguments and, instead, agree to explore options.

However, even with coaching, some people are unsuitable to work on teams or are unwilling to put team needs above their own. Such people can destroy teamwork and, in extreme cases, destroy teams. These people are “team toxic” and need to be removed before damage is done.

Looking to reward individual performance in modern organizations tends to drive poor results and damages staff behavior.

With a team-first approach, the whole team is rewarded for their combined effort.

the team needs the space to continuously try to reduce the amount of intrinsic and extraneous load they currently have to deal with (via training, practice, automation, and any other useful techniques).

“Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?”

organization needs to take the necessary steps to reduce cognitive load, thus ensuring that the team is able to be effective and proactive again. Incidentally, this will increase motivational levels within the team as members see more value and purpose in their work.

The team was constantly faced with too much work and context switching prevailed, with tasks coming in from different product areas simultaneously.

there is a risk here of diminishing team members’ motivation due to the more routine nature of their work.

“Minimize cognitive load for others” is one of the most useful heuristics for good software development.

For effective team-first ownership of software, teams need to continuously define, advertise, test, and evolve their team API to ensure that it is fit for purpose for the consumers of that API: other teams.

People who work all day with headphones on are seen as anti-social, and their behavior does not promote interaction and collaboration; but it could well be that the office environment is generally noisy and these people require a quiet environment to be effective.

Office design for effective software delivery should accommodate all of the following modes of work: focused individual work, collaborative intra-team work, and collaborative inter-team work.