DevOps is not a job title — it's a way of working most teams still get wrong

If you have ever posted a job for a "DevOps Engineer" and expected one person to fix your entire delivery process, you have misunderstood DevOps. That misunderstanding is so common it has become the industry default — and it is why so many teams adopt the tools without the results.

Where the DevOps concept came from

DevOps emerged from a specific problem in software delivery. Development teams wrote code and threw it over a wall to operations teams who were responsible for keeping systems stable. Each team was incentivised differently — developers rewarded for shipping features, operations teams rewarded for stability. The result was constant conflict, slow releases, and blame cycles when things broke.

The DevOps movement, formalised around 2009 through Patrick Debois and the "Velocity" conference, proposed a solution: break down the silos. Give developers responsibility for the operational health of what they build. Give operations teams input into how software is designed. Make both sides share ownership of the delivery pipeline.

The key insight was cultural, not technical. The tools came later.

The three ways: the framework most DevOps discussions ignore

Gene Kim's "Three Ways" framework describes the foundations of DevOps thinking. The First Way is about flow — optimising the entire value stream from development to the customer, not just individual steps. The Second Way is about feedback — building feedback loops so problems are caught fast and knowledge flows in all directions. The Third Way is about continual learning — creating a culture of experimentation and learning from failure rather than blame.

Most organisations that claim to "do DevOps" are only implementing tools associated with the First Way (CI/CD pipelines, automation) without addressing the Second and Third Ways. This is why so many DevOps transformations fail to produce the promised results — the culture does not change, only the tooling does.

What DevOps looks like when it is actually working

In a genuine DevOps culture, developers write code and are also responsible for it in production. They are on call when it breaks. They monitor its performance. They get paged at 2am if something goes wrong. This accountability changes how code is written — you write more defensively, add better logging, design for observability.

Releases are small and frequent. Instead of big quarterly releases that are stressful events, teams ship small changes multiple times per week or day. Each small change is easier to test, easier to debug if something goes wrong, and faster to roll back.

Failure is expected and planned for. Post-mortems are blameless — focused on understanding the system failure, not punishing individuals. This creates an environment where people report problems honestly rather than hiding them.

DevOps in African tech teams: what changes and what stays the same

In Cameroon and across Central and West Africa, tech teams often start small — two to five engineers handling everything from feature development to server management. This is actually a natural DevOps environment. The artificial silos that DevOps tries to break down never formed in the first place.

The risk for growing African tech companies is that they replicate the silo model as they scale. As teams grow, there is a temptation to create separate "backend," "frontend," and "infrastructure" teams that stop talking to each other. If you are scaling, resist this. Keep cross-functional ownership explicit in how you structure teams and measure performance.

Budget is always a consideration. The good news: the most important DevOps practices are free. Blameless post-mortems cost nothing. Code review culture costs nothing. On-call rotation costs no software license. The expensive parts — monitoring platforms, CI/CD infrastructure — have free or low-cost tiers that are entirely adequate for early-stage teams.