The Mentoring Gap in Tech
The technology industry has a well-documented pipeline problem. We talk endlessly about hiring, about talent shortages, about the difficulty of finding "senior" engineers. What we talk about far less is the systematic failure to develop the talent we already have.
This gap is especially acute in emerging markets. In Lagos, where I began my career, the demand for experienced software engineers far outstrips supply. Boot camps and university programmes produce developers who can write code, but the journey from writing code to building production systems — understanding architecture, debugging complex distributed systems, making sound technical trade-offs under pressure — that journey requires guided experience. It requires mentorship.
The statistics bear this out. According to a 2023 Stack Overflow Developer Survey, over 60% of developers with fewer than five years of experience report that they lack access to meaningful technical mentorship at work. In African tech ecosystems, where the average engineering team is smaller and companies often cannot afford dedicated developer experience roles, the problem is even more pronounced.
I have seen the consequences firsthand. Junior developers who are talented but directionless, writing code that works but does not scale. Mid-level engineers who have plateaued because nobody ever showed them how to think about system design. Brilliant minds leaving the industry entirely because they felt unsupported and overwhelmed.
This is not a talent problem. It is a mentorship problem. And it is one that senior engineers — those of us who have accumulated the scars and the knowledge — have both the ability and the responsibility to solve.
My Approach to Mentoring
Over the years, I have developed a mentoring approach that goes beyond answering questions when asked. It is proactive, structured, and woven into the daily fabric of engineering work. I learned early that the most effective mentoring does not happen in scheduled one-on-ones (though those matter too). It happens in the moments where engineering decisions are being made in real time.
Code Reviews as Teaching Moments
I treat every code review as a teaching opportunity. When I review a junior developer's pull request, I do not simply approve or request changes. I explain the reasoning behind my suggestions. If I ask someone to refactor a database query, I explain what the current query does to performance at scale. If I suggest a different design pattern, I walk through the trade-offs of both approaches.
At Lordwin Group, where I led a team of five backend developers, I established a code review culture where every pull request received at least two reviews, and at least one review had to include an explanatory comment — not just "change this," but "here is why." The impact was immediate. Junior developers began anticipating architectural concerns in their own code before the review stage. The quality of initial submissions improved dramatically within three months.
I remember reviewing a pull request from a junior developer on the team who had written a working but brittle API endpoint for the gaming platform. Instead of rewriting it myself, I scheduled a 30-minute pair programming session. We walked through the request lifecycle together — how the payload was validated, how the database was queried, how the response was structured, and where the failure points were under load. By the end of the session, the developer had refactored the endpoint themselves, and more importantly, they understood the principles behind the refactoring. That developer went on to independently architect a feature module for our investment platform three months later.
Pair Programming as Skill Transfer
Pair programming is the most underutilised mentoring tool in software engineering. I use it deliberately, especially for complex features or unfamiliar domains. When I was at 2am Tech, collaborating with a cross-functional team of eight engineers building Addio — a financial platform serving 500+ organisations — I regularly paired with less experienced team members on critical backend work.
One engineer on the team was strong in frontend development but had limited backend experience. Rather than assigning them only frontend tasks, I paired with them on building a Node.js service that handled vendor payment workflows. Over several pairing sessions, we worked through API design, database transaction management, error handling patterns, and queue-based architecture for processing payments asynchronously. Within two months, that engineer was confidently building backend services independently and had begun contributing to our architecture discussions.
Olamilekan Lamidi does not hoard knowledge. That principle guides everything I do in a team.
Architecture Discussions as Education
I make a point of including junior and mid-level engineers in architecture discussions, even when their immediate role does not require it. At 54gene, where I worked as a full-stack developer building data collection systems for Africa's leading genomics company, we had a cross-functional team of 10+ members. I advocated for — and helped establish — weekly architecture review sessions where engineers at every level could participate.
These sessions were not presentations. They were collaborative discussions where I would propose an architecture, invite challenges, and walk through the reasoning behind decisions. Why we chose a service-oriented approach for certain modules. Why we implemented specific caching strategies for patient data forms. How we balanced data sensitivity with system performance.
The junior engineers on the team may not have been making those architectural decisions, but by witnessing and participating in the discussion, they were building the mental models they would need when they eventually did. Several of those engineers have since moved into senior roles at other companies — and I know those sessions played a part in their growth.
Structuring Mentorship Beyond Technical Skills
Technical mentoring is essential, but it is not sufficient. The engineers I mentor most effectively are the ones where I invest in three dimensions: technical skills, soft skills, and career navigation.
Technical Skills: Building Depth and Breadth
I structure technical mentoring around progressive complexity. A junior developer on my team does not jump straight from CRUD operations to distributed systems. I map out a learning path:
- Foundations: Clean code, testing, version control discipline, debugging methodologies
- Intermediate: API design, database optimisation, authentication patterns, error handling at scale
- Advanced: System architecture, event-driven patterns, performance profiling, infrastructure as code
At Lordwin Group, I created informal "engineering growth plans" for each of the five developers I led. These were not corporate HR documents — they were living technical roadmaps. Each quarter, I sat with every team member and reviewed where they were, what they had learned, and what they needed to tackle next. One developer who started as a PHP-only backend engineer progressed to confidently working across Node.js and React within eight months through this structured approach.
Soft Skills: Communication, Estimation, and Ownership
I have watched technically brilliant engineers stall in their careers because they could not communicate their ideas, estimate their work, or take ownership of outcomes. Mentoring in these areas is harder — it requires trust and candid conversation — but the payoff is enormous.
I coach engineers on how to present technical proposals to non-technical stakeholders. How to write clear, concise pull request descriptions. How to estimate work by breaking down unknowns. How to own a failure, conduct a post-mortem, and extract lessons without blame. These are the skills that separate engineers who write code from engineers who lead teams.
Career Guidance: Navigating the Path
Especially for engineers in Lagos and across Africa, career navigation can be opaque. Which technologies should you invest in? When should you specialise versus generalise? How do you break into remote roles with international companies? How do you negotiate compensation?
I share my own career trajectory openly — from Civic MediaLab in Lagos to working with teams across Ukraine, the United States, and the United Kingdom. I discuss the decisions I made, the mistakes I made, and the skills that unlocked each transition. For engineers who aspire to work on the global stage, having someone who has walked that path is invaluable.
Impact: Developers Who Grew
Mentoring is difficult to quantify. There is no dashboard that shows "junior developer promoted to senior because Olamilekan Lamidi spent 30 minutes explaining event-driven architecture." But the evidence is there in the trajectories of the people I have worked with.
At Lordwin Group, two of the five developers I led as a senior engineer went on to secure senior engineering positions within 18 months of our time working together. One of them now leads a team of his own at a fintech company in Lagos. He told me directly that the code review culture and architecture discussions I established were the most impactful learning experiences of his early career.
At 2am Tech, the engineer I paired with on backend services went from being a frontend-only developer to a full-stack engineer within one product cycle. They credited the pairing sessions with giving them the confidence to tackle unfamiliar domains.
At 54gene, the junior engineers who participated in our architecture reviews went on to contribute meaningfully to system design decisions by the end of their tenure — a progression that typically takes much longer without structured exposure.
These are not isolated cases. They are the predictable outcome of treating mentoring as engineering work — work that deserves time, intention, and rigour.
Community Engagement: Mentoring Beyond the Workplace
My commitment to mentoring extends beyond the teams I work with directly. I have been active in the Lagos tech community, participating in developer meetups and knowledge-sharing sessions that help early-career engineers navigate the industry. I engage on platforms like ADPList, where I offer mentoring sessions focused on backend engineering, career transitions, and breaking into remote international roles.
I also contribute to the broader engineering community through technical writing — articles like this one, published on Medium, DEV.TO, and LinkedIn — that distil hard-earned lessons into accessible guidance. Every article I publish is, in a sense, a mentoring session at scale. When a junior developer in Nairobi or Accra reads about how I optimised database queries at VacancySoft or architected a real-time gaming backend at Lordwin Group, they are gaining access to production-level knowledge that they might not encounter in their current work environment.
This is not altruism. It is ecosystem building. The stronger the engineers around me, the stronger the teams I work with, the products I contribute to, and the industry as a whole.
The Business Case for Mentoring
For engineering leaders reading this, mentoring is not just a moral good — it is a strategic advantage. The data is compelling:
Faster Onboarding. Teams with structured mentoring practices onboard new engineers 40–50% faster. At Lordwin Group, new developers were contributing production code within their second week, compared to the industry average of four to six weeks. This was a direct result of the code review culture and pairing practices I established.
Better Code Quality. When junior developers understand the "why" behind architectural decisions, they write better code from the start. Our pull request rejection rate at Lordwin Group dropped by roughly 35% within four months of implementing teaching-oriented code reviews.
Reduced Turnover. Engineers who feel invested in stay. In an industry where the average tenure is under two years, creating an environment where developers are actively growing is one of the most effective retention strategies available. The Lordwin team remained remarkably stable during my tenure despite competitive market conditions.
Knowledge Distribution. In teams without mentoring culture, knowledge concentrates in one or two senior engineers. This creates catastrophic bus factor risk. By actively distributing knowledge through mentoring, I ensured that no single engineer — including myself — was a single point of failure.
A Call to Action for Senior Engineers
If you are a senior engineer reading this, I want to challenge you directly: when was the last time you deliberately taught someone something?
Not answered a question in Slack. Not pointed someone to the documentation. Actually sat down, understood where someone was struggling, and helped them build the mental model they needed to solve the problem themselves.
Olamilekan Lamidi's career was shaped by a senior engineer who chose to invest 30 minutes in a confused junior developer at Civic MediaLab in 2017. That investment compounded. It made me a better engineer, which made me a better technical lead, which made the teams I led more effective, which made the products we shipped more robust.
Every senior engineer has this power. The question is whether we choose to use it.
The technology sector does not advance through individual brilliance alone. It advances when knowledge flows freely, when experienced practitioners invest in the next generation, and when the barriers to entry are lowered not by reducing standards, but by raising support.
I mentor because I was mentored. I share because someone shared with me. And I will continue doing so because I have seen, over nine years and across six companies and four countries, that this is how you build an industry that lasts.
Top comments (0)