Team Topologies: My Reading Journey

I love the book “Team Topologies”.

It’s one of those annoying books that’s so full of good stuff that if you highlight what’s worth remembering, you end up highlighting the entire book (and then you think to yourself: “well, that was useless”. Or is that just me?).

What I like so much about the book is that it puts into words several things that I had kind of figured out, but hadn’t processed deeply enough to have words for some of my thoughts, much less shaped a well-rounded whole.

When to Rewrite

One of the hard questions of an engineering manager is how to deal with technical debt, especially of the crippling variety.

Three bad choices

Do you throw out the existing product, and rewrite from scratch? Everybody who has tried that has learned painful lessons. Rewrites are always harder than you expect.

Do you gradually refactor? That means fighting an inadequate product for a long time, painfully juggling old-style and new-style parts of the product, and perhaps not being able to excise all the unpleasant aspects of the old system (after all, the parts that bug yo uthe most are probably also the ones hardest to change).

The Three Ways and Conway's Law

First, a quick refresher about those terms I used.

Hang on, what ways?

If you’ve read some DevOps literature, you’ve certainly come across Gene Kim’s Three Ways, his core principles underlying the DevOps approach. These ways are

• Systems Thinking: always considering the system (e.g. your product) as a whole, not just the fraction of the whole you’re concerned with
• Amplify Feedback Loops: actively seeking out and creating feedback loops, carrying information from “right” to “left”, upstream in the development process
• A Culture of Continual Experimentation and Learning: well, exactly that: actively finding and welcoming opportunities to try new things – and accepting the occasional disappointment

And what abut that Mr Conway?

Conway’s law states that organisations always create products whoes architecture is similar to the organisational structure itself.

The people you hire are your architecture

If you’re starting a new company, or a new team, something critical will happen: the people you hire, their skills and interests, will define how they work together… and that will invariably shape your architecture.

So for budding organisations Conway’s law extends to hiring: you’ll end up with exactly the architecture your first few engineers dictate.

In a very real sense, your first hires will be your architecture.

Dunbar's number in remote teams

Excuse me, what number again?

Maybe you’ve heard of Dunbar’s number. It’s the maximum number of people you can have a stable social relationship with: the kind where you know the other person, at least somewhat. Dunbar guesstimated this number at about 150 people, for humans.

Dunbar’s number is important because it puts a cap on the size of departments, or teams-of-teams, or other organisational structures. Once the group becomes too large, it breaks down and splits into subgroups; you won’t know all the people in your organisation, only about 150 of them.

DevOps in Aerospace

DevOps in Aerospace

DevOps is for software companies. You’re an aerospace company.

…are you sure you’re not a software company?

Because when I look at aircraft, they have lots of software in them. From avionics to in-flight entertainment, from flight-critical to luxury.

And let’s not get started with all the software that’s driving processes on the ground: during design, manufacture, maintenance and operation.

(And remember, I’ve got a degree in Aeronautical engineering, as well several years’ experience in avionics development – I know this first-hand.)