I stumbled on a post that said Telegram runs with just 30 employees. Thirty. For a platform serving over a billion people. And I just sat there, stunned. I couldn’t even pretend to process it. My mind was properly mindfucked. I kept asking myself, how? How do you run a platform that huge, with that many features, with barely enough people to fill a small Zoom call?
Then came OnlyFans. Yes, that OnlyFans. Whatever people choose to use it for is irrelevant. What matters is that the company managed to generate over a billion dollars in profit within just three years, with a team of only 42 employees. No bloated org chart and endless chains of middle management designed to make lives miserable. Just a few people, some servers, and insane efficiency.
Clearly, these companies were not playing by the same rules. They had figured out something the rest of us hadn’t.
You see, I’ve worked in places where excellence wasn’t just a fancy word on a mission statement. People like Aigboje Aig-Imoukhuede and Herbert Wigwe weren’t just exceptional because they worked long hours (they did), but because they were razor-sharp, operated on a high-performance frequency, and demanded the same from everyone around them. It was just the minimum standard and you either leveled up or you got left behind.
That kind of energy had a way of forcing you to either grow fast or quietly excuse yourself.
Luckily, I got a close-up view of that energy early in my career at Access Bank. That place was, without exaggeration, the most valuable kind of pressure cooker. It gave no quarter to mediocrity. You might have walked in with vague ambition, but if you made it through, you came out with a very clear understanding of what elite execution looked like. It wasn’t just about working hard; it was about operating with sharpness and speed, and pressure. You were expected to make decisions quickly, own your output, and never use bureaucracy as an excuse. It could be intense and occasionally unforgiving, but it was the most formative professional experience I’ve ever had. It taught me what a real high-performance culture feels like.
So when I started Lendsqr, I made a personal decision: we were going to build that same culture of excellence, but make it smarter, leaner, and automated to the bone. Not just hiring people who could take instructions, but people who could figure things out, solve problems without fanfare, and keep things moving without layers of hand-holding. A place where high performance is the norm, not the exception. Where being technical isn’t a job description but a shared mindset. That’s the only way we were ever going to scale without becoming bloated or mediocre.
No dead weight, no dumping ground.
I’ve always held the view that companies should not become homes for “pity departments”. Those departments that exist just so someone can hold a title and collect a paycheck. These are often the places where underperformers get quietly reassigned, tasked with managing something non-essential, while everyone pretends it’s all part of the plan. It’s the professional equivalent of sweeping dust under the rug. Everything looks neat until you bother to look closely.
At Lendsqr, we don’t make room for that kind of organizational clutter. If you’re unable to operate at the standard required for any team in the company, then you don’t make it in. We don’t insulate some teams from pressure while expecting excellence from others. Whether you’re in Marketing, Finance, HR, Engineering, or Product Operations, the expectations are the same. You must be able to think clearly, make good decisions quickly, and execute without someone constantly guiding your hand.
And yes, that meant making uncomfortable choices about how we evaluate applicants. Academic performance doesn’t tell the full story, but it does show a history of effort.
We obsess over grades. And also don’t obsess over grades. Now, I’m confused 😵
We’ve hired smart individuals from polytechnics who often outperform those with a first-class degree. Some of our most impactful people didn’t come from flashy schools or big brands. One of our best engineers never finished school but what he did finish was a long list of complex features, urgent fixes, and systems that never go down. That’s what matters here.
In Lendsqr, we care about whether you can think critically, learn quickly, and do difficult work without falling apart. And we’ve built our hiring process to reflect that. It includes rigorous evaluations and hands-on filters. If you’re not resourceful and ready to be useful, you’re not making it past the first few stages, and that’s intentional.
Everyone builds and automates. No exceptions.
One of the biggest problems I’ve seen in companies is how much time gets wasted on repetition and low-value tasks. You’ll find people spending hours each week copying and pasting the same reports. Others wait endlessly for the data team to pull simple numbers they could easily learn to access themselves. Some won’t touch a broken workflow until engineering steps in to fix it because the companies decreed that tech stuff is best done by tech bros, which reinforces silos and slows everyone down. So we killed that way of working at Lendsqr.
From the very beginning, we agreed that if we wanted to operate like a lean, high-performance company, everyone, regardless of their title or department, is expected to be hands-on. That means being able to access the data you need without blockers. If you need numbers, you learn how to write SQL queries. If a workflow is too manual, you build your own automation using n8n. If something breaks, you check the logs, read the error messages, and try to figure out what went wrong before escalating. You don’t sit around waiting for engineering to solve problems that are well within your ability to handle. Whether it’s drafting and testing HTML emails, playing with APIs using Postman, or simply understanding how different parts of the product talk to each other, we expect everyone to be curious and capable enough to dive in.
And the expectations don’t stop at technical tools. Even engineers are required to understand the fundamentals of credit risk, because it’s not enough to only build features; you need to understand the domain in which they exist. Since you’re expected to build lending platform for lenders, you must know what good lending looks like.
Just to give you a perspective, our ML models are written by guys from the Product Ops team and the best SQL writers are not even from engineering. Our finance team would coach an engineering team how to use n8n for automation.
There’s no space for helplessness, because we don’t make room for it. If you don’t know how to do something, you’re expected to learn. “I’m not technical” is not a viable excuse in our culture. Even our HR lead builds their automations to make hiring workflows more efficient. That’s how embedded this mindset is. If you work at Lendsqr, you’re expected to think critically, move independently, and make things better without needing permission. You don’t throw problems over the wall and hope someone else catches them.
Product owners have to be actual owners
At Lendsqr, product ownership means just that: ownership. It’s not a role for someone who only writes tickets or sets up meetings. Being a product owner here means taking full responsibility for how your product area performs; technically, commercially, and from the user’s point of view. They’re not simply there to relay messages between engineering and other teams. They have to think clearly about trade-offs, understand how things work under the hood, and stay close to the business and user needs, as this helps them make better decisions and move things forward without needing constant direction.
This kind of ownership requires a wide lens. Our product owners are expected to speak the language of engineers well enough to collaborate deeply and problem-solve together. At the same time, they have to understand the business strategy, how the product supports growth or efficiency, and how to prioritize based on actual outcomes, not gut feelings or noise. And then there’s the user experience; something we expect product owners to care about deeply. Whether it’s a micro-interaction or a major feature flow, they need to be able to evaluate whether it makes sense, feels intuitive, and delivers value.
To support this level of ownership, we’ve built weekly training sessions into our routine. These aren’t theoretical workshops. They’re practical training sessions based on what we encounter day-to-day. We spend time walking through how to write postmortems, not just so that issues are tracked, but so that context is preserved and others can step in quickly. We go through how to escalate issues intelligently, making sure the right people have the right information. Many of these end up with automations that owners do themselves.
We also train product owners on how to debug small issues enough to avoid bottlenecks and dependency loops when engineering is tied up. That kind of autonomy matters when things move fast. On the planning side, we show how to break down features clearly and structurally, so engineering and design teams aren’t starting from confusion or vague ideas. And we talk about usability; what makes an interface intuitive, how users think, and how to bring simplicity into even the most complex flows.
All of this isn’t because we expect perfection or want everyone to be an expert in everything. It’s because we want product owners who are genuinely helpful and capable of driving execution forward. The less they need hand-holding, the more momentum the entire team builds. And over time, that makes the difference between a product team that’s reactive and one that’s constantly pushing things ahead.
Everyone is an engineer, whether it says so on your job title or not
At Lendsqr, technical skills aren’t confined to the engineering team. While we have a team of skilled engineers who handle the deep, complex system work, almost every other team in the company engages with technology in real, hands-on ways. And that’s by design. Being “technical” here isn’t about what degree you have or whether your role has the word “engineer” in it. It’s about what the work demands and whether you’re willing to level up to meet it.
Take our Product Ops team, for instance. Their job isn’t to be passive intermediaries between customers and engineers. They’re expected to understand how our systems work well enough to build automations, write simple scripts, and investigate issues thoroughly before handing anything off. They know how to trace the source of a problem and propose concrete solutions, not just escalate tickets. The Growth team, too, doesn’t sit around waiting for data to arrive. They query APIs themselves, generate the reports they need, and even troubleshoot issues when things don’t look right. In meetings with customers, they can speak fluently about the system, sometimes so well you’d think they were on the engineering team.
We’ve made it clear that there’s no safe zone in the company where you can avoid learning some level of technical skill. Even people who would never describe themselves as “technical”, including those who started out with zero engineering background, are now comfortable reading logs, writing complex queries, or debugging issues.
We’re not trying to turn everyone into a full-stack developer. That’s not the point. What we are doing is removing the kind of fragile dependencies that slow teams down. When people know how to investigate and fix problems themselves, they move faster. When they understand how the systems behave, they make better decisions. And when they’re confident navigating technical tasks, they become much harder to block or derail.
Why do all this? Because we want to scale without bloat
Lendsqr currently serves more than 2.7 million users and supports the lending operations of over 7,000 lenders. And all of this is being run by a team of fewer than 40 people. That’s not a happy accident or a temporary situation we’re trying to fix. It’s the outcome of a deliberate and disciplined approach to building the company. From the very beginning, we made a decision to grow differently by doing more with less, but do it sustainably and without compromising quality or ambition.
Our goal isn’t to keep hiring more people as we grow. In fact, we’re designing the company so that we won’t need to significantly increase our headcount until we’re serving 10 million users or more. And the only way that’s possible is if the company is designed to be resilient and efficient from the inside out. That means building systems that don’t crack under pressure, designing workflows that don’t rely on a single person’s heroics, and creating infrastructure that can handle scale without collapsing under the weight of complexity.
Instead of throwing more people at every new problem, we focus on solving those problems in smarter ways. We build internal tools that take away busywork and allow one person to handle the kind of operational load that would normally require a team. We invest heavily in training and cross-functional learning so that people are empowered to troubleshoot, experiment, and resolve things on their own. We treat documentation as an asset, not a chore, and we create a shared understanding of how things work so that knowledge isn’t hoarded or lost when someone moves on.
That’s what we’re really building: a culture that survives change. One that doesn’t depend on any one person or team to keep the company running.
It’s not perfect. But it’s deliberate.
We’re not pretending to have it all figured out, and we’re still 10,000 miles from Telegram-level productivity. But that’s the bar we’ve set for ourselves. That’s the north star we’re aiming at because it forces us to think differently about how we build, work, and grow.
This isn’t about chasing perfection but being intentional. I want to build a company where people feel genuinely challenged, where every role comes with stretch, discomfort, and pressure that pushes you to level up. A place where you can’t just coast. Where the expectation isn’t that you tick boxes or do your part, but that you grow sharper, faster, more useful over time.
And it’s not just about engineers chasing technical mastery. We want a culture where every single person (from Marketing to customer support to HR) is constantly upping their game, learning something new, and improving how they solve problems. We want curiosity to be second nature and mediocrity to feel unnatural.
This kind of environment isn’t built for everyone because it doesn’t offer a quiet corner to hide in. But the people who thrive here? They leave changed. They build resilience, operate like owners, and leave knowing how to figure things out in any room, any company, and under any pressure. And honestly, that’s exactly the kind of company that’s worth building.