The Moniepoint talent conversation has been circling the wrong part of the problem.

The emotional version is predictable. A founder says there are not enough qualified people. The ecosystem feels insulted. People ask whether the company pays well enough. Others blame the education system. Soon the whole thing becomes another social media fight about tone, pride, and who is allowed to criticize Nigeria.

That fight is too small for the size of the problem.

The sharper diagnosis is this:

African tech does not only have a senior talent shortage. It has a knowledge transfer shortage.

We do not merely need more people with senior titles. We need more companies that behave like talent factories, more senior engineers who behave like teachers, more juniors who behave like apprentices, more conferences that behave like classrooms, and more media that turns private engineering experience into public memory.

In other words, education has to become part of the DNA of the ecosystem, not something we outsource to universities, bootcamps, YouTube, or the occasional benevolent senior engineer.

When I say education should become part of the DNA, I mean something more practical than “we need to teach people.” I mean the ecosystem needs a set of repeatable knowledge-transfer loops:

• companies that treat talent development as infrastructure, not CSR (corporate social responsibility)
• senior engineers who treat explanation as part of engineering, not extra labour
• juniors who treat learning as apprenticeship, not passive consumption
• conferences that treat talks as teaching artifacts, not status performances
• media that treats engineering stories as curriculum, not startup decoration

The transfer layer is where seniority compounds. The value of a senior engineer is not simply that they know more. The value is that their knowledge should reduce ignorance around them.

Their experience should become better decisions, clearer documents, stronger juniors, calmer incidents, sharper design reviews, better architecture conversations, more honest postmortems, and more durable institutions.

Knowledge is the raw material; transfer is the multiplier. If what you know only helps you, that is competence. If what you know helps a team make better decisions without you in the room, that is seniority.

The issue is not public speaking for clout or writing articles for personal branding. The issue is whether African tech can make engineering judgment portable. A senior engineer should not be merely a container of hard-won lessons, but someone whose hard-won lessons become usable by the team, the company, and eventually the ecosystem.

The Moniepoint Conversation

TheCable reported that Tosin Eniolorunda said Moniepoint was struggling to fill about 500 vacancies after deciding to prioritise hiring locally. According to the report, he said the company needed people who could meet global standards because Moniepoint was not only competing locally, and he tied part of the problem to Nigeria’s education system, social values, japa, and the need to develop human capital.

The most important line in that report, for me, was not even the 500 vacancies claim. It was the final thrust of the argument: Nigeria must invest in human capital and provide alternative role models that make sustainable careers more attractive.

People can challenge the number of vacancies. They can ask whether the roles were publicly listed. They can ask whether the compensation matches the standard being demanded. They can ask whether the interview process is sensible. They can ask whether founders sometimes describe a management problem as a talent problem.

Those questions matter. They still do not erase the larger issue: a country that wants to produce globally competitive technical companies has to take human capital development seriously at every level.

After the backlash, TechEconomy reported Tosin’s clarification that the issue was not a general lack of Nigerian intelligence or capability, but a shortage of resident senior technical talent capable of building and managing infrastructure at global scale.

The distinction matters because excellence and senior operating depth are not the same thing. Of course Nigerians can be excellent engineers. That was never the interesting question. The harder question is whether we have enough institutions that turn individual excellence into repeatable senior judgment.

Senior operating depth does not appear by magic. It is produced by repeated exposure to hard problems, strong institutions, mentorship, documentation, review, failure, and time.

If a major African company says it cannot find enough senior talent locally, the question cannot stop at whether the CEO spoke politely. The harder question is what kind of ecosystem produces senior engineers consistently, what kind of companies grow them, what kind of seniors teach them, what kind of juniors become ready for that growth, and what kind of public infrastructure keeps the lessons moving.

Brightness is not the bottleneck. The bottleneck is whether we have built an education culture strong enough to turn brightness into operating depth.

The Shortage Beneath The Shortage

There is a senior talent problem, but there is also a feeder ecosystem problem, a company training problem, an education problem, a japa problem, and a knowledge transfer problem.

The last one gets the least attention because it is less convenient than blaming schools, government, compensation, or young people on social media. Those things matter, but they do not explain everything. Even where senior engineers exist, too much of what they know stays private.

• A company survives a painful outage, but the ecosystem learns nothing from it.
• A team migrates a database under pressure, but nobody writes the migration story.
• A senior engineer makes a difficult architectural call, but the reasoning never becomes a design note.
• An engineering manager figures out how to grow mid-level engineers into seniors, but the playbook stays inside one company.
• A CTO has scars from scaling payments, identity, logistics, infrastructure, or fraud systems, but the only public artifact is a panel answer about “execution” and “hiring great people.”

A collection of private scars is not the same thing as public memory.

Companies can protect secrets and still teach. Some details should remain private. Some systems cannot be discussed publicly without creating security, regulatory, or competitive risk.

But there is a large distance between exposing company secrets and publishing nothing of educational value. Mature ecosystems know how to abstract lessons without leaking secrets. They turn incidents into postmortem culture, architecture into design essays, migrations into case studies, and operating scars into reusable principles.

If almost nothing becomes portable, the ecosystem keeps paying the same tuition repeatedly.

Juniors grow slower. Mid-level engineers plateau longer. Companies import seniority faster. Conferences drift toward motivation because the people with actual scars are not teaching. Engineering blogs become product announcements because nobody wants to do the harder work of explaining the system. Public discourse becomes hot takes because the people with real context are too quiet to shape the conversation.

Then we act surprised that the ecosystem feels shallow. We should not be surprised. An industry that does not document its lessons has chosen to forget them.

Seniority Is Leverage, Not Tenure

One of the weakest habits in our ecosystem is confusing years of experience with seniority.

Somebody has been in tech for 20 years and we immediately assume they can mentor, teach, write, speak, lead, explain tradeoffs, and shape engineering culture. That is not how skill works.

Time can produce wisdom, but it can also produce arrogance. Time can produce depth, but it can also produce staleness. Time can produce judgment, but it can also produce a long history of doing the wrong thing with confidence.

Ask how much better the team becomes because someone is there, not merely how long they have been around.

A senior engineer should make the team better even when they are not the one writing code. Their design reviews should improve taste. Their code reviews should transfer judgment. Their incident response should create memory. Their documents should reduce confusion. Their talks should make hard things easier to approach. Their presence should make the system, the team, and the next engineer less fragile.

A senior engineer who cannot transfer knowledge is a single point of failure disguised as expertise.

Engineers already know what to call that in systems. A database with no replica is a recovery risk. A service that falls over when one node disappears is fragile. A deployment process that only one person can operate is operational debt.

A senior engineer whose judgment cannot be explained, documented, challenged, or taught is the human version of the same problem.

The job of a senior engineer is not to become mystical. It is not to hoard context until the company has to worship your calendar. It is not to be the only person who can touch the frightening part of the codebase.

Your job is to make the organization less dependent on your personal memory. If your expertise cannot be taught, documented, explained, challenged, reused, or built upon, then your impact is smaller than you think.

Serious engineering ladders already recognize this. GitLab’s public framework for a senior backend engineer expects clear written and verbal communication with team members, customers, and the wider community.

Tanya Reilly’s The Staff Engineer’s Path frames senior technical leadership around influence, direction, and raising the capacity of others, not only individual output.

The higher you go in engineering, the less convincing it becomes to say, “I am good, but I cannot explain.”

Communication Is Engineering Work

There is a lie many technical people quietly believe:

If I am technically deep enough, communication will take care of itself.

The lie collapses the moment you need to align a team, teach a junior, defend a tradeoff, explain risk to a founder, or write down why a system behaves the way it does.

Because you can write code does not mean you can write a useful article. Because you can debug a production incident does not mean you can give a good conference talk. Because you can design a payment system does not mean you can explain the tradeoffs in a way that helps the next engineer learn.

Those are separate skills. Writing is a skill. Speaking is a skill. Teaching is a skill. Documentation is a skill. Technical storytelling is a skill. Simplifying complexity without losing truth is a skill.

And like every serious skill, you learn it deliberately. You read people who are good at it, watch their talks, study how they structure arguments, imitate them until your own voice becomes clearer, write bad drafts, give awkward talks, learn how to hold an audience, and learn how to make complexity approachable without making it false.

Calling communication a soft skill has always annoyed me because making a hard idea clear is not soft work. Explaining a system to a founder who needs to make a business decision, writing a design document that prevents six months of confusion, mentoring a junior until patterns become principles, and standing on a stage without hiding behind jargon are all engineering leverage.

ABET’s official 2025-2026 criteria for accrediting engineering programs includes the ability to communicate effectively with a range of audiences as an expected engineering outcome.

IEEE’s Professional Communication Society published a piece called “The Writing Engineer” that cites research showing engineers spend between 20% and 40% of their workday writing, with that percentage rising sharply as engineers move up the career ladder. The same piece notes that engineers in middle management may spend 50% to 70% of their day writing, and those in senior management may spend even more.

Communication is one of the ways engineering travels through an organization. Without it, good judgment stays trapped inside one person’s head.

Sarah Drasner is worth studying here. She is not just technically strong. She is an award-winning speaker and engineering leader who has worked across Microsoft, Netlify, and Google, written books, taught engineers, and made complex frontend ideas feel approachable.

That combination matters because technical depth and communication depth are not enemies. At the highest levels, they reinforce each other. The better you understand something, the more responsibility you have to make it understandable.

What Companies Should Do

Companies cannot complain about the senior talent gap and then behave as if senior talent should fall from heaven fully formed.

One of the better responses to the Moniepoint conversation came from people who pointed out that talent in emerging ecosystems is often built, not found. Segun Olugbile made this argument in TheCable: companies in new sectors cannot just search for ready-made talent forever; they have to build structured talent pipelines.

We already have proof that pipelines can be designed.

MEST was built around intensive software entrepreneurship training and early-stage support. Semicolon Africa combines software engineering training with real-world projects. Decagon describes its mission around producing world-class software engineers from Nigeria. Andela has repeatedly positioned itself around building and assessing engineering talent for global work.

These models differ, but they share one premise: talent production is designed. It does not arrive as a miracle after the market becomes desperate.

The company example I keep returning to is Paga. In The African Engineer issue on Paga, the section titled “Talent As A System Requirement” captures the mindset African companies need.

From Paga’s earliest days, the hardest scaling problem was not only Kubernetes, SQL Server, or payment infrastructure. It was people. Brain drain was not treated as an edge case; it was treated as the baseline condition the company had to design around.

Paga’s realism matters. The company did not pretend that engineers would stay forever in a market where foreign companies, NGOs, offshore contracts, and remote roles can outbid local startups and Big Tech.

It treated two to three years as a normal tour of duty for many engineers, invested heavily during that window, and accepted that some of those people would leave with better opportunities. The goal was not to fight gravity. The goal was to make the time useful enough that both sides won.

That approach turns talent development into system design:

• recruit, train, promote, and repeat
• create onboarding that teaches both general engineering skills and the specific architecture of the company
• let some engineers learn through support or maintenance, where they see how the platform behaves under real load
• keep deeply experienced technical leads focused on the products that truly need them
• treat alumni as part of the company’s extended network, not merely “people who left”

I want more African companies to copy this kind of thinking: talent treated as operating infrastructure, not employer-branding language.

If companies want better senior engineers, they need to create the conditions where juniors and mid-level engineers can become senior without relying on luck.

That starts with onboarding that explains the system, not onboarding that quietly says, “here is the repo, good luck.”

It means apprenticeship, not silent observation from a distance. The Jedi and Padawan relationship I keep returning to is useful here. A Padawan can go to Jedi school, learn the fundamentals, study the rules, and still be assigned to a Jedi because the real formation happens in the context of actual work.

The mission teaches what the classroom cannot: timing, restraint, judgment, pressure, courage, and the cost of decisions.

Many teams skip that bridge. They hire juniors out of universities, bootcamps, or self-taught paths, give them onboarding documents, and then treat tickets as if tickets alone can mature a person. Tickets create exposure; apprenticeship turns exposure into judgment.

A junior should see how a senior reads a vague requirement, challenges a bad assumption, designs a migration, handles production pressure, communicates risk, and changes their mind when new evidence arrives.

It means RFCs and design docs, not “we discussed it in a meeting last quarter.” It means incident reviews that teach instead of shame. It means engineering ladders that make mentorship, writing, speaking, and documentation part of advancement.

It also means managers who reward people for increasing the judgment of the team, not only for closing tickets.

If the only thing your company praises is speed, nobody will write anything down. If the only visible heroes are the people who save production at midnight, nobody will invest in the boring systems that prevent midnight heroism.

If senior engineers are punished for spending time on documentation, mentorship, architecture walkthroughs, and postmortems, then the company has chosen short-term output over institutional memory.

Company publishing matters too. African Big Tech and startups should publish more technical material when it is safe to do so. Not PR announcements. Not “we are excited to announce.”

Real engineering writing:

• the migration that worked
• the migration that failed
• the queue design
• the observability lesson
• the payments edge case
• the fraud lesson
• the operational scar
• the hiring lesson
• the platform decision
• the story of how the team changed its mind

In a weak senior talent market, training belongs inside the supply chain of the company, not at the edge of it.

If your company needs senior technical talent, then your company has to participate in producing senior technical talent. You cannot keep extracting from a weak market and act surprised that the market remains weak.

What Senior Engineers Should Do

Senior engineers need to become better teachers. They do not need to become full-time educators, influencers, course creators, or conference celebrities.

It means that the ability to explain, document, mentor, and communicate tradeoffs should be treated as part of the senior engineering skillset. If you have touched real systems at scale, you owe the next generation some trail of understanding.

Write about the migration that almost killed your team. Explain why you chose Postgres over something fashionable. Document how you think about retries, queues, transactions, caching, observability, incident response, API design, or hiring. Teach juniors how to read legacy code. Give a talk about the tradeoffs behind the system you built.

Protect company secrets. Avoid pretending every lesson is universal. Stop acting like communication is beneath you.

A real senior engineer is not just the person who solves the hard problem. They make the team smarter after the hard problem is solved.

That means mentoring deliberately, documenting deliberately, speaking deliberately, writing deliberately, and reviewing code like you are training judgment rather than merely approving diffs.

I wrote about this years ago in The Alchemy of Mentorship: mentorship should let a person internalize another person’s operating model without becoming an imitation of them.

In a healthy ecosystem, senior engineers do not produce clones. They produce people who understand their reasoning well enough to surpass it, challenge it, and adapt it to problems they will never see.

When a junior asks a question, do not perform superiority. Explain the model, the tradeoff, the failure mode, and the lesson you wish someone had taught you earlier.

And if you cannot explain it simply, do not hide behind “it is complex.” Maybe it is complex. Maybe you also do not understand it well enough yet. Both things can be true.

What Junior Developers Should Do

Juniors are not innocent spectators in this either. If you are a junior developer, you cannot spend five years saying “I am just a junior” and then complain that nobody is taking you seriously.

Kent C. Dodds wrote Stop Being a Junior. He is not saying you should lie about your experience. He is saying you should stop using the junior label as a cage.

No ecosystem can mature if juniors remain passive consumers of mentorship. If you want a better ecosystem, do not wait until someone gives you permission to grow up.

Act like someone being trained for seniority:

• ask to sit in architecture meetings when appropriate
• take notes
• read the design docs
• volunteer to write the summary after a technical discussion
• ask why decisions were made, not just what ticket to pick next
• build small tools
• write about what you are learning
• give a small internal talk
• study the best engineers around you

In the Jedi and Padawan relationship, the Padawan is not passive. They watch, ask, practice, fail in controlled places, and slowly earn harder missions.

A junior who wants serious mentorship must become the kind of person who turns access into growth: listen closely, document what you learn, bring better questions, and show evidence that previous teaching changed your work.

When you do not understand something, ask. When you finally understand it, document it for the next person.

That is how you stop being dependent on vibes, titles, and rescue. Juniors should demand mentorship, yes, but juniors should also become easier to mentor by becoming active participants in their own growth.

The ecosystem needs senior engineers who teach. It also needs juniors who are hungry enough to learn in public, ask better questions, and stop waiting for perfect conditions.

Conferences Are Classrooms Too

Technical conferences matter because they are one of the few places where private experience can become shared education quickly. Many of our events still treat that opportunity too casually.

A technical conference is not a stage for senior people to perform importance. It is a knowledge transfer mechanism. A good talk should leave the room with better language, better judgment, and a clearer sense of how an experienced person thinks through constraints.

A bad talk leaves people with vibes, motivational smoke, and a slide deck that looked impressive only because nobody had time to inspect it.

A slide is not a textbook page.

If your slide contains the entire essay and your talk is just you reading it line by line, you have not given a talk. You have performed a PDF. Slides should support teaching; they should not replace it.

A good technical talk needs a problem, context, constraints, false starts, tradeoffs, examples, and consequences. The best speakers are not merely dumping information. They are guiding attention. They know what to show, what to skip, what to repeat, where the audience will get lost, and how to bring them back.

A serious technical talk should help the audience understand:

• what problem was being solved
• what constraints shaped the solution
• what tradeoffs were considered
• what went wrong or almost went wrong
• what principle the team learned
• what another engineer can reuse from the experience

Mature technical conference cultures create a forcing function for senior people to explain themselves publicly. They make private experience legible. They give mid-level engineers a chance to see how senior people frame problems.

They create archives of talks that people can return to years later. For one day, two days, or a week, they turn a room full of attendees into a temporary school.

That conviction is part of why I care about Sailsconf. I do not want it to be just another event where people come to clap for frameworks. I want it to become a serious learning environment for mid-level and senior engineers who care about building real web systems, regardless of stack.

Of course Sails, Node.js, and The Boring JavaScript Stack will have a strong center of gravity there. It is Sailsconf after all. But the deeper subject is not framework loyalty. It is how serious engineers build, operate, maintain, and explain software that real people depend on.

Beginner content matters, but ecosystems also need spaces where experienced people can talk about architecture, migrations, testing, deployment, maintainability, performance, tradeoffs, framework design, and the uncomfortable parts of operating software after the tutorial ends.

I have already seen what happens when a community gets a real educational center. Sailscasts began because I believed developers needed a place to learn Sails and server-side JavaScript properly, not through scattered fragments.

The Sailscasts community later became the official Sails.js community, and Sailsconf became a natural extension of the same belief: a technology ecosystem that wants to grow has to teach.

Documentation, courses, conferences, communities, and maintainers are all teaching surfaces. If education is not part of the ecosystem’s DNA, adoption becomes accidental and maturity becomes slow.

Media Is Part Of Knowledge Transfer

I built The African Engineer partly because I did not want African engineering excellence to remain invisible, flattened into funding announcements, founder profiles, and generic “Africa is rising” narratives.

We need stories that show how things are actually built: the constraints, the tradeoffs, the mistakes, the operational realities, the product decisions, the engineering culture, and the people behind the systems.

If media takes engineering seriously, it becomes part of the talent pipeline.

When a junior reads a good engineering story, they do not only learn that a company exists. They learn what kinds of problems are worth solving. They learn what taste looks like. They learn what senior people pay attention to. They learn that real engineering is not only syntax and tickets, but judgment under constraints. Ecosystems are partly built by the stories they tell about themselves.

If the only public stories young engineers see are stories about valuations, exits, layoffs, celebrity founders, and tech influencers, then we should not be shocked when the imagination of the ecosystem bends toward status instead of craft.

Tosin’s comment about alternative role models is important here. Human capital is not built only by curriculum. It is also built by aspiration. People become what they can see. If we want more serious engineers, we need more serious public examples of engineering seriousness.

The African Engineer, Sailscasts, Sailsconf, open source work, docs, courses, and technical essays are all connected in my mind for this reason.

They are all expressions of the same bet: education is infrastructure. A stronger ecosystem needs more mechanisms that make skill visible, judgment portable, and excellence desirable.

Escaping A Third-World Engineering Ecosystem

When I say we are still operating like a third-world engineering ecosystem in some areas, people get offended. Good. Maybe we should be offended enough to grow.

The issue is not whether Nigerians or Africans are intelligent. That argument is tired. The issue is whether our ecosystem consistently produces, exposes, transfers, rewards, and retains engineering judgment at scale.

Too much is still accidental. You become good because you found one rare senior who cared. You learn architecture because one company happened to have a strong internal culture. You understand production because one incident almost killed you. You learn communication because you personally decided to study speakers and writers.

That is too fragile for an ecosystem that wants to build companies capable of competing outside their home market.

A serious ecosystem puts education inside its operating system.

It builds ladders. It creates public memory. It rewards people who teach. It makes juniors practice senior behaviors early. It makes seniors explain their judgment. It makes companies invest in feeder systems.

It makes conferences worth attending because the talks carry real experience. It makes engineering blogs worth reading because they are not PR announcements disguised as technical insight. It makes technical writing normal, public speaking normal, documentation normal, and criticism normal.

We do not grow by pretending we are already world-class in every dimension. We do not grow by insulting ourselves either. We grow by telling the truth, copying what works, adapting it to our context, and doing the boring work of building institutions around knowledge.

The Bar Is Currently On The Floor

Here is the bar I am arguing for:

Can you build, explain what you built, document why you built it that way, teach someone else to build better, communicate the tradeoffs to people outside your technical bubble, and leave the team, company, and ecosystem smarter than you found it?

Seniority, in that sense, is not title, age, years of experience, or the number of systems you have survived. It is judgment plus transfer.

Technical depth matters; nobody is arguing otherwise. But communication is what turns individual competence into organizational leverage.

Until education becomes part of our engineering DNA, we will keep producing isolated brilliance instead of a compounding ecosystem.

The work is to stop treating excellence as an accident of which senior an engineer happened to meet, and start building an ecosystem that can reproduce it on purpose.