Why a town?
Last month I posted a picture of myself as an octopus. Five arms, five jobs: Site Reliability Engineer, Cloud Engineer, Platform Engineer, SDET and CI/CD Engineer. All of them regularly squeezed into a single “DevOps Engineer” vacancy.
Behind that post sit two questions that keep coming back in delivery work. Engineers ask which of those arms to grow next. Engineering leads ask a more urgent one: which of them do we actually need, right now, to go faster, safer?
A list of job titles answers neither. Titles describe people, and both questions are really about work: where it gets stuck, and who knows how to unstick it.
I meant to answer them in one blog post. Two weeks later I had a town, eleven islands and a mayor. Its name is Flow Town. Let’s have a tour together!
One small town, two ways in
Every city has at least two maps. The traffic map tells you where the jams are today. The metro map tells you where you could go next. Same streets, different questions.
Flow Town works the same way. Both views share one inventory: 156 topics and 163 tools across 38 groups, each topic linking to books, courses and references, most of them free.
- The Delivery map is the traffic map. It starts from a wait or a failure you can see, and follows it to the practices and roles that clear it.
- The Engineer roadmap is the metro map. It groups the same topics into islands, one per specialisation, so you can pick a destination and see the stops along the way.
There’s no account to create. Open it, wander, leave when you want.
Where is your delivery stuck?
The Delivery map is for CTOs, tech leads and teams. It lists 25 common pain points, ordered the way work travels: from engineers setting up a laptop to running in production. From “PRs wait days for review” to “nobody trusts the test suite”, it suggests which capability fixes each one, and who can help.
You start from the symptom, not the solution. That matters, because most of us reach for a tool first. In my article on merge queues, a 30-minute CI run capped a whole company at roughly 16 merges a day. A merge queue helps, but only if the failure rate is low enough. The real fix often sits one stop earlier, in tests nobody trusts.
Each pain point leads to the practices that address it, the roles that usually own those practices, and the tools you’ll meet along the way.
In my experience the jam is rarely a missing tool. It’s more often a missing owner, a handover nobody designed, or a feedback loop that takes a day instead of ten minutes. DORA’s 2025 research makes a similar point about AI: it amplifies what’s already there. Teams with solid foundations get faster, teams without them produce more code that waits longer.
You don’t need to fix all 25 at once. Find the one that costs you the most this quarter, and start there.
Choose your next specialisation
The Engineer roadmap is for engineers. It splits the same inventory into 11 islands, from QA & SDET to SRE, each with the topics worth learning, the tools you’ll run into, and resources to get started.
The islands overlap, and that’s on purpose. An SRE automates infrastructure. A platform team often owns the CI templates. An SDET can spend most of the week improving pipelines. The boundaries move from one company to the next, so treat the islands as neighbourhoods, not countries with border control.
If you’re not sure where to go, I’d start from the problem you secretly enjoy fixing, rather than the title that pays best this year:
- Flaky tests annoy you enough that you hunt them down: the QA & SDET island.
- You’re the one who speeds up the build when nobody asked: CI/CD.
- You enjoy a calm on-call week more than a new feature: SRE.
- You keep writing the same deployment setup for every team and want to do it once, properly: Platform.
That’s how I ended up in CI and test automation myself, six years ago at Unity. Not from a career plan, but from being the person who couldn’t stop poking at a slow pipeline. I enjoy optimising every process I can get my hands on, from personal workflows to systems used by hundreds of engineers.
Enablement Engineering: the umbrella over DevOps, SRE and QA
All eleven islands share one job: helping product teams deliver software safely and often. I call that Enablement Engineering. Some larger companies call it engineering effectiveness. Either way, it treats engineering as a system to improve, rather than a list of job titles to hire for.
DevOps started as a culture shared by development and operations. Enablement Engineering is the work that makes that culture concrete: the pipelines, test suites, platforms and dashboards that let a product team ship on a Friday afternoon without holding its breath.
It covers these five areas (and possibly more I forgot!):
- Quality: testing, test automation and defect prevention. That’s the QA & SDET island.
- Reliability: SRE principles, observability, resilience and fewer incidents.
- Delivery: CI/CD, release automation and deployment safety.
- Platform: internal tooling, developer platforms and infrastructure. Removing the friction that keeps developers out of their flow.
- Security: security automation and policy enforcement built into the pipeline.
Small teams often have one person covering several of these. As a company grows, each area needs a clear outcome and an owner, and that’s usually when the “DevOps Engineer” job ad starts listing five jobs at once.
How it was built, and what it isn’t
Flow Town stands on other people’s work:
- DORA’s research and the book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, for what actually moves delivery performance.
- The Google SRE books, for everything reliability.
- Stéphane Robert’s DevOps guides, a remarkable free learning portal in French that taught me more than a few things. Merci Stéphane.
- roadmap.sh, whose navigation inspired the Engineer roadmap.
The rest comes from six years of CI and test automation work at Unity and from research since.
A few honest caveats:
- It’s one person’s curation, and I’m a CI and test automation engineer. Expect my islands to be more detailed than the ones I’ve only visited.
- The illustrations are AI-generated. The content and the curation are mine.
- Some book links are Amazon affiliate links, labelled on the About page. Most links go to free resources.
What’s next for the town
A town is never finished. Topics will move, tools will retire, and some islands will grow as people tell me what’s missing.
That’s the one thing I’d ask of you: if a pain point doesn’t match what you’ve lived, or your favourite resource isn’t there, open an issue on the Flow Town forum. I read every one.
And while you’re walking around, keep an eye out. The mayor hid a few things in town.
I’m Théo Penavaire, a senior CI/CD and Test Automation Engineer with more than six years of experience, now freelancing from Norway. If the Delivery map points at a jam you’d like a second pair of eyes on, reach out.