A DevOps maturity model for African mid-market companies.

Auto-generated and lightly edited. Let us know about errors.

Chinedu Okafor: This session is for engineering leaders at mid-market African companies who are trying to plan a DevOps roadmap. I'm going to walk through a five-stage maturity model we use with customers. Stage one is automated builds and tests. Every commit triggers a build. Every build runs a test suite. Every failed build blocks deployment. This sounds basic, and it is, but the number of mid-market teams I meet who skip past it is striking. They jump straight to Kubernetes because they read about it on Hacker News, while their actual deployment process involves someone manually SSH-ing into a server. Don't do that. Get continuous integration solid before you do anything else. Stage two is automated deployment. Every successful build deploys automatically to a staging environment. Promotion to production is a one-click action. The deployment artifact is immutable. Rollback is a one-click action. At this stage you can ship multiple times a day if you want to. You'll catch most of your issues in staging because staging now actually represents production. Stage three is observability. This is where logs are not enough. You need three things — structured logs, distributed tracing, and structured metrics. Logs tell you what happened on one machine. Traces tell you what happened across the system for one request. Metrics tell you what's happening in aggregate. Most teams have logs. Fewer have metrics. Almost none have tracing until they hit a production incident that they couldn't have diagnosed without it. Stage four is reliability engineering. SLOs and error budgets. You define what reliability looks like for your business, you measure it continuously, and you allocate engineering effort against reliability the same way you allocate it against features. This is where you start saying — we can't ship the new feature this week because we've burned our error budget. Stage five is platform engineering. You have a dedicated team building internal tooling that makes product engineers more effective. This is what big tech does. It's where most of the conference talks are. And it's a trap for mid-market companies. You need a critical mass of product engineers — typically 50 or more — before a platform team pays for itself. Below that, you're better off buying the platform pieces and integrating them. The pattern I want to flag — most of our mid-market customers should be at stage three or four. Stage five is rarely the right destination, and trying to skip stages from one to four is how teams end up with sophisticated dashboards on top of unreliable deployment pipelines. My advice to a CTO at a 30-engineer African mid-market company is — get to stage three, take a year to bed it in, then evaluate whether stage four is worth the investment. Don't aim for stage five.