Going Founder Mode in a Big Company

Host Intro (Gene Kim)

All right. How were the talks this morning? Thumbs up. Round of applause. Good? Fantastic. We have some amazing talks this afternoon.

So earlier this June, I was at GitLab Transcend event in London, and I kept on hearing about this team inside of their organization that was doing something like 30,000 commits in two months and doing 5,000 merge requests touching nearly every product repo in the company. And I was like, "I need to meet this team." So eventually, Andrew Ramirez introduced me to Angelo Rivera, engineering lead for Orbit.

And I had so many questions for him. For example, how strategic was the project that you were working on? Answer: very strategic. How did you pick the team size and shape? How did the project come to be? What sort of processes broke around you as you were racking up these kind of numbers?

So I will admit that my timing wasn't great because this was right before Angelo had to present to hundreds of people and 15,000 more people online. But I'm so grateful that he made some time for me afterwards, where we went into great detail into all of these questions.

And so I am so delighted that he'll be sharing the answers to all of those questions, and he'll be co-presenting with one of his teammates, Jean-Gabriel. Here to tell their amazing story — Angelo, Jean-Gabriel.

Michael Angelo Rivera

Well, nice to meet everybody. My government name is Michael Angelo, but my dad thought Angelo was too Italian, so he put Michael in front of it, which just made it 10 times more Italian. So most people know me by Angelo.

Jean-Gabriel Doyon

And I'm Jean-Gabriel. I'm a founding member of Orbit with Angelo.

Michael Angelo Rivera

Cool. So much like the title says, this is a little bit of a nod to the original founder of GitLab, Sid. And we won't be nearly as cool as him because he made an article very similar to this for how he went founder mode on his cancer treatments, and he is in a much better state.

And again, we won't be as cool, but we wanted to talk about the story of how we went founder mode at GitLab, and we thought it was especially important and relevant to everybody in this room today when you're trying to talk about AI transformation and getting stuff done.

So with that, let's go ahead and talk about it.

So Orbit is not only the proof of concept we brought to production — it's actually a full-on running service now serving over 2,500 customers, reaching over a million users, and it has indexed over a million projects. Our graph consists of 50 billion nodes, and this represents, again, across 2,500 customers at GitLab. Our team has merged thousands of merge requests, impacted almost 90 repositories, and all of that was shipped by a small team of six engineers. We were able to bring the proof of concept to production within the first three months of the first commit.

Jean-Gabriel Doyon

And just to add to that, the reason why we're showing you this data is this is a true enterprise-grade product. So while it was built by a small team, we wanted to show some of the numbers on how big this system is, as it is a big data distributed system.

So for the multi-call people in the room — and this might interest you — our system that runs in production currently can reach up to tens of millions of rows per second of ingestion, which means building our whole 46 billion rows graph in two and a half hours. And this runs on limited resources, which is super important because we distribute our solutions to dedicated environments and self-managed customers. We are also almost FIPS compliant, so that's good for our dedicated government customers. So this is a real production service. We've actually brought it to production. It's actually deployed to customers.

Michael Angelo Rivera

Awesome. And rather than just talk about the product, we can do a little bit of a product demo so everybody here gets a sense of what we actually built and why it was strategic, as Jean-Gabriel was saying, for the company.

So I'll just show a little bit of a demo here so people can relate a little bit more. Of course, everybody's job today is based around AI context, and so our job was to bring better AI context to agents at GitLab across the entire software development life cycle.

And so what you're seeing here is a graph that represents over a billion nodes and probably well over 10 to 12 billion edges. What we did is built a semantic graph over all of our GitLab software data. It basically allows agents to write their own queries, either in GQL format or openCypher, and effectively allows you to ask any question you want about your GitLab instance. So if you're a developer or a VP of Eng and you care about productivity or getting the right answers about your code, that's what this is for.

And so you can just see in this one prompt here — we both live and breathe GitLab every day — I asked a simple question: give me the complete architecture of all of GitLab. And just in a few tool calls, and this is just a web chat, it gave us a complete map of every single repository inside of GitLab, leveraging the product that we built.

And I know it's a little bit true because, again, we work in this code every day. Of course we could spend all day demoing this product to you. We're very proud of what we built as a small team, but we also want to talk about the people side and why we think what we did is relevant in today's AI age. So that's a little bit about the product itself.

Do you want to talk about a little bit of the backstory?

Jean-Gabriel Doyon

Yeah. So initially how it started is, Angelo had an idea when we worked in the AI R&D engineering organization back when we were doing tab auto-completion with unready code — some of you may remember that, that's already so far behind. But Angelo had an idea: how could we provide context to agents in a way that helps the completion be more accurate and reduce hallucinations? And this could be super relevant across systems more than just a single code base.

And Angelo was lucky enough to have a manager that allowed him to go in and actually explore that proof of concept and build it.

Michael Angelo Rivera

Yeah. And originally at the time, this project was called Project Da Vinci. And we wanted to show this timeline because it's super important to know the story of Orbit for the reasons that we think this new way of working is highly effective in a big company.

And so you can see just in the timeline here, Project Da Vinci was started, but unfortunately — if you want to talk a little bit about how traditional software development would work — it was assembled as a traditional software project where more generalist software engineers and an engineering manager were brought on to build the project. But that wasn't the right call at the time, and it isn't the right call today, because for building such a system, you need to get people that are experts in their field and build a team that can actually work together, that is actually cohesive.

Jean-Gabriel Doyon

And that's what we saw there, because we saw multiple attempts at building the project, but it all led to nothing or to dead ends until this January this year.

Michael Angelo Rivera

Yeah. And so, as you can see, the project was attempted multiple times, but we were lucky enough to be given the opportunity by Bill Staples, our CEO. And when I say opportunity, we meant basically a mandate to deliver this project end to end.

Again, this is a big data system. We have a pretty small team, which we'll talk about. But when this was all occurring, I'm a little bit more of an entrepreneurial type, and I basically was telling Gene, as we were kind of explaining the backstory, in order to deliver a project of this scale in the time that we needed to, I basically told Bill at the time: we need to completely revise the way that we work and do this in a very strategic way.

And Jean-Gabriel, if you want to tell a little bit about after we got the go-ahead.

Jean-Gabriel Doyon

Yeah. Once we got the buy-in from Bill, our CEO, to go all in, Angelo handpicked a team. He handpicked the people he believed were key players in the company to deliver such a project — people that would actually practice extreme ownership and treat this like their own company.

So when the team was built, in January, we met the first time in person and wrote the first commit. And a few months down the line, we were already in production serving customers in beta. And since then, we've already shipped 184 releases and are approaching GA.

Michael Angelo Rivera

And some of the conditions that I was sort of saying we need to operate under are some of these principles here.

So the first thing is starting with a small team. It sounds counterintuitive, but picking the right people is just as important as the capital investment that you're putting into things.

The second thing is real authority — giving the team itself, like Jean-Gabriel said, complete end-to-end ownership of the project.

Third thing is space. So having leadership — and I would really like to thank all of my mentors and bosses: Nitin, Maverick, Siba, our current CTO — basically give us the air cover and freedom to what we like to call cook, or go founder mode.

And then the fourth and fifth one kind of go hand in hand: allow everybody at the company to know this team is moving — acknowledge that this team is going to be moving at startup speed, but they need support and help from the rest of the capital that's available in a big company.

Jean-Gabriel, you want to talk about the team a little bit?

Jean-Gabriel Doyon

Of course. In our case, that's our team. We started off with four, and then we expanded to six.

We have Angelo, who is more of the entrepreneurial tech CEO type. I spend more time working on distributed systems and making sure all gaps are covered in the business. Dmitry is our solution architect — he knows the GitLab stack in and out, he's the expert here. Mike is our crack low-level guy, so if any of you are into compilers, query engines, database query planners, he's definitely the expert. Aaron joined this summer, and he's our expert in agent experience. And I skipped Bogdan, but he's the one that actually helped us go to production, so I saved the best for last — he's our infrastructure guy. He helped us go to staging and production in such a quick amount of time. So credit to him.

And I'm just saying this to show that in the AI world we live in, where generating code is cheap, assembling the right team is one of the most important things you can do. Because that team is going to be responsible for using the tools they have to actually build a successful product.

In our case, we have different personas on board. You can see we don't have talent that overlaps as much as generalist teams tend to have. Everyone has their own skill, and they bring their own part to the project.

Michael Angelo Rivera

And as we can see, not only did we show previously how big the system we built was as far as the amount of data that flows through it — it is a big data distributed system — we also wanted to talk a little bit about the velocity at which our team moved.

And you can see in a little bit of the stats here, we were able to do, in one sprint, over 100K lines of code. We actually hand-reviewed a lot of that code, as well as a number of merge requests. And Jean-Gabriel, if you want to tell a little bit about the story of when we got together in January.

Jean-Gabriel Doyon

Of course. That will hopefully answer Gene's question on some of the processes that—

One of the things that we did differently than most enterprises will do at a big scale — like GitLab, where they have thousands of employees — is we actually, once the team was handpicked and built, all flew into Vancouver into an Airbnb. We all met there. We got an Airbnb with a big kitchen table. So if any of you are founders, you may remember actually coding at the kitchen table. That's what we did for two weeks: heads down, everyone with their own laptop, and we just wrote the whole thing end to end and deployed it on a test instance of GitLab.

So that's one of the key things we did to not only prove that it could be done and could work in production, but we had a working prototype that also showed it could be deployed to customers.

Michael Angelo Rivera

Yeah. And then once that was running, we realized we had to bring in the whole company early. This means including legal, security, infrastructure, data engineering, leadership.

Once the proof of concept was built, we flew in every key player from every one of these areas into Vancouver, and we walked them through how the whole system works. And this way, we were able to catch gotchas early. We were able to get alignment across all the teams we needed to work with, and we were able to get started on the processes we needed to complete for government customers, for self-managed customers, and data.

So we treated other teams as consultants, not gates.

Jean-Gabriel Doyon

Yep, exactly. And that's one of the things that I think might be missing nowadays. Of course we had the small team, but we led and indirectly led over 30 to 50 people and brought in so many different experts throughout GitLab, and really partnered with them really early on in the project. And the alignment was brought in as early as possible.

And just to add a little bit to the data — and Gene was alluding to it, and this goes back to involving the whole company — our product touched pretty much every single part of GitLab's architecture. And so, we worked in over 80 repositories.

One of the key things that a lot of enterprise people here might appreciate is not only did we work in a greenfield project that was a repository on the side, we actually did real integrations into what we call the GitLab monolith, which is the big code base that every engineer works out of. So not only does it prove a small team can move fast on the side, but if you have that alignment early on, you can move fast even with a big legacy code base.

Michael Angelo Rivera

So with that, we just wanted to yap a little bit about some of the things that we learned that might apply to you or something to think about in the future.

Jean-Gabriel, you want to talk a little bit about this here?

Jean-Gabriel Doyon

Yeah. Going founder mode for us means that everyone owns every part of the— It means that we all have a shared sense of ownership of what we're doing. So whether it's team coordination, bringing the right people on early, getting the conversation started ahead of time so that when we approach deadlines or milestones, we're not blocked by downstream dependencies. So this goes as far as staffing, observability, security, legal compliance, and every single other function of the business.

And we're also active on calls with customers. If we're going to build a product and we want to go fast — founder mode, kind of like if we're in a startup — we need to be close to customers. We need to have engineers on calls with customers so they can see and have a firsthand feel for the reaction of customers using their product.

Michael Angelo Rivera

Yeah, and I think that's super important, especially from the product management side and those related functions. One of the reasons why we're able to move so fast and evolve the product is because I personally got to meet over 100 customers, and the team itself has interfaced directly with customers, which is another key tenet that we found.

Jean-Gabriel Doyon

And also for us, being founder mode also means everyone's an IC. So even if Angelo does a lot of management stuff at director level, he's still an IC, he still pushes code. Even sometimes he pushes MRs that are way too big. Sometimes I'll see Angelo sneaking changes in between meetings for a merge request that's 5,000 lines of code and could be 50. And we hold ourselves accountable, so I'll just tell him, "This is not it." He knows it was not, and he goes and fixes it.

This is how we hold ourselves accountable, and this is what it means to treat it like a startup.

Michael Angelo Rivera

Yep. And that's one of the major things that we learned: everyone should be an IC to some degree, so everybody can relate to the end product that they're building.

And then just some other things — we don't want to come across as too preachy, but hot take of 2026: reviewing code we believe is still important. Not only do you have to read code, but you should be really looking at the mission-critical code that you're shipping. But with that said, a lot of automation is still valuable. And what we're finding is a blend — like we were showing the team earlier — a blend of product and people sense is absolutely essential for the new engineering age.

And then a few other things around staying in the loop. Of course, we found that being in the loop is still very important. And the other two tenets, when it comes to building an enterprise-grade product: you still have to ensure that you have redundancy in the system, ensuring you're hiring and making sure you're practicing good production engineering.

And with that—

Jean-Gabriel Doyon

We have a message to give to leaders in the room. Maybe you're in management, maybe you're a higher executive. There is a huge opportunity now with the new tools for every single one of your engineers to build and start a great initiative that could turn into a product line. So if you're a leader and you see people that show potential and want to explore ideas, I believe it's important to give them a shot or give them the space to do so. Because I think it's important to make that bet, and I think in today's world, if you don't make that bet and you let these opportunities slip, someone else will take the bet. And it might have been less expensive to just let your engineers experiment and maybe grow a product line than to pass on it and let someone else or your competitor do it.

Michael Angelo Rivera

Yep. And just like he said, really we think it's important to find — and just like I got the opportunity from Bill and some of the key leaders in our organization — we think it's important that as a leader, you go and find the team that you want to build, or have them build something, and take that bet.

So we're happy to meet with anybody after to learn a little bit more about our story. But yeah, that's it.

Jean-Gabriel Doyon

Cool. Thanks so much. Thank you.