
Oussama Ammar
What is the most impressive thing you have ever done?
Or how a simple question turned out to be the most effective recruitment filter I have ever devised.
Originally published in French in Flâneries Libres.
While recruiting for Naijm, Samuel and I asked candidates a slightly strange question: what is the most impressive thing you did as a child? Then at school? Then at university? Then at work? What surprised us was not so much the quality of the answers. It was how many people did not really have one.
More than 1,000 people applied to Naijm. There were 213 serious applications, and we ultimately hired twelve people. There were plenty of good CVs, good schools, good companies, people who had done everything normally expected of them. But sometimes, when this question came up, not much happened. And then, every now and again, we would come across someone Samuel and I immediately wanted to meet.
One was already building things at nine and, at fourteen, had sold a product that used AI to help blind people. Years later, he was contributing to Chromium, building his own memory systems for AI, and rewriting a database in Rust. Another was twenty-two, had represented France at the HackerOne World Cup, and had spent a fairly substantial part of his young life legally breaking into other people's computer systems. Another had won a national mathematics competition in France, studied mathematics in Israel, and then spent five years in military intelligence before building AI systems. Yet another had worked with several major pharmaceutical and cosmetics groups, automated analytical pipelines at LVMH Recherche, published AI research, and built, for fun, a system for encoding a file in synthetic DNA.
Each time, the reaction was roughly the same: we wanted to know more. Not necessarily to hire the person, because at that stage we did not yet know whether they were right for Naijm, but to meet them and continue the conversation. I do not yet know whether this question predicts anything. The team is only just starting, so it would be a little early to explain that we have discovered a new science of recruitment. Perhaps in six months, some people who fascinated us for an hour in an interview will be driving us completely mad. For now, I simply know that whenever a truly unusual trajectory appeared, it sparked a great deal of curiosity in Samuel and me.

Twelve people who probably should never have ended up together
That is ultimately how this first team came together, and it is quite strange. Some have more than twenty years of experience, while others are barely twenty themselves. There is a hacker, engineers, people who have worked in pharma, luxury, or intelligence, people who know how to sell, two brothers who make films together, and Samuel Cardillo, who led technology at RTFKT before its acquisition by Nike and whose official title with us is now CTO & Open Source Tsar. I stand by that last choice with a reasonable degree of serenity.
We organized this little group into four crews: Navigators, Builders, Outriders, and Firekeepers. The Builders build, the Outriders go directly into our clients' operations, the Navigators set the direction and make commitments, and the Firekeepers look after, among other things, the story and signal around what we build. Put that way, you might think the company has been around for ages and we have merely documented a perfectly well-oiled organization. In reality, the team starts tomorrow, and we already have more RFPs than people available to respond to them.
This is probably where Naijm gets interesting.

Doing a lot with a little
We built the company around a fairly aggressive hypothesis: some operations that cost 100 million today might eventually cost 20 or 30. Obviously, not because people will work five times faster, but because you probably do not build the same operation when you can use software and agents from the start instead of adding them fifteen years later to an existing organization.
And if you really believe that a small team can achieve what previously required a much heavier organization, there is a rather awkward consequence: we should start by being able to do it ourselves. Our first problem is already exactly that. We have too much work for twelve people. The conventional answer would be fairly simple: keep hiring until capacity catches up with demand.
At Naijm, we at least want another set of questions to come before that one. Does this work really need to exist? Can we remove a step, change the process, code it, build an agent, give someone already here more capacity? And sometimes, after all that, the best answer will obviously be a human, in which case we will hire a human. The aim is not to turn headcount into a golf score. A company of seven people is not morally superior to a company of seven hundred. I simply want to see how far we can go before every new amount of work automatically produces a new job description.
Recruiting without building an army of recruiters
Recruitment gave us a first glimpse of this problem. Taking more than 1,000 applications seriously with a small team can very quickly become several people's jobs, so we built Al-Battani, the AI that supports our recruitment process. It reads applications, analyzes answers, and produces an assessment. When a file is ambiguous, it can be assessed several times, and disagreements bring the candidate to a human's attention.
But Al-Battani rejects nobody. Every rejection still requires a person to make the decision. I find this distinction interesting because discussions about AI often mix up two things: delegating work and delegating responsibility. We want to delegate a great deal of the former, and are much less ready to delegate the latter. A machine can read faster, compare more things, and start again twenty times without tiring. That does not necessarily mean we should entrust it with the moment when someone stops being a candidate.
Conversely, we allowed candidates to use AI during the tests. In fact, we wanted to watch them use it. There is little point in someone who will work with agents every day showing us what they can do after we have taken their agents away. What becomes interesting is precisely how they use them: what they delegate, what they check, how they frame their problem, and above all the moment they realize the machine has just headed in the wrong direction. Before we started trusting Al-Battani's scoring, the first assessments were also reviewed by humans. It would be a shame to build a machine to assess other people's judgment without first checking the machine's own judgment.

When software starts to contain the company
This logic gradually spread through the rest of Naijm. We built our own internal system, home to recruitment, people, RFPs, procurement, the wiki, onboarding, the brand, and part of day-to-day operations. Even the organization chart exists in code: roles, crews, access, and permissions are linked, to the point that an actual change to the organization can end up requiring a change to the system that represents it.
A few years ago, building this much internal software for a company of this size would probably have been a fairly absurd idea. Why pay a team for months to recreate inferior versions of five SaaS products costing $49 a month? SaaS won precisely because that calculation was obvious: you bought the same software as ten thousand other companies and slightly adapted how you worked to fit inside it.
But the calculation becomes less obvious when making a small tool perfectly suited to the way you work starts taking a few hours or days instead of several months. Suddenly, software can become extremely specific again. It does not have to be generic enough to satisfy ten thousand companies. It can contain your rules, your access rights, your quirks, and your slightly ridiculous crew names. Above all, it can absorb some of those little coordination rules that normally end up living in a few people's heads.
Every company knows the phrases that appear at that point: "ask X," "Y knows where it is," "she is back on Monday," "whatever you do, do not touch that spreadsheet." A rather strange part of growing a company consists of producing humans who gradually become necessary to understand how the company works. I want to see how long we can avoid that when many of those rules can be contained directly in systems.
You can automate bullshit too
Obviously, there is a rather amusing flip side to all of this: when useful software becomes cheaper to build, useless software becomes cheaper to build by exactly the same amount. And objectively, we are prime candidates for that problem. We have our own internal system, a recruitment AI named after an Arab astronomer who died more than a thousand years ago, four crews called Navigators, Builders, Outriders, and Firekeepers, and a CTO whose official title includes the word Tsar. You can quickly get very good at playing company.
I have already seen enough companies with a wonderful culture, wonderful processes, a wonderful deck, and not enough customers to know the danger is not theoretical. AI may even make this kind of bullshit much easier: today, you can very quickly build an agent, a dashboard, or an automation around a problem that perhaps should never have existed. So just because we can code something in two hours does not necessarily mean we should spend those two hours coding it.

In the end, you have to change a number
Fortunately, our business model leaves us relatively few places to hide. When Naijm works with a company, we go inside its operations, look at the processes, people, and systems, and, above all, establish with the company how much all of it costs today. Then we try to bring that number down. There is a base fee, but a significant part of what we earn depends on the savings actually achieved against that baseline.
I really like this feature of the model because it prevents us from winning simply by looking clever. We can deploy fifty agents, rebuild an entire architecture, automate twelve processes, and spend two hours explaining why the company is now AI-native. If the operation cost 100 before we arrived and still costs 100 afterwards, something probably happened that was less interesting than the PowerPoint suggests. The client is not paying for our religion. They are paying for the number.
That is what makes our hypothesis of 100 million becoming 20 or 30 interesting. For now, that is precisely what it is: a hypothesis. We have not yet earned the right to present it as a truth, and I actually prefer to write this newsletter now, while so much is still undecided. In a year or two, if it works, it will be very easy to reconstruct the story backwards. Every hire will seem obvious, every agent will look as if it had been planned from day one, mistakes will become necessary lessons, and accidents particularly subtle strategic decisions. Entrepreneurs are quite good at that.
Tomorrow, the experiment really begins
Today, the situation is much less elegant. We have twelve people starting tomorrow, more RFPs than available capacity, a lot of software, a few agents, and several convictions, some of which are probably wrong. If the agents do not enable this team to do much more with a little, we simply will not manage it.
A few months ago, we had three clients and no employees. Tomorrow, we will have the employees and already too much work for them.
Now we need to see what twelve can do.