The advice the African developer ecosystem gives young engineers is well-intentioned and mostly wrong. Not factually wrong — learning to code is good. Remote work is real. The global market is accessible. All true.
But optimised for the wrong outcome.
The ecosystem has been shaped by a specific success story: a Nigerian developer gets a remote job at a US or European company, earns in dollars, builds a comfortable life. That is a legitimate achievement. It is not the ceiling. And the advice that produces that outcome does not produce the outcome beyond it.
" Africa doesn't have a shortage of engineers. It has a shortage of engineers who understand institutions well enough to build for them.
What thinking in systems actually means
A system is not a codebase. A system is the full set of interacting components — human, institutional, technical, environmental — that produce an outcome. When you're building for an institution, the codebase is one component among many. Often not the most important one.
Thinking in systems means asking: who are all the actors in this process? What are their incentives? What breaks when the power goes out? What happens when the person I trained leaves? What does success look like in five years, not five months?
Most developer training produces people who can answer technical questions. The work I do requires people who can identify the right questions. That is a different capability entirely.
Build for institutions, not just for users
Consumer product thinking — the dominant frame in global tech — is user-centric by design. Institutional technology is different. The institution is not a single user. It is a collection of people with different roles, different relationships to the system, different incentives. It has a lifespan that extends far beyond the current administration.
Building for institutions means thinking about governance, not just UX. Designing for handover, not just adoption. Caring about what happens to your system in year seven, not just at launch.
Position yourself for work that matters
The intersection of technical depth and institutional understanding is underpopulated. There are many developers who can build software. There are relatively few who understand how governments procure it, how bureaucracies adopt it, how policy shapes what's possible. That rare combination is where leverage lives.
Learn to read policy documents with the same fluency you read technical documentation. Study failed govtech projects — the post-mortems are instructive. Build a mental model of how your country's procurement system works. Read widely outside technology.
" The ceiling is not the dollar salary. It's the quality of the thing you built and the breadth of the people it serves.
And when you get the opportunity to work on something that actually matters — take it seriously. Do it properly. Document it thoroughly. Build it to last. That's what's worth building toward.