When I explain how we work, the first question is almost always the same: "So your engineers must be exceptional. Top of their class? Best universities?"
No. They're not.
People assume the interesting thing about our model is the 70/10/20 split — that 70% of what a client pays goes straight to the engineer writing the code, not to an agency taking a 35-to-50-percent cut, not to a layer of managers between the client and the work. That part is true, and it does make us a better deal. But it's not the part that actually matters, and the split isn't where the real story is. The story is what happens to ordinary engineers once they're inside this environment.
The question behind the question
We don't win by recruiting geniuses. The engineers we work with are, for the most part, ordinary programmers — the same people you'd find at any competent software company. What's different isn't who they are when they arrive. It's who they become.
I couldn't even pick the winners
I'll give you the evidence that convinced me, because it's evidence against my own judgment.
In our early years, before any of the AI tooling or the current model existed, we had a few dozen ordinary programmers and a simple offer: if you want to run your own branch office, we'll help you. The company puts up the capital. You go to a city of your choosing — usually your hometown — register the company, rent the office, hire the team. Keep it from running at a loss in the first year, and a meaningful share of that branch is yours, growing every year after.
Anyone who asked, we said yes to. We didn't screen for who looked like leadership material. We didn't run assessments. If you raised your hand, we backed you.
Close to twenty of those ordinary programmers became branch managers. Almost none of them failed.
And here's the part that stays with me: several of the people I privately doubted — the ones I looked at and thought, "this one won't make it" — went on to build the largest, fastest-growing branches we have.
I was wrong about them, repeatedly. If our success came from picking the right people, I wouldn't have misjudged so many of them so badly. It doesn't come from picking the right people. It comes from what happens to people once they're in.
What actually changes them
Put a programmer in a particular kind of environment and something shifts. He answers directly to the client, with no middle layer making decisions for him. His income is tied to the value he creates, not to the hours he logs. He is expected to own the outcome — not to close tickets, but to make the client's problem his problem.
Running a branch was exhausting, especially at the start, when one person did the work of several. But that's exactly why it changed people. Every one of those ordinary programmers was stretched and sharpened by it. The environment did the work that no recruiter could.
When we rebuilt our operations center in 2018 and introduced the 70/10/20 split, the same thing happened again, on the engineering side this time. Engineers who had spent their careers only writing code — Bin Hu, Xiaoming Li, and many others — became Account Owners, took on the split model, and grew into the de facto CTOs and CIOs of the clients they served. Same people. Different environment. Different outcome.
What it looks like up close
Let me show you one of them, because the transformation is easier to believe when you watch it happen slowly.
Xiaoming Li is an ordinary programmer. Quiet, low-key, not much of a talker, often carrying the faint tiredness of someone who has been working late. By his own account, he still doesn't think of himself as having any special "agile mindset." Two years ago he was handed a project, and without quite noticing, it turned him into the de facto CTO of the client's company.
The client ran a logistics business — a company renting out collapsible containers for transporting liquids. Their management cared deeply about technology but had no technical people of their own, and had taken a few wrong turns building their systems. Xiaoming came in, on paper, only as a project supervisor: his job was to review the work of an outside development team. He wasn't supposed to write code at all.
He ended up doing far more than that. Nobody asked him to.
The client had no IT staff, so when they wanted an office automation system, he helped them choose one, bought them a server, registered the domain, deployed and configured it himself, and built out their approval workflows. When they wanted analytics from their business data, he built the first reports himself, then taught the development team to build the rest. When the project needed two core systems integrated — one in Java, one in Microsoft .NET — and nobody on the team knew .NET, the client asked if he could do it. He worked mostly in Java. He had touched .NET only briefly, years before. He taught himself, and wrote the entire interface alone.
He spent so much time on site that the client's staff became closer to him than his own colleagues. When the new system went live, he and the team worked nearly around the clock for a month. Some nights it got so late he simply slept at the client's office.
Why? He explains it in one line:
No one wrote that sentence into his contract. He arrived as a code reviewer who wasn't meant to write code. Two years later he was running the client's entire IT function. He wasn't selected to become a CTO. The environment grew him into one.
What the environment produces
This is what the 70/10/20 split is really for. Not to be cheap — cheapness is a side effect. It's there to align incentives, to tie an engineer's livelihood to whether the client's product actually succeeds, and to keep him close enough, for long enough, that the client's business becomes his own.
What that produces is an engineer who stays. Our client relationships don't run for the length of a project; they run for five years, ten years, eighteen years. The engineer who started with a client is still there years later, understanding their business more deeply every year. That is something the agency model — fixed salary, developer rotated off when the project ends — never produces, at any price.
Why I'll happily show you the whole thing
None of this is secret. The 70/10/20 split, the Account Owner model, the profit-share, helping engineers go build branches in their hometowns — we'll explain all of it to anyone who asks. We're playing with our cards face up.
If someone can copy this, and wants to, I'll be glad. My only worry is that it can't be learned by copying. What you can copy is the mechanism. What you can't copy is the environment that keeps turning ordinary people into owners — because that takes years to build the trust it runs on, and it only works if you genuinely treat human development as the starting point, not as a slogan you put on a wall.
The world needs more companies like this: ones that take the development of their people as their mission. That, in the end, is the deepest moat we have. Not the 70. Not the split. The environment behind them.