Teams, ownership and Conway's law

the system has four services and the company has four teams, and nobody planned that.

Conway's law

they wanted the architecture split three ways, so they reorganised the teams first and waited.

Inverse Conway manoeuvre

one team owns a slice of the product end to end and does not hand anything to another team to finish.

Stream-aligned team

another team's product is your deploy pipeline, and you are their customer rather than their ticket queue.

Platform team

two specialists sat with your team for six weeks, taught you the testing approach, and then left.

Enabling team

the pricing engine needs actual mathematicians, so it has its own team rather than living in everyone's backlog.

Complicated-subsystem team

you consumed their API and never spoke to them, which was the point.

X-as-a-service

the team owns nine services and can explain four of them.

Cognitive load

you opened a pull request against another team's repository and it sat there for eleven days.

Code ownership

the alert fired and it took forty minutes to establish which team was supposed to answer it.

Orphaned service

the team that wrote the code carried the pager for it, and the retry logic got better within a month.

You build it, you run it

one person is responsible for answering at 3am this week, and next week it is you.

On-call rotation

there was a supported way to spin up a new service, and doing it that way took an afternoon instead of a fortnight.

Golden path

you deployed to a new environment without opening a ticket or learning what the infrastructure was.

Internal developer platform

one person was on holiday and the release could not go out until they got back.

Bus factor

the database changes all go through one team, and their queue is nine weeks long.

Silo

the same engineer saves every launch weekend and gets praised for it, and nothing about the launches changes.

Hero culture