Okay, my name is Vikas. I'm the CEO of Datalab, and today I'm going to talk about how we got to 40k GitHub stars, seven-figure ARR, and trained state-of-the-art models with a team of three. 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. I did not get enough sleep. It's important. 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. We've grown revenue 5x since January.

We're at seven-figure ARR, and our customers include Tier 1 AI labs, universities, Fortune 500, and AI startups, including Gamma, who I used to make this presentation. So today's focus, I'm going to talk about how we've grown with a small team. I'm going to 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.

And I'm really going to 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. But it almost never, 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. And we scaled to 30 people and 4 million ARR bootstrapped during COVID. It was an online education startup. And then, unfortunately, we had to do two rounds of layoffs post-COVID when online education kind of tanked.

We went from 30 to 15, and then again from 15 to 7. And it was obviously awful for the people we had to lay off. But I noticed something really interesting. 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.

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. 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. Two, we were a remote team, which required a lot of intentional process and heavy syncing, which just eats into your time and just makes it really hard to get on the same page.

Because of that, we had a lot of meeting overload. And especially once we got 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. 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 up getting kind of tied down and doing a lot of work to manage the more junior people. 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.

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. Like Google 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. 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.

I had a friend at Amazon who worked there for two years and built a shopping cart button. It's fine, right? But, I mean, at that scale of org, that's kind of the tiny box you get fit in. And you end up with a lot of bureaucracy, a lot of sinks, a lot of unclear priorities.

And this pattern is unfortunately very common. But I started to think, what if that golden period just lasted forever? Why do you actually need to end it? And as I started working with Jeremy Howard at Answer AI, I got to understand his philosophy for building a company a little bit better.

And his idea is basically hire less than 15 generalists. So people who can really do everything across the stack and really understand all aspects of the company, fill in the edges with AI and internal tooling. So Jeremy's invested a lot recently in fast HTML 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.

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. But this unfortunately requires kind of a high cultural bar for folks. You need people who really want to and can understand everything you're doing.

So you need engineers who talk to customers. You need go-to-market people who actually build. And that's not necessarily easy to find. You need high trust. So basically, you need people who are in it because they're building something together and not in it for other reasons like politics or personal advancement, etc.

And everyone needs to really care about the customers and focus on them. I think these are the prerequisites for this kind of team working, this less-than-15-person team of generalists. I'll give you a quick example. So we recently trained a model, Surya OCR3. We recently shipped it but have not announced it yet.

So it's 500 million parameters that supports 90 languages and 99% accuracy on our challenging internal benchmarks that include math. And it also does some features that no other model does, like character-level bounding boxes. It uses PDF text as grounding at a line level. So it was a very challenging model to train.

And in order to do it, Tharun, who's a research engineer at Datalab, and I had to handle the entire process from end to end. So that included talking to customers, figuring out what they wanted. It included reading a bunch of papers and figuring out the right architecture, prototyping, doing the model training itself, which you always hope is 90% architecture, but it's always 90% data cleaning.

So building a data pipeline library, building out the data sets. 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. So this is a scope that in a big company, you'd probably have four, ten, 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? 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. It just gets, it becomes very inefficient. 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? Like you talk to a customer today, and it might impact your model training in months. Whereas if you have generalists who can work across the stack, you get seamless context, right?

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. And the reason we were able to do this is we used AI to take kind of the easy, low-leverage pieces of this, like building a data pipeline 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.

So if you get one thing from this talk, this is the thing. More people does not equal more productivity. All right. And how do you make this work? 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. You need people who can look at a problem and say, I'm going to figure out how to solve this. I'm going to do what it takes. And I really care enough to iterate with the customer to solve it. You need to avoid over-complication, right? Like I'm an engineer.

A lot of us are engineers. We love over-complicating things. Like, hey, let me deploy this Kubernetes cluster and multi-stage pipeline to solve like a data extraction problem. But in reality, you need people who can go back and like kind of set aside the fixation on shiny tech and just do the simplest possible thing, which usually is I'm just going to write a shell script to run this on one machine.

There's that famous like Hadoop versus shell script blog post from a few years ago when you like you could replace a whole Hadoop cluster with just like a 64-core machine. You need people who appreciate that ethos. And you need to work in person, I personally think. Remote is great for a lot of reasons, but it's not great for a small team that needs to move fast because you need to set up a lot of process.

And process, to me, is kind of the death of this really fast collaboration and tight feedback loop. And then how do you do it architecturally? So 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.

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 light, HTMX, and Alpine. And then super clean modular code that AI can really add to very well. Like we re-architected our marker repo to be extremely modular and easy to work with and well-documented.

And that makes it much easier to use AI to actually add to it. All right, so basically, keep everything simple. Code is clean, readable, maintainable. Architecture, as few moving pieces as possible. Minimize your surface area. And then process. Minimize bureaucracy, high trust, continuous discussions. If you feel like someone's going to need a lot of management, like don't hire them.

Like you need people who can move fast without being managed. All right, and then how do you fill in the edges with models? So a challenge we're going to face as we scale is this idea that we're a document processing document intelligence company. And every customer has a slightly different way that they want to parse their docs.

And if you go back kind of to the last generation of OCR companies, the way they solve this is they hired a bunch of forward-deployed engineers. You sat at a client site and you just kind of iterated with them until it was good enough. 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 right state. So you can kind of replace that entire forward-deployed engineering side of the org. And then when does this model fail? Like we're early, right? I don't know exactly when this model falls apart.

But Gamma, as we just saw, is a great example of a small team with very, very meaningful growth in ARR. I think the key is being able to say no, right? 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.

And maybe that different way is slightly less efficient in terms of revenue, but it might be more efficient in terms of your long-term company trajectory and health. So it's really unknown if this will work forever, but in my opinion, it's your choice, right? Like you can choose to make this model work, or you can choose to do the less efficient, let's scale to hundreds of people model.

All right, so LLMs are surprisingly bad at generating Venn diagrams, so that explains why this slide is not so well done. But basically, we have three core roles, and the responsibilities overlap a lot. So everybody talks to customers, everybody builds product in some way, and research engineer and full-stack engineer overlap quite a bit.

And then go-to-market is really like your traditional kind of sales, marketing, support functions all collapsed into kind of like a more generalist role. 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?

Like minimal ego. You need some ego to kind of advance your own ideas, but not so much that you're willing to fight for them at the detriment of kind of the health of the company. We pay top-of-market salary, right? Like it's always weird to me that startups pay 150 or 200K when they've raised 20 million, right?

Like you should be able to hire fewer people with higher salaries and get more done. At least that's what I've seen. 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. And that's very exciting for some people.

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. And that's another downside of remote culture, in my opinion, it gets very hard to tell the two apart.

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. All of my best hires have been when I said, okay, let me find the best person and hire them. Even though I may not necessarily have a role today, they're a great generalist.

This is actually a big debate in NBA and NFL drafting too, like best player available versus drafting for fit. All right, so really, I think the thing to think about as you scale is like, how do we scale productivity, not headcount? 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. 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?

There's so many tools out there now that are worth paying for that can abstract away a lot of these edges for you. And finally, 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. We'd love to chat.

All right. Yes, I think we do the microphone for questions, right? Okay. So when you went from 30 to 15 and then to seven, I mean, my takeaway from this whole talk is like the human touch points are really what slow things down, right? Was there any additional 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?

Yeah, that's a really good question. So at a very high level, we offered the same product, but we cut some features that were less relevant. Like we'd built up a lot of those edges that you kind of like end up building over the years. And we ended up slicing a lot of those edges.

So 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? 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.

And I think you always want to be in that zone. And that's kind of where we ended up back. Oh, sorry. No worries. So 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.

It's got super comfortable with revenue stream. And they're clearly folding over on themselves with too many people. How do you change that culture? Yeah, I'm not the right person for that. I've never done that before. I would say the people who want to change the culture, go start a small company and build the same thing, just build it better.

That's a common pattern, right? That's a common disruption and growth cycle. I think that's the best way to do it. Once a culture gets ossified, I've worked at the State Department, Pepsi, UPS. Once a culture gets ossified enough, you're not going to change it. It just is what it is.

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. Yeah, sometimes that happens. But Google is a great example of where that didn't happen, right? So you haven't talked about how you source these really good generalists.

Yeah, that's a great question. Well, one way is this. Another way is just open source and Twitter are great ways to hire. A lot of best candidates have actually come from Twitter, which is weird. I refuse to call it X. It's still Twitter. But yeah, 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, that seems to attract people who really care about this mission and want to build in the same way.

At least that's been my experience. Thank you. Well, actually, it's related. So how do you structure your interview process and recruitment? How does it look like you maybe do a trial period? Yeah, that's a great question. So three steps. So step one is people come in, we do a short chat.

It's really like talking to a peer. Like, here's a challenge I'm having. 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. So we do a paid project. It's usually around 10 hours.

We pay $1,000. It sounds like a lot, but it's actually a tiny amount of money to figure out if someone's a fit or not. 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 if it feels like a good fit, like, it's a hire.

Yeah, and what is your success rate? There are maybe 10% of the people that goes through that process? Oh, 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. Like, we don't want to waste anyone's time.

But we probably, of the people we've interviewed, I think 40% have we've ended up hiring. Nice. Thank you. All right. I'm out of time. Thank you, folks. This was great. Thank you. Thank you. We'll see you next time.