Why OZ Hires for Leverage, Not Headcount
A Talented Engineer at a Crossroads#
Imagine you are an engineer with deep expertise in computer vision, or embedded systems, or spatial computing. You have spent years building skills that are in extraordinary demand. Every major technology company wants you. The offers are generous. The roles are stable. The career paths are mapped out in five-year increments.
And then you encounter a company like OZ. A small team. Building sealed hardware that survives outdoor deployment across seasons. Running AI on-site under real-time constraints. Building a purpose-built database for physical space. Operating managed infrastructure across venues with published performance guarantees and financial penalties if they miss. All of it integrated into a single vertical stack. All of it live, in production, with zero tolerance for failure.
The pitch is not comfort. The pitch is that you will own a capability area (not a task, not a feature, not a component of a larger system) but an entire domain. You will see your work deployed to physical venues, operating under real-world physics, producing results that thousands of people consume in real time. You will work across the full stack, from hardware constraints to API contracts. And the work you do will compound, because every venue deployment makes the system smarter, every model update benefits from every previous deployment, and every operational improvement feeds back into the platform.
That is a fundamentally different proposition than a well-defined role in a large organization. It appeals to a specific kind of person. And finding, attracting, and retaining that kind of person is what my work at OZ is about.
The Big Tech Trap#
The problem is not that Big Tech is a bad place to work. It is often an excellent place to work, well-resourced, well-managed, with brilliant colleagues and meaningful technical challenges. The problem is structural. In a large organization, the scope of any individual's contribution is necessarily bounded by the organization's architecture.
An engineer at a major cloud provider might work on object detection. Specifically, on one variant of one detection model used in one component of a larger pipeline. They will optimize that model. They will publish papers about it. They will earn promotions based on the impact of that model within the organization's metrics. But they will never touch the hardware it runs on. They will never deploy it to a physical venue. They will never debug an overheating issue that causes their model to miss performance deadlines during a live broadcast. They will never see the full consequence, positive or negative, of their work.
This is not a criticism. It is a description of how scale works. Large organizations scale by decomposing problems into manageable pieces and assigning those pieces to specialized teams. It is effective. It is also, for a certain kind of engineer, deeply unsatisfying.
The engineers who thrive at OZ are the ones who find that decomposition suffocating. They want to see the whole system. They want to understand why a hardware cooling decision affects their AI model's speed. They want to debug a production issue at 2 AM and understand every layer of the stack between the camera sensor and the final data output. They want ownership, not specialization.
Hiring for Leverage, Not Headcount#
My role is to build the organizational model that attracts these people and then gives them the environment to produce their best work. The principle is simple: we hire for leverage, not headcount.
Every person we add to OZ should multiply what the team can do, not just add to it. If a new hire makes the existing team 20% more effective, that is a better outcome than adding another person who contributes linearly. Leverage is the only hiring metric that matters in an AI-native organization.
What does hiring for leverage mean in practice? It means we do not write job descriptions that list forty requirements and twelve "nice-to-haves." We define a capability area, a domain that the company needs to own, and we look for the person who can own it entirely. Not manage it. Not contribute to it. Own it.
When we hired Suresh for the AI runtime, we did not look for "a senior engineer with experience in AI optimization." We looked for someone who could build and own the entire AI execution engine: architecture, implementation, optimization, deployment, monitoring, and iteration. Someone who would wake up at 2 AM when the system missed a performance deadline and have the knowledge to diagnose the issue across the full stack, from hardware scheduling to overheating to AI model optimization trade-offs.
That kind of person does not appear on job boards. They are not looking for a job. They are looking for a problem worthy of their capability. Our recruiting process is designed to present the problem first and the company second. The problem is the pitch. If the problem does not excite them, the company never will.
Ownership From Day One#
The organizational model that supports this kind of talent has four elements.
First, extreme ownership from day one. There is no onboarding period where new team members shadow existing staff and learn the ropes. There are ropes, but you grab them immediately. When Bhagyashree joined to lead edge perception, she was making architectural decisions within her first week. Not because we are reckless, but because we hire people whose judgment we trust from the moment they arrive. If we did not trust their judgment, we would not have hired them.
Second, cross-domain exposure. Every team member at OZ understands the full stack. Rushikesh, who leads hardware, understands the AI pipeline well enough to discuss heat budgets with Suresh in precise terms. Suresh, who built the spatial database, understands the AI model outputs well enough to design queries that work seamlessly with Bhagyashree's detection system. This cross-domain fluency is not accidental. It is the product of a flat organizational structure where information flows directly, without intermediary layers of management.
Jagruti Patil
Head of People Operations
“We don't hire for headcount. We hire for leverage. Every person we add should multiply what the team can do, not just add to it.”
Third, university thesis collaborations. We partner with university programmes to give exceptional students real-world research problems, not toy datasets, but actual production challenges from our deployment pipeline. The students get access to problems that no academic lab can provide: real-time AI processing under physical constraints, spatial queries over live data, stitching together multiple camera views at specific venues. We get early access to talented researchers who have already proven they can contribute to our specific domain. Several of our strongest technical contributors entered through this pathway.
Fourth, hackathons. We host hackathons in our key cities, intensive events where talented engineers work on real OZ challenges over a compressed timeframe. The energy at these events is remarkable. You see people solve problems in forty-eight hours that would take weeks in a normal setting, because the format strips away everything except the work. Some of our strongest team members joined OZ after we met them at a hackathon. Our most recent one was in Nagpur, India, and the talent that came through the door reminded us why we keep running them. A hackathon reveals qualities that a resume cannot: how someone thinks under pressure, how they collaborate with strangers, and whether they create energy or consume it.
Fifth, AI-amplified workflows. Every person at OZ is equipped with AI tools that amplify their individual output. Not as a novelty. As a core operational principle. Our engineers use AI for code generation, documentation, analysis, and debugging. Our operations team uses AI-driven diagnostics and automated playbook execution. The expectation is not that people work harder. It is that AI handles the systematic work, freeing people to focus on the judgment-intensive work that only humans can do.
Choose Leverage Over Comfort#
The engineer I mentioned at the beginning, the one choosing between Big Tech stability and OZ's ownership model, ultimately joined OZ. His reasoning, which I have heard echoed by every team member, was this: "I can be excellent at one thing in a large organization, or I can be essential to an entire system in a small one. Essential is more interesting."
That is the action we ask of every candidate: choose leverage over comfort. Choose a problem that demands your full capability over a role that uses a fraction of it. Choose to see the full consequence of your work (in hardware deployed on gantries, in models running under rain, in spatial queries that return answers almost instantly) over the abstract satisfaction of contributing to a metric in a quarterly review.
This is not for everyone. It should not be for everyone. The engineers who thrive in large organizations are doing vital work, and the world needs them there. But the engineers who feel constrained by organizational boundaries, who want to understand the full stack, who want to own a domain rather than occupy a role, those are the people OZ is built for.
Scaling Culture, Not Just Headcount#
The trap that every growing company falls into is hiring ahead of need. You raise funding, you feel pressure to grow, you add headcount because headcount feels like progress. And with every hire, the culture dilutes. The cross-domain fluency degrades. The ownership model fragments into specialization. The small team that operated with extraordinary leverage becomes a bloated organization that operates with ordinary efficiency.
The conventional model says more venues means more people. OZ's model says more venues means more operational leverage, because the playbooks compound, the models improve, and the platform handles more of the systematic work. The team grows with the deployment footprint, not ahead of it.
We guard against this by tying hiring to deployment leverage, not to revenue milestones. We do not ask "how many people do we need?" We ask "what capability area is the bottleneck, and can we solve it with AI amplification before we solve it with a hire?" Often, the answer is yes. A better playbook, a better model, a better automated diagnostic can unlock the same capacity as an additional team member, without the cultural dilution.
When we do hire, the bar is not "can this person do the job?" The bar is "will this person multiply the team's output?" Multiplication, not addition. That is the standard. And it is a standard that every existing team member holds, because they were hired against the same bar.
AI-Native Operations at Scale#
The outcome of this approach is a small team that produces output conventionally associated with organizations many times its size. Not through heroic effort. Heroism doesn't scale and it burns people out. Through systematic leverage.
Each person owns a domain. Each domain is amplified by AI tools. Each deployment compounds the operational playbooks that make subsequent deployments faster. Each model update benefits from the accumulated data of every previous deployment. The team does not grow linearly with the number of venues. It grows with the complexity frontier, adding people only when a genuinely new capability area emerges that AI amplification cannot address.
This is what an AI-native organization looks like. Not a traditional organization that uses AI tools. An organization designed from the ground up around the assumption that intelligent systems handle the systematic work and humans handle the exceptional. The humans are not replaced. They are elevated: from executing procedures to designing systems, from monitoring dashboards to solving novel problems, from documenting processes to encoding them as executable specifications.
The technology at OZ is extraordinary. The hardware survives every season. The AI models run at production speed. The spatial database answers queries almost instantly. The runtime meets published performance guarantees with financial penalties attached. But none of that technology builds itself. Behind every sealed enclosure, every optimized model, every spatial query, and every operational playbook, there is a person who owns it completely. The technology is what they build. The culture is what lets them build it.
That is the human multiplier. Not more people producing more output. The right people, in the right structure, with the right tools, producing extraordinary output. And every person's work amplified (by AI, by the platform, and by each other) into something far greater than the sum of its parts.