Direct answer, read this first
Pick your biggest bottleneck and fix that, not the whole list. For most growing teams the order is: automate deployment first, then make infrastructure reproducible and monitoring real, then add structural things like platform teams and cost governance only when the team is big enough to need them. The practices are settled; the order and timing are where teams go wrong.
01The short version
Pick your biggest bottleneck and fix that. Not the whole list, the one thing costing you most right now.
For most growing teams the order is: get deployment automated first, because manual releases are where the pain concentrates. Then make your infrastructure reproducible and your monitoring real. Then, and only when the team is big enough to need it, add the structural things like platform teams and cost governance. Everything below is an elaboration of that sequence.
The practices themselves are settled and uncontroversial: automated CI/CD, infrastructure as code, automated testing, observability, security in the pipeline, and measuring what you do with DORA metrics. Nobody disputes these. What almost no guide tells you is the order and the timing, and that is where teams actually go wrong.
02The two mistakes growing teams make
Nearly every DevOps failure at a growing company is one of two mistakes, and they are opposites.
Adopting too late.
One or two engineers own all the infrastructure. It works fine at first, so nobody changes it, and those engineers quietly become bottlenecks. Then one leaves, or gets sick during an incident, and suddenly nobody else can deploy or debug production. By the time the problem is obvious, deployments blocked for days, incidents taking hours to resolve, the damage is done. The moment infrastructure knowledge lives in one person's head is the moment to start spreading it.
Over-building too early.
The opposite error, and just as common. A ten-person startup builds a Kubernetes platform, a service mesh, and a full observability stack because that is what the engineering blogs of big companies describe. Now they maintain a system built for a scale they do not have, and every hour spent on it is an hour not spent on the product. The tell is adopting a tool because it feels modern rather than because something is actually broken.
The whole art of DevOps for a growing team is staying in the narrow band between these two. Not so little that individuals become single points of failure, not so much that you are gold-plating for a future you have not reached.
The practices do not change, but which ones matter does. The mistake is doing the right column at the wrong stage.
03The practices that matter, by stage
Team sizes here are rough markers, not thresholds. Your product, traffic, and risk profile shift them. But the sequence holds.
| Stage | Fix first | Leave for later |
|---|---|---|
| ~5 engineers | Automated CI/CD so shipping is one action; basic monitoring so you find out before customers do. | Kubernetes, platform teams, cost governance, heavy process. |
| ~15 engineers | Infrastructure as code for reproducible environments; security checks in the pipeline; DORA metrics. | Dedicated platform team, elaborate governance. |
| ~50 engineers | Team structure that scales (platform and enabling teams); cost-as-code; full observability. | Little, at this point most practices earn their keep. |
Note:The "leave for later" column is the one competitors omit, and it is the most useful. Adopting a practice before you need it is a cost, not a head start.
04The core practices, briefly
These are the table-stakes practices every guide lists. They matter, they are just not where the interesting decisions are. Here is each in a sentence, with a link to go deeper.
CI/CD
Learn more →Automates the path from a code change to production, and it is almost always the first thing worth fixing.
Service →Infrastructure as Code
Learn more →Turns your cloud setup into version-controlled files you can review, test, and roll back, so production does not live in one engineer's memory.
Service →Automated Testing
Catches problems before users do, and it is what makes frequent deployment safe rather than reckless.
Observability
Learn more →More than a dashboard of green checks. Being able to investigate problems you did not predict, by correlating logs, metrics, and traces.
Service →DevSecOps
Learn more →Threads security through every phase instead of bolting it on at the end.
Service →DORA Metrics
Four honest numbers: deployment frequency, lead time, change failure rate, and time to restore, to track against your own baseline.
05Team structure as you grow
At five engineers, everyone does everything, and that is correct. The structural question only appears later, and it is where a lot of growing teams stumble by making the same mistake: treating DevOps as a separate department that "does the ops," which recreates the exact developer-versus-operations wall DevOps was meant to remove.
The better-documented model for structuring this as you scale is Team Topologies, from Matthew Skelton and Manuel Pais. It describes a few team types that work together:
Stream-aligned teams
Own a product or service end to end
Platform team
Builds shared infrastructure and tooling the others use
Enabling teams
Help spread practices across the organization
The point is not to adopt the vocabulary. It is the underlying idea that a single centralized DevOps team stops scaling past a certain size, and that the fix is a platform others build on, not a department others hand work to.
You do not need any of this at fifteen people. You need it when coordination between teams starts costing more than the teams themselves, which is a problem you will feel clearly when it arrives.
06The 2026 additions: cost and AI
Two things have joined the standard practice set recently, worth knowing even if neither is urgent for a small team.
Cost-as-code, or FinOps
Treats cloud spend as a first-class engineering metric rather than a surprise the finance team raises quarterly. In practice it means making cost visible to engineers at the moment they make decisions, tagging resources, and treating a runaway bill as a bug. It matters more the larger you get, and it is a genuinely useful discipline that older best-practice lists predate.
AI-assisted development
Is changing how code gets written, and the honest note is a caution: research through 2025 and 2026 suggests AI can raise how much you ship while quietly raising your change failure rate too. The practice is to watch both numbers together. If your deployment frequency climbs but your failures climb with it, you are shipping faster in the wrong direction, the same measurement discipline DevOps has always asked for, applied to a new tool.
07How to actually roll these out
Not all at once. The teams that succeed with DevOps do not adopt a list; they build habits one at a time.
Start with your single biggest source of pain.
If deployments are terrifying, fix CI/CD. If you keep getting surprised by outages, fix monitoring. If onboarding a new engineer takes weeks because nothing is reproducible, fix infrastructure as code. Pick the one thing that is costing you most, fix it well enough to stop the bleeding, and let the win build momentum for the next one.
Measure as you go.
Against your own baseline from three months ago rather than against some published elite benchmark.
Resist the pull to do everything.
That is just the over-building mistake wearing a productivity costume.
Not sure which practice to fix first?
Tell us your biggest bottleneck, scary deploys, surprise outages, slow onboarding, and we will give you an honest read on what to fix first and what to skip for now.
Book a free technical callContents
Frequently Asked Questions
Common questions about DevOps best practices
Quick answers to the most common questions.
01What are the most important DevOps best practices?
02What DevOps practices should a small team start with?
03What are the most common DevOps mistakes?
04How do DevOps practices change as a team grows?
05Is DevOps a separate team?
06What is Team Topologies?
07What is cost-as-code or FinOps?
08How should I measure whether our DevOps practices are working?
Want an honest read on your practices?
Tell us your biggest bottleneck and we will tell you what to fix first and what to leave alone.
No pressure. Just a conversation to see if we're a good fit.