AI Engineer World's Fair 2025
Small AI Teams with Huge Impact — Vik Paruchuri, Datalab
Read the talk
Growing an AI Company Without Growing the Org Chart
Datalab’s experience connects small-team productivity to preserved customer context, simple architecture, broad ownership and a hiring process built around doing real work.
From a talk by Vikas Paruchuri
How much can three people build?
How can a team train models, maintain open-source repositories and build a business without immediately hiring separate teams for each? Vikas Paruchuri opens with Datalab’s results: he reports 40K GitHub stars, seven-figure annual recurring revenue and models he describes as state of the art, achieved with three people. Over the preceding year, he had trained models and built repositories around Marker and Surya, left his AI research job, founded Datalab and raised a seed round.
Those results describe an earlier team size. At the recording, Datalab had four people, and Paruchuri reported fivefold revenue growth since January, when the company made its first hire. The newest colleague, Faraz, was not yet in the team photograph. Customers included major AI labs, universities, Fortune 500 companies and AI startups. Gamma was both a customer and the tool he used to make the presentation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When fewer people meant more productive work
Headcount does not equal productivity. Raising money, hiring people and building more can look like a natural sequence, but Paruchuri’s previous company made him question the connection. Dataquest, a bootstrapped online education business, reached 30 people and $4 million ARR during COVID. When online education contracted afterward, it went through layoffs from 30 to 15 people, then from 15 to seven. He acknowledges how awful those reductions were for the people affected.
Paruchuri reports that productivity and happiness increased a couple of months after each layoff, eventually exceeding their levels before the reductions. The observation prompted a question: what had the larger organization been spending its capacity on?
He offers four explanations from that experience:
- Specialization: people hired into narrow functions could not readily move to the company’s most pressing problems.
- Synchronization: a remote organization required deliberate process and frequent coordination to keep people aligned.
- Meetings: middle management added more scheduled coordination, leaving less time to make things.
- Senior attention: experienced people spent substantial time managing less experienced colleagues instead of directly solving problems.
In one example, he says a team became more productive after shrinking from three people to one because the remaining senior person could concentrate on the work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keeping the early company’s alignment
An early company often has a period when everyone understands the product, the business model and the work that matters. Paruchuri points to Google Search and Microsoft Windows as examples of defining products around which companies formed. Expansion then fills out the surrounding functions: enterprise sales, marketing and engineering roles with increasingly narrow scopes. His deliberately extreme illustration is a friend at Amazon who, he says, spent two years working on a shopping-cart button. The concern is the accumulated bureaucracy, synchronization and uncertainty about priorities. Could the initial period of shared context last longer?
Working with Jeremy Howard at Answer.AI gave him a possible organizational design: fewer than 15 generalists who understand the stack and the company, with AI and internal tools covering the surrounding work. He connects Howard’s investment in FastHTML and MonsterUI to this approach: reusable building blocks make it easier for a small group to build the other tools it needs. The infrastructure should stay equally straightforward; a three-person company need not start with a Kubernetes cluster.
That design sets a demanding cultural requirement. Engineers must talk to customers, and go-to-market people must build. People need both the ability and the desire to understand work outside their primary specialty. High trust makes that overlap workable: colleagues are building something together, rather than protecting territory or optimizing for personal advancement. Shared customer focus supplies the basis for deciding what to do next.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Surya OCR 3: carrying customer context through training
The concrete technical example is Surya OCR 3, which had shipped but had not yet been announced at the time of the talk. Paruchuri describes a 500-million-parameter model supporting 90 languages, with 99% accuracy on Datalab’s challenging internal benchmarks, including math. The talk does not specify the accuracy calculation or dataset composition; these are historical internal results, and the current repository describes a later model and different evaluations.
The model produced character-level bounding boxes—a capability Paruchuri described as distinctive—and used PDF text as grounding at the line level. Delivering it required him and research engineer Tarun to own the development process from beginning to end:
- Talk to customers and identify what they needed.
- Read papers, select an architecture and prototype it.
- Build the data pipeline library and datasets, clean the data and train the model.
- Write inference code, connect it to the repositories and integrate it into customer-facing products.
His joke about training captures where much of the effort went: you hope the work will be mostly architecture, but it becomes mostly data cleaning.
Paruchuri estimates that a larger company might divide this scope among four teams. Each handoff creates a translation problem: the people who heard the customer explain the need communicate it imperfectly to the builders, who communicate it imperfectly to the model trainers. Meetings consume time trying to reconstruct that context without fully recovering it. A customer conversation can consequently take months to influence training.
End-to-end ownership keeps the reason for a change attached to the work. The same people can connect customer needs to model decisions and product behavior, shortening the feedback cycle. AI helped make that breadth manageable by assisting with lower-level tasks, such as building the pipeline library and working out API integration. Paruchuri and Tarun retained the higher-level decisions across those areas. The organizational gain came from combining broad human ownership with assistance on implementation work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Maturity means choosing the small solution
Operationally, this starts with hiring senior generalists. Paruchuri uses seniority to mean maturity rather than years of experience: someone takes responsibility for figuring out a problem and cares enough to keep iterating with the customer. That includes resisting an engineer’s attraction to elaborate infrastructure. For a data-extraction problem, a Kubernetes cluster and multistage pipeline may be unnecessary when a shell script on one machine will do.
For example, a batch that only needs text from digital PDFs can begin with a shell loop around pdftotext, with that utility installed:
bash
#!/usr/bin/env bash
set -euo pipefail
mkdir -p text
for pdf in documents/*.pdf; do
[[ -f "$pdf" ]] || continue
name="${pdf##*/}"
pdftotext -layout "$pdf" "text/${name%.pdf}.txt"
done
This illustrates the one-machine approach, not Datalab’s OCR implementation: it extracts existing PDF text and does not recognize text in scanned page images. The useful starting question is whether the actual task requires distributed infrastructure.
Paruchuri recalls a Hadoop-versus-shell-script article in which a single 64-core machine could replace a cluster. The exact article and hardware detail are uncertain; the principle he draws from the recollection is to value simple solutions. He also favors working in person for a small team that needs to move quickly. He acknowledges remote work’s benefits, but in his experience the additional process needed to coordinate it slows continuous collaboration and tight feedback loops.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A small technical surface area
Datalab applies the same principle to its architecture. It reuses components between on-premises and API deployments instead of maintaining separate implementations of the same capabilities. Its frontend uses server-rendered HTML with light HTMX and Alpine, rather than React or an elaborate frontend framework. Paruchuri also says the team rearchitected marker into modular, well-documented code, making it easier for AI to contribute useful changes.
| Area | Practice | Intended effect |
|---|---|---|
| Code | Readable, maintainable modules | Easier changes |
| Architecture | Few moving pieces | Less surface area to manage |
| Process | High trust and continuous discussion | Less bureaucracy |
These choices reinforce one another. A small organization still has to maintain everything it creates, so complexity consumes the same scarce attention needed for customers and product work. Paruchuri extends the constraint to hiring: someone who needs extensive management may not fit this operating model.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Can a model absorb customer-specific work?
Document intelligence introduces an obvious pressure to hire: every customer wants documents parsed slightly differently. Earlier OCR companies often addressed this by placing forward-deployed engineers at client sites, where they could repeatedly adjust the system until its output was acceptable. Paruchuri proposes a different route: train a model to loop over customer outputs until they reach the desired state. In that proposal, the model would absorb work otherwise assigned to a customer-specific engineering function. He presents this as a future direction, not an already demonstrated replacement.
The limits remain open. Paruchuri points to Gamma as another small team with meaningful ARR growth, then shifts the question from what a company can accept to what it can decline. Hiring engineers to work at every client site is a choice; so is solving the problem another way. The alternative might capture revenue less efficiently in the near term while better supporting the company’s long-term health. He explicitly does not know whether this organizational model can work forever. Preserving it requires deliberate choices about which complexity to take on.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Broad roles, patient hiring and more resources per person
Datalab organizes around three overlapping roles: research engineer, full-stack engineer and go-to-market. Paruchuri jokes that the awkward Venn diagram reflects an LLM’s difficulty drawing it, but the intended overlap is practical. Everyone talks to customers and builds product in some form. Research and full-stack engineering share substantial responsibilities, while go-to-market combines sales, marketing and support in a generalist role.
The overlap depends on low ego. People need enough confidence to advocate for ideas without fighting for them at the expense of colleagues, customers or the company. Datalab pays top-of-market salaries; Paruchuri questions the practice of raising $20 million and then paying $150K–$200K salaries rather than hiring fewer people at higher compensation. Broad scope is another part of the offer: people can work across the stack and ship complete things. That attracts some candidates and causes others to opt out. Screening therefore looks for both low ego and the habit of shipping, rather than merely talking about it.
Paruchuri finds that distinction harder to assess remotely. More generally, his worst hiring decisions came when he felt compelled to fill a role quickly, while his best came from finding a strong generalist even without an immediate opening. He compares it to the NBA and NFL drafting debate: choose the best available player or draft for a specific fit. In his experience, patience produces better hires than urgency.
Growth can then mean increasing what each person can accomplish:
- Compensation: raise salary bands as the company grows, bringing more experienced people into the same roles.
- Compute: give researchers more capacity to run their work. Paruchuri contrasts access to eight GPUs with access to 64 as an example of greater resources per researcher, without reporting a measured productivity multiplier.
- AI tools: pay for tools that handle peripheral work and expand what the team can deliver.
He closes the prepared talk by inviting people who want to work this way to contact him through the social accounts shown on his slide.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What changed besides headcount?
The first audience question adds an essential qualification to the Dataquest story: did the smaller team keep the same responsibilities? Paruchuri says the high-level product remained the same, but the company removed less relevant features and accumulated peripheral work. The productivity account therefore includes a reduction in scope, not just fewer people doing an unchanged set of tasks. He argues that excess capacity can encourage organizations to invent work, whereas a tiny team has to prioritize ruthlessly.
Another question asks how he would change a century-old company with hundreds of thousands of employees, comfortable revenue, bureaucracy and entrenched egos. Paruchuri says he has not led that kind of transformation. His suggestion is for people who want a different culture to start a small competitor and build the product better. Drawing on his experience at the State Department, Pepsi and UPS, he is skeptical about changing a culture once it has become deeply entrenched.
The audience pushes back: incumbents can buy those startups and crush them. He acknowledges that this sometimes happens and offers Google as a counterexample. This exchange leaves a boundary around his advice: it comes from building small organizations, rather than from a tested method for transforming a large one.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Finding generalists and working together before hiring
Where do these generalists come from? Speaking publicly is one channel—the talk itself is an example. Open source and Twitter have also brought strong candidates to Datalab. Paruchuri jokes that he refuses to call Twitter X, then describes the more useful mechanism: publish good work and explain how it is built, and people who care about the mission and working style can find you. He presents that as his experience, not a complete sourcing formula.
The interview process tests collaboration through progressively more concrete work:
- Have a short peer conversation. Discuss a real challenge and see whether the candidate and team can reason through it together.
- Choose and build a paid project. Paruchuri says the project usually takes about 10 hours and pays $1,000. The team then reviews the work.
- Spend time with the team. If the project goes well, assess how everyone interacts as people. A good fit leads to a hire.
The project makes the ability to build together observable before either side commits to an ongoing working relationship.
Asked about the success rate, Paruchuri explains that candidates enter this process only when the team already has high confidence in them, to avoid wasting anyone’s time. He estimates that Datalab hired approximately 40% of the people it interviewed. That denominator is interviewed candidates, not all applicants: the evaluation process begins with substantial prior confidence and uses shared work to test it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Datalab's OCR and document-analysis toolkit, with installation instructions and examples. The current README describes a later model and inference interface.
Document conversion toolkit with configurable converters and structured Markdown, HTML and JSON outputs.
Python web framework that expresses HTML and HTTP directly and uses HTMX for interactive page updates.
Tailwind-powered UI components for building FastHTML interfaces with minimal code.
Further reading
Adam Drake's worked example of counting chess-game outcomes with shell pipelines, including timing assumptions and comparison with a Hadoop implementation.
Read the complete timestamped transcript
- 0:00
[upbeat music] Okay, um, my name is Vikas.
- 0:16
I'm the CEO of Datalab, and today I'm gonna talk about how we got to 40K GitHub stars, seven-figure ARR, and train state-of-the-art models with a team of three.
- 0:26
So I spent the last year training these models, like Brittany mentioned, Marker and Surya. I also built repositories around them. I left my AI research job, and I started a company and raised a seed round.
- 0:37
Uh, I did not get enough sleep. It's, uh, important.
- 0:42
And this is Datalab. So we made our first hire in January. We're now a team of four. Faraz is new enough that he's not pictured. Um, we've grown revenue 5X since January.
- 0:50
We're at seven-figure ARR, and our customers include tier-one AI labs, universities, Fortune 500, and AI startups.
- 0:59
Including Gamma, who I used to make this presentation. Um, so today's focus, I'm gonna talk about how we've grown with a small team. I'm gonna talk about my philosophy on building teams and why I think we're at kind of an inflection point in how we think about building teams.
- 1:13
And I'm really gonna talk about this idea that headcount does not equal productivity. There's, like, this really persistent notion in Silicon Valley that you raise money, you hire a bunch of people, and you build more.
- 1:22
But it almost never, in my, in my opinion, works out perfectly that way. All right. So my last company was called Dataquest. I'm very fond of the data prefix, apparently.
- 1:32
Uh, and we scaled to thirty people and four million ARR bootstrapped during COVID. It was an online education startup. Um, and then, unfortunately, we had to do two rounds of layoffs post-COVID, when online education kinda tanked.
- 1:44
We went from thirty to fifteen, and then again from fifteen to seven. And it was obviously awful for the people we had to lay off, but I noticed something really interesting.
- 1:52
Productivity and happiness increased a couple of months after both layoffs, to the point where we were actually much more productive after both cycles than we were at the beginning.
- 2:01
And I started to wonder why that was. Like, how could reducing the team so much actually improve productivity? And I came up with these four hypotheses. One, we'd hired a lot of specialists.
- 2:12
So as you scale, like Grant mentioned in the earlier talk, you end up building these very specialized functions and teams, and those specialists often can't flex across the company to solve the key issues of the company.
- 2:24
Two, we were a remote team, which required a lot of intentional process and heavy syncing, which just eats into your time and just, just makes it really hard to get on the same page.
- 2:34
Um, because of that, we had a lot of meeting overload, and especially once we got m- middle management in place, people whose job is kind of professionally to manage, we ended up with just a lot of meetings on people's calendars and not enough time to actually work.
- 2:46
And then senior people, we hired kind of a mix of experience, like most companies do. We hired junior, mid-level, senior. And then senior people ended to get up getting kind of tied down in doing a lot of work, uh, to manage the more junior people.
- 2:59
Uh, we actually had a case where we had a three-person team, and we cut it down to one, and the team actually got much more productive because it freed up the senior person's time.
- 3:08
Um, and kind of every company, I feel like, goes through this journey. There's this initial golden period when everyone is aligned, you're on the same page, you're building this amazing stuff, and that's really when you build the core thing of your company.
- 3:21
Um, like Google, uh, with Search, or Microsoft with Windows. It's kind of when you figure out your business model. And then you hire a bunch to fill out the edges around it.
- 3:29
Like, you hire a bunch of enterprise sales, you hire a bunch of marketing, you hire a bunch of engineers who are kind of in very small boxes to build very small features.
- 3:37
Uh, I had a friend at Amazon who's worked there for two years and built a shopping cart button. Um, it's, it's fine, right? But I mean, at, at that scale of org, that's kind of the tiny box you get fit in.
- 3:47
Uh, and you end up with a lot of bureaucracy, a lot of syncs, a lot of unclear priorities, um, and this pattern is unfortunately very common. But I started to think, what if that golden period just lasted forever?
- 3:57
Why, why do you actually need to end it?
- 4:00
And as I started working with Jeremy Howard at AnswerAI, I got to understand his philosophy for building a company a little bit better. And his idea is basically hire less than fifteen generalists, so people who can really do everything across the stack and really understand all aspects of the company.
- 4:17
Fill in the edges with AI and internal tooling. So, uh, Jeremy's invested a lot recently in FastHTML and things like Monster UI because he sees them as kind of building block libraries to really build out the other tools that the company's working on.
- 4:29
Uh, and then use simple, boring tech, right? Like, you don't need to get too fancy. You don't need a Kubernetes cluster when you're a three-person company.
- 4:38
Um, but this unfortunately requires, uh, kind of a high cultural bar for folks. Um, you need people who really want to and can understand everything you're doing. So you need engineers who talk to customers.
- 4:49
You need go-to-market people who actually build. Uh, and that's, that's not necessarily easy to find. You need high trust. So, um, basically, you need people who are in it because they're building something together, uh, and not in it for other reasons, like politics or personal advancement, et cetera.
- 5:05
And everyone needs to s- really care about the customers and focus on them. Um, I think these are the prerequisites for this kind of team working, this less than fifteen-person team of generalists.
- 5:16
I'll, I'll give you a quick example. So we recently trained a model, uh, Surya OCR 3. Uh, it-- we recently shipped it but have not announced it yet. So it's five hundred million parameters.
- 5:24
It supports ninety languages and ninety-nine percent accuracy on our challenging internal benchmarks that include math. Um, and it also does some features that no other model does, like character-level bounding boxes.
- 5:35
It uses PDF text as grounding at a line level. Um, so it was a very challenging model to train. And in order to do it, Tarun, who's a research engineer at Datalab, and I had to handle the entire process from end to end.
- 5:47
So that included talking to customers, figuring out what they wanted. Uh, it included reading a bunch of papers and figuring out the right architecture, prototyping, doing the model training itself, which you always hope is ninety percent architecture, but is always ninety percent data cleaning.
- 6:00
So building a data pipeline library, building out the datasets. Then we had to write the inference code. So we had to connect it to our repos, get the inference written for all our customers, and then integrate it into our products.
- 6:11
So this is a scope that in a big company, you'd probably have four 10. You'd have a lot of teams doing this. And every time you hand off between teams in a traditional company, you lose context, right?
- 6:22
The people who talk to the customers lossily communicate it to the people who build, who lossily communicate it to the people who train the model. Um, it just gets-- it becomes very inefficient.
- 6:32
You end up eating a lot of time in just syncing context. It never gets fully synced. You're not able to build a great end-to-end experience as a result, and you have very slow feedback loops, right?
- 6:41
Like, you talk to a customer today, and it might impact your model training in months. Um, whereas if you have generalists who can work across the stack, you get seamless context, right?
- 6:49
You never need to share context and do inefficient syncing. You get a really tight integration between all aspects of the company and very, very fast feedback cycles. Um, and the reason we were able to do this is we used AI to, to take kind of the easy low leverage pieces of this, um, like building a data pipeline
- 7:05
library or helping us really figure out how to integrate it into the API, whereas we did the higher level work in each of these silos.
- 7:13
So I-- if you get one thing from this talk, this is the thing. More people does not equal more productivity. Um, [lip smack] all right. And, uh, like, how do you make this work?
- 7:22
Like, how do you operationalize this? So the first thing you have to do is hire senior generalists. And senior to me does not mean years of experience. It really means maturity.
- 7:31
You need people who can look at a problem and say, "I'm gonna figure out how to solve this. Uh, I'm gonna do what it takes, and I really care enough to iterate with the customer to solve it."
- 7:39
Um, you need to avoid overcomplication, right? Like, I'm an engineer, a lot of us are engineers. We love overcomplicating things. Like, "Hey, let me deploy this Kubernetes cluster and multistage pipeline to solve, like, a data extraction problem."
- 7:51
Um, but in reality, you need people who can go back and, like, kind of set aside the sh- fixation on shiny tech and just do the simplest possible thing, which usually is, "I'm just gonna write a shell script to run this on one machine."
- 8:01
There's that famous, like, Hadoop versus shell script blog post, uh, from a few years ago when you, like, you could replace a whole Hadoop cluster with just, like, a sixty-four core machine.
- 8:10
Uh, you need people who, who appreciate that ethos. Um, and you need to work in person, I personally think. Um, remote is great for a lot of reasons, but it's not great for a small team that needs to move fast, um, because you need to set up a lot of process.
- 8:22
And process, to me, is kind of the death of this really fast collaboration and tight feedback loop.
- 8:29
And then how do you do it architecturally? So, um, I, I alluded to this a little bit, but you have to reuse components aggressively. So we reuse a lot of components between our on-prem and our API deployments.
- 8:39
We keep our technology super simple. Like, we don't use React. We don't use any fancy front-end frameworks. It's all server-rendered HTML with, like, Lite, HTMX, and Alpine. And then super clean modular code that AI can really add to very well.
- 8:52
Like, we rearchitected our marker repo to be extremely modular and easy to, to work with and well-documented, and that makes it much easier to use AI to actually add to it.
- 9:03
All right. So basically, keep everything simple. Code is clean, readable, maintainable. Architecture, as few moving pieces as possible. Um, minimize your surface area. And then process, minimize bureaucracy, high trust, continuous discussions.
- 9:16
Um, if, if you feel like someone's gonna need a lot of management, like, don't hire them. Like, you need people who can, who can move fast without being managed.
- 9:25
Um, all right. And then how do you fill in the edges with models? So a, a challenge we're gonna face as we scale is this idea that we're, we're a document processing, document intelligence company, and every customer has a slightly different way that they wanna parse their docs.
- 9:38
And if you go back kind of to the last generation of OCR companies, the way they solved this is they hired a bunch of forward-deployed engineers. You sat at a client site, and you just kinda iterated with them until it was good enough.
- 9:49
But in the future, you can really train a model to handle this complexity, right? Like, we can train a model to essentially loop over customer outputs until it gets to the, the right state.
- 9:58
So you can kinda replace that entire forward-deployed engineering side of the org. Um, and then when does this model fail? Like, we're early, right? I don't know exactly when this model falls apart.
- 10:09
Um, but Gamma, as, as we just saw, is a great example of a small team with, with very, very meaningful growth in ARR. I think the key is being able to say no, right?
- 10:18
A lot of these edges are choices, right? You can choose to go hire a bunch of forward-deployed engineers and put them at your client sites, or you can choose to solve it a different way.
- 10:26
And maybe that different way is slightly less efficient in terms of revenue, um, but it might be more efficient in terms of your long-term company trajectory and health. Um, so it's really unknown if this will work forever, but in my opinion, like, it's your choice, right?
- 10:39
Like, you can choose to make this model work, or you can choose to, to do the less efficient, let's scale to hundreds of people model.
- 10:47
Um, all right. So LLMs are surprisingly bad at generating Venn diagrams, so that explains why this slide is, [chuckles] is, is not so well done. Um, but basically, we have three core roles, and the, the responsibilities overlap a lot.
- 11:00
So everybody talks to customers, um, everybody builds product in some way, and research engineer and full stack engineer overlap quite a bit. Um, and then go-to-market is really, like, your traditional kinda sales, marketing, support functions all collapsed into kind of like a more generalist role.
- 11:15
Um, and really, like, I feel like politics are the death of small teams, right? Like, we want people who only care about the work, the people around them, and customers, right?
- 11:25
Like, m- minimal ego. You need some ego to, to kind of advance your own ideas, but not so much that you're willing to fight for them at the detriment of, of kind of the health of the company.
- 11:35
Um, we pay top-of-market salary, right? Like, it's always weird to me that startups pay a hundred fifty or two hundred K when they've raised twenty million, right? Like, you should be able to hire fewer people with higher salaries and get more done, in my-- at least that, that's what I've seen.
- 11:49
Um, meaningful work. So big challenges in scope, right? Like, if you come in, you get to work across the stack, you get to ship things end to end, uh, and that's very exciting for some people.
- 11:58
It's, it's not exciting to other people, and they kind of self-select. And then you really need a good way to screen for low ego and GSD, right? Like, you need people who will ship, not talk about shipping.
- 12:08
Um, and that's another downside of remote culture, in my opinion. It's very-- It gets very hard to tell the two apart. Um, and then patience, right? Like, the worst hires I've personally made have all been when I thought I had to fill a role very quickly.
- 12:20
All of my best hires have been when I said, "Okay, let me find the best person and, and hire them. Even though I may not necessarily have a role today, they're a great generalist."
- 12:30
Um, this is actually a, a, a big debate in NBA and NFL drafting too, like best player available versus Drafting for fit. Um, all right. So really, I think the thing to think about as you scale is, like, how do we scale productivity, not head count?
- 12:43
And you can do that in a few ways, right? Like, you can raise salary bands as the company grows, so you hire more and more experienced people into the same role.
- 12:51
Um, you can invest more in compute, right? Like, a one researcher with access to eight GPUs is less productive than one with access to 64 GPUs. You can invest in AI tools that multiply productivity, right?
- 13:00
There's so many tools out there now, um, that are worth paying for that can abstract away a lot of these edges for you.
- 13:08
And finally, uh, I'd be remiss if I didn't say, if this culture sounds interesting to you, drop me a line. Those are all my socials. Um, we'd love to chat.
- 13:17
All right. Yes. Uh, I think we do the microphone for questions, right?
- 13:26
So, um, when you went from 30 to 15 and then to seven ... I mean, my takeaway from this whole talk is, like, the, the human touch points are really what slow things down, right?
- 13:35
Um, was there any, uh, additional po- um, focus on reducing the domains that you were focusing on, or, like, your capability sets, or it was, like, basically your same product offering just with less folks focused on it?
- 13:50
Yeah, that's a really good question. So at, at a very high level we offered the same product, but we cut some features that were less relevant. Like, we'd, we'd built up a lot of those, those edges that you kind of, like, end up building over, over the years.
- 14:01
Uh, and we ended up slicing a lot of those edges. So I think, I think what happens when you hire a lot of people is you don't have enough work, and you start making work for people, right?
- 14:09
And they end up building all of these edges that actually aren't that useful to the customer. But when you have a tiny team, there's so much work that you actually have to ruthlessly prioritize.
- 14:17
And I think you always wanna be in that zone, and that's kinda where we ended up back.
- 14:27
Oh, sorry.
- 14:28
Oh, sorry.
- 14:28
No worries. So, uh, it's a hypothetical question for you. So we take you and drop you in the middle of a giant company that's been around for 100 years, hundreds of thousands of employees, lots of bureaucracy, lots of ego.
- 14:44
S- got super comfortable with a revenue stream, um, and they're clearly folding over on themselves with too many people. How do you change that culture?
- 14:54
Yeah, I'm not the right person for that. [laughs] I've never done that before. Um, I, I would say, I would say you ... the people who want to change the culture, go start a small company and build the same thing, just build it better.
- 15:05
That, that's a common pattern, right? Like, that's a common disruption and growth cycle. Um, I think that's the best way to do it. Like, it's, it's just bec- once a culture gets ossified ...
- 15:13
Like, I've worked at the State Department, Pepsi, UPS. Like, once a culture gets ossified enough, like, you're not gonna change it. Like, it just, it just is what it is.
- 15:19
I mean, generally with that pattern what happens is these companies recognize that they're a target, and they start to buy up those small startups and crush them.
- 15:27
Yeah. Um, sometimes that happens. But, like, I mean, Google is a great example of where that didn't happen, right?
- 15:31
Right. Right. So you haven't talked about how you source these, these, uh, really good generalists. Have you?
- 15:40
Yeah. That's, that's a great question. Well, one way is, is this. [laughs]
- 15:43
Okay.
- 15:44
Uh, another way is, uh, is just open source and Twitter are great ways, uh, to hire. Like, uh, a lot of, a lot of the best candidates have actually come from Twitter, which is weird.
- 15:53
Uh, I refuse to call it X. It's still Twitter. Um, but yeah. Uh, I, I don't ha- I don't have a great answer to that, but I think if you do good work and you put it out in public and you talk about how you're building, like, that seems to attract people who really care about this mission
- 16:06
and wanna build in the same way. At least that's been my experience.
- 16:09
Thank you.
- 16:12
Yeah.
- 16:13
Uh, well, uh, actually it's related. Uh, so h- how do you structure your interview process and recruitment? Like, uh, how, how does it look like? Uh, you maybe do a trial period or ...
- 16:24
Yeah, that's a great question. So, uh, th- three steps. So step one is people come in, we do a short chat. It's really like talking to a peer. Like, uh, "Here's a challenge I'm having.
- 16:34
Let me talk it through with you and see if we can solve it together." If that goes well, step two is let's think of a project we can build together.
- 16:40
So we do a paid project. It's usually around 10 hours. We pay $1,000. It's like, it sounds like a lot, but it's actually a tiny amount of money to, to figure out if someone's a fit or not.
- 16:49
Um, and then we review the project, and if it's good, we come in and just do a culture fit. Like, how does it feel if we're all just interacting as humans and people, and, and does it ...
- 16:57
If it feels like a good fit, like, it's a hire.
- 16:59
Yeah. So, and what is your, like, success rate there? Like, maybe 10% of the people that goes through a pro- through that process, uh, gets selected or?
- 17:07
Oh, that's, that's an interesting question. Like, usually we don't ... Once we kind of get someone to the beginning of the process, we have high confidence they'll be good.
- 17:15
Okay.
- 17:15
Like, we don't wanna waste anyone's time. Um, but we probably, of the people we've interviewed, I think 40%-
- 17:21
Oh
- 17:21
... have, we've ended up hiring. Yeah.
- 17:22
Nice. Thank you.
- 17:26
All right. I'm out of time. Thank you, folks. This was great. [upbeat music]