Optimize for the team, and the benefits compound in a positive way.
@TeamTopologies
Optimize for the task and the costs compound until we are all stuck in mud.
@TeamTopologies
Optimize for the task and the costs compound until we are all stuck in mud.
See the team as the fundamental unit of delivery.
Build an API surrounding each team [to other teams and the wider organization.]
@TeamTopologies
Build an API surrounding each team [to other teams and the wider organization.]
@TeamTopologies
Teams need to continually define, advertise, test, and evolve their team API... for other teams.
@TeamTopologies
Look, we all need marketing. Marketing makes connections. Connections make nodes useful.
@TeamTopologies
Look, we all need marketing. Marketing makes connections. Connections make nodes useful.
None of this organization stuff will even help if the team doesn’t get to deliver and learn quickly.
They need to form hypotheses, roll out changes, observe the results, enhance, test, repeat. With no blockers from outside the team.
They need to form hypotheses, roll out changes, observe the results, enhance, test, repeat. With no blockers from outside the team.
Individual competition optimizes for thick skin.
“In a team-first organization, [individual people] have the space and support to develop their skills”
@TeamTopologies
“In a team-first organization, [individual people] have the space and support to develop their skills”
@TeamTopologies
A computer will perform the same whether it is placed in Room A or Room B, but an engineer placed on Team A may perform very differently than if placed on Team B.
@TeamTopologies
@TeamTopologies
Treat frontline staff and teams as highly valuable sources of signals.
Get a superior “sensing” ability.
@teamtopologies
#superpowers
Get a superior “sensing” ability.
@teamtopologies
#superpowers
DevOps won’t work unless orgs “address fundamental misalignments between teams.”
Tools make rapid delivery possible. They don’t make it happen.
Tools make rapid delivery possible. They don’t make it happen.
“The success of different types of teams
does not depend solely on team members’ skills and experience;
it also depends on (perhaps most importantly) the surrounding environment, teams, and interactions.”
@TeamTopologies
So obvious. So hard to remember when making judgements.
does not depend solely on team members’ skills and experience;
it also depends on (perhaps most importantly) the surrounding environment, teams, and interactions.”
@TeamTopologies
So obvious. So hard to remember when making judgements.
Teams can have external dependencies. They just can’t be blocking.
If you want the cloud infra team to make decisions about how stuff is deployed, cool.
Let them build that into automation that’s used by product teams
who decide what and when to deploy.
Let them build that into automation that’s used by product teams
who decide what and when to deploy.
A “DevOps team” can make sense as a temporary team of evangelists who help other teams learn and implement what they need to.
If the “DevOps team” is being asked to execute stops on the delivery path of every application, they become a hard dependency for application teams.
This is the “DevOps team” antipattern.
@TeamTopologies
This is the “DevOps team” antipattern.
@TeamTopologies
Orgs might set up teams to
- scale a product
- adopt new technologies
- respond time new market demand
These are all reactive. This is not a well-thought-out topology.
It is optimized for temporary problems, rather than adaptive to new problems over time.
~ @TeamTopologies
- scale a product
- adopt new technologies
- respond time new market demand
These are all reactive. This is not a well-thought-out topology.
It is optimized for temporary problems, rather than adaptive to new problems over time.
~ @TeamTopologies
