Thread by @jessitron

"An organization is a sociotechnical system or ecosystem that is shaped by the interaction of individuals and the teams within it"

@matthewpskelton and @manupaisable give Cybernetics a shout-out in the book @TeamTopologies

The focus on teams and their interactions:

"Teams should be long-lived and autonomous, with engaged team members."
"There is huge value in agreeing to a coherent vocabulary and way of working together across teams"

@TeamTopologies

It's Conway's Law in both directions.

Software needs to be about people,
and the arrangement of people is also about the software.

"an organization is the interaction between people and technology."

@TeamTopologies

"the team as the fundamental unit of delivery"

Software isn't written by individuals. That's limiting and unreliable. Software is written by teams. Face it.

@TeamTopologies

The limit of what a team can do is cognitive capacity.

@TeamTopologies

It isn't how much we can do, it's how much we can know.

The team is "an indivisible element of software delivery."

And not the team you just assigned people to for this budget cycle, either. Teams are long-lived.

Big re-orgs are like big software re-writes. Don't do it.
Instead, continually (re)shape teams.

@TeamTopologies

@TeamTopologies Definition of a monolith: "any indivisible software part that exceeds the cognitive capacity of any one team."

@TeamTopologies

Restricting the cognitive load of one team's responsibilities is the difference moving toward mastery and circling in context switches.

@TeamTopologies

@TeamTopologies Conway's Law means that business organization is not a business decision. It's also a technical decision.

@TeamTopologies

"Not all communication and collaboration is good."

Want software components to remain independent?
Check that those teams never have to coordinate.

(Sharing a repo or a task-tracking tool might cause this.)

@TeamTopologies

"Reorganizations for management reasons should become a thing of the past."

@TeamTopologies

I remember in Domain Driven Design, @ericevans0 noted that the careful bounded contexts in the software are disrupted by business re-orgs.
Yeah - don't do that.

@TeamTopologies @ericevans0 "Who is on the team matters less than the team dynamics"

except that who is on the team matters for team dynamics.
"Some people are unsuitable to work on teams or are unwilling to put team needs above their own."

@TeamTopologies

As a company grows, its org structure needs to change too.
At 5, 15, 50, 150, 500 people, there's a fundamental shift in how teams interact.

Therefore, your software needs to be re-architected at each of these growth points.

@TeamTopologies

Abolish annual or merit ratings. Abolish management by objectives. Abolish individual bonuses.

"Looking to reward individual performance … drives poor results and damages staff behavior"

The team is the unit of allocation. Not the individual.

@TeamTopologies

Cognitive Load comes in three varieties.

Intrinsic - "How do I sort an array in JS?"
Extraneous - "How do I deploy this?"
Germane - "How does this interact with businesspeople and other services?"

Minimize the first two, so that you can handle more of the last.

@TeamTopologies

@TeamTopologies When a team's cognitive load is too high, coherence dissolves. You get a group of individuals instead, "each trying to accomplish their individual tasks without the space to consider if those are in the team's best interest."

@TeamTopologies

"Teams using more abstractions and reusing code will have smaller but not necessarily simpler codebases."

@TeamTopologies

Re-use is also coupling, and coupling adds complexity.