Rethinking Team Building: how a 30-person Startup serves 50 Million Users — Grant Lee, Gamma

Thanks so much for having me. It's— it's great to be here. My name is Grant. I am one of the co-founders and the CEO of Gamma. We are basically, as alluded to, building the anti-PowerPoint. So we are trying to reimagine how people create and share content.

We want to make that dead simple. And this all started with kind of just trying to solve my own problem. I was previously doing consulting and, like many of us have probably seen, a page or a slide that looks like this, the blank slide, and just had this feeling like there's got to be a better way.

And so we've been spending the past 4 years just really trying to reimagine the building blocks. How can we make it dramatically simpler so that we're not spending all this time designing, formatting boxes, aligning boxes, resizing them, figuring out theright layers.

We can focus on the content itself and let it feel more like a content-first approach versus a design-first approach. And so, you know, we have grown over the years, and for us, we're really trying to deliver both speed and power to our users.

A lot of what we pride ourselves in is giving people simple tools to really mold and shape their presentations, their content, much simpler. And longer term, we're trying to build what we call tools for imagination. So this is the whole notion of how can we help people really sort of stretch, shape their ideas in a way that's way easier for them to share.

And if we can do that, maybe we can help kind of push innovation forward in general. But this talk isn't about any of that because, you know, most of the talks today, really great talks around really innovation, obviously AI, it's very much a product, you know, centric lens that people are applying, which is amazing.

I want to take a step back and, you know, I think a lot of founders are great at applying sort of first principles to thinking about how do I build product. And I would encourage everyone to think about we're in an era where we can also apply those first principles to think about how do we build a team.

How do we innovate on org design? And we're obviously still learning ourselves, but I just wanted to share, you know, some of those lessons along the way to hopefully inspire you to all think about maybe there's a different way about building teams in the future.

This is the old way. We're all used to this. You know, there's many, many different flavors of this. Once an organization starts getting big, inevitably you have a bunch of hierarchy, and that could take shape in itself in many, many ways.

And, you know, what traditionally happens is once a startup starts scaling, you'll bring on the sort of VP. The VP will go on and hire their directors. Directors will go on and hire their direct reports. And you get this sort of cascading effect.

And this happens across every single function. And you can go from a small team, a tiny team, to a team that ends up becoming much, much bigger. And that can happen overnight. I mean, we've all lived probably through the blitzscaling phase of startups, and, you know, some of that still exists.

But I do think there today can be maybe a new way. And for us, you know, we've reached over 50 million users now. We're still a team of 30. And in fact, this is only more recently that we've become a team of 30.

And so, you know, again, these are things that we're still learning along the way and trying to think about what are some of the themes that we're starting to see that we can start talking about and sharing and obviously getting input from you all, and then for us to continue to learn and adapt.

So this kind of impacts three different pillars. The first pillar is, you know, obvious, where do you begin? Who do you even hire? For us, I want to talk a little bit about kind of the rise of the generalist.

What does that look like in practice? The second is, okay, now that you have a team, how do you manage that team? I want to talk about this notion of introducing the player coach, something that is very critical to how we build and manage the team.

And then the last is, how do you scale? You actually have a team, whether it's 10, 30, more, how do you actually prepare for the next phase? It doesn't mean you don't hire at all. It just means relative to maybe where you were to companies before, you're just much smaller.

For us, you know, at our scale, I would say we're probably one-tenth the size of what we would have been if we were started just a few years ago. So it's just a different way of, like, framing it.

So let's first talk about kind of what I call the rise of the generalist and what does that mean. This notion of a generalist is, you know, in engineering you might have an idea, this notion of like a full-stack engineer.

It applies to many different disciplines. This one concrete example I'll provide is, you know, a generalist on our team is our head of design. He was also happens to be our first hire. He is a designer that is both, you know, super visual.

He actually knows how to code as well. And in addition to that, he can actually really go deep on the core UX. So he loves researching, talking to users, doing all of that. So that empowers him to really what I call kind of connect all the dots.

You might be able to pull in and really empathize with, you know, your engineering counterpart by knowing, like, okay, deeply what is, what are we actually capable of building so that when you go off and vibe code a prototype, it's actually something you could ship and actually deliver in production.

And so understanding that comes with just being able to actually play with everything and have much deeper empathy for what you're building. He also has this really willingness to sort of adapt and reinvent himself. So every phase of growth, he's had to kind of change it up a little bit.

Like early on when, you know, there's really no product itself, like you're trying to think about, okay, what is the basic, most simple UI/UX that we can deliver to a user? As the product becomes much more complex, you need to iterate really fast.

He's the one coding prototypes, getting in the hands of users, setting up user tests, interviewing them, getting feedback, getting that back into the hands of users, iterating that a ton. And then we're also at a scale now where he's also able to look across the team and actually provide, you know, guidance and mentorship.

And I'll get into sort of player coach in a second because he's actually one of those as well. Inherently, I think what makes a strong generalist is someone that both likes to learn and likes to teach. And I think learning, it's one of those things, like if you're a continuous learner, especially in this age, it's very valuable.

There's so much innovation happening. Can you pick up new skills? And I think the counterpart of that is like people that usually are great at learning can also be a great teacher. When we look for an interview process, is someone that can teach someone else a new skill?

Like that is baked into how we approach finding people is can they not only be deep, you know, domain experts in a space, can they articulate that in the way? Do they really have deep understanding? Can they convey and persuade others to kind of share in that understanding?

Those are all things that I think a great generalist can encapsulate and certainly stuff we try to suss out during the interview process. The second notion is just introducing the notion of player coach. And some of you may have heard of this before.

This metaphor or analogy comes from sports. In American football, you have a sport that there's so much action going on all the time. The game on the field is moving incredibly fast. And what you can do is rather than just having the head coach make all the calls, make all the plays, call all the plays, you can have a player coach, someone that's actually on the field, help make some adjustments.

So in football, that could be you have a quarterback on the offensive side. On defense, you might have the linebacker. They're able to read and react to what's happening on the field and then not having to rely on the coach, they can actually make adjustments.

This metaphor applies today because I think the game on the field is AI. AI is moving incredibly fast. We're all forced to have to adapt. And so rather than having every single thing be a tops-down mandate, what if you had player coaches on the field that are able to actually understand how can we adapt, how can we rejigger, reprioritize really, really quickly?

And for all of our sort of core leadership team, every single one of them is a player coach. On our engineering side, we have player coaches that have had a ton of management experience, but they still love to code.

They still love to be in the day-to-day. And that allows them to be uniquely valuable. One, they're obviously so close to the work that they know what's happening. When someone else on the team needs mentorship, needs coaching, needs some form of prioritization, or how can we actually, you know, consider the things that are in flight and maybe change things, that player coach has a ton of context, understands the nuances, can make theright technical trade-offs, and in addition to that can make, you know, the sort of pave the path for longer-term career aspirations.

We don't know how this is going to scale, but for today, this is working well. And for us, it allows us to have this really, really lean team where, you know, we still have the ability to mentor and coach the individuals that need it.

And then you have deep domain, like technical expertise in places where, you know, you're able to make adjustments as fast as needed.

The last thing I'll talk about is scaling. And it's maybe a little bit counterintuitive. You know, you might think like a small team, why would you invest in things like brand and culture? I say brand and culture because for me, brand and culture, they're two sides of the same coin.

Brand is ultimately a reflection of your culture. Your culture is your values as a company. And you really want those two to go hand in hand. Culture, I mean, this piece of it is a little bit more obvious, but when you're a small team, what ends up becoming super important is like every new team member you bring on, you have to believe that they share your same values, that they operate the same way because you can't afford that not to be the case.

A bigger company, it's much more diluted. You might be able to bring on a bad hire. It's not going to be pervasive and like spread. Smaller teams, that cannot be the case. And so you need to invest heavily in this from day one.

We have a living culture deck that we've maintained basically since the beginning, and we rewrite it all the time. We look up at the makeup of the team. We kind of like really try to encapsulate everybody's core values and the way they behave.

And then we share that back out to the team. We onboard new employees with the same culture deck. It's an ongoing evergreen sort of exercise that we go through. And I think what comes out of this is like this feeling that this tiny team can have this feeling of being a small tribe.

And that tribe is something that's pretty magical. It allows you to have this feeling of continuity. It allows you to have this like feeling that you are in it together. And if you have that continuity, there's just so much like it's hard to even quantify that value because you're not having to retrain people, re-onboard people.

Like people just get it. There's that tribal knowledge. And I do think there's a lot of magic that happens. That translates into just, in my mind, higher productivity, transparency, shared context amongst all things. We have in our team, and it's easier to do this when you're small, is we have like three standing all-company all-hands meetings.

The very beginning of the week, we start with like going deep on metrics. We talk about, we have this thing called the wall of work where everybody's showing like what everyone else is working on. Wednesdays and Fridays, we do company-wide show-and-tell.

So this is a chance for people to also dogfeed our own product, use Gamma, present, share what they're working on. It could be a small project. It could be a feature they shipped. And this continuity allows everyone to feel like we're still in a small room sharing this, you know, big ambitious long-term vision and do it together.

I know there's a lot of talk of like, oh, maybe there'll be the 1 billion one-person startup. And I don't know, maybe that will happen, but my thought is like, why? It's so fun to build with a team.

Like, why do it alone? We're having a ton of fun building as a small team. And part of that is like we really want to, you know, preserve that magic for as long as humanly possible. So this, you know, talk started with me talking about how the Gamma journey began, which is me thinking about, hey, from a product perspective, you know, there's got to be a better way.

And my, you know, I guess challenge to you all is as you think about building your own teams, really thinking about, hey, you know, there's the old playbook, the old way of scaling and building up a team, and that's totally fine.

But is there today a better way? And hopefully you guys can find your own path and hopefully share back and we can all, you know, do this together.

I guess we have a few minutes for questions if anybody has any.

With the ag moving so fast, if you could go back, what would you do differently about building your current team now?

Yeah, that's a great question. So the question was, with AI moving so fast, what would I have done differently? We actually started, you know, four years ago. So this was before like the more recent, you know, wave. And so I do think, you know, when you're early on, whether you're using AI or not, you're going to probably spend some time in the idea maze.

You're really trying to navigate, figure out where is their true user need and what problems are we solving? And I do think the temptation today is to move super fast. AI can do everything for you. So you just jump onto the thing and start building.

I still think people can afford to be much more patient. And I think even for us, like when we initially started doing our first AI launch, it was two years ago, I almost wish like in hindsight we could have like really just taken our time to appreciate how much things are changing and evolving before going to like full steam ahead.

Like let's just build, build, build. Because part of that, I think, realization that we did have starting to build was that, hey, because things are moving so fast, like are there infrastructure decisions we should be thinking about earlier, much earlier on before things become too late?

You get to a scale where it's impossible to unwind. And I think it's helpful to think a little bit more about that way early on in the process. Doesn't mean you should slow down. It just means you should be thoughtful of it.

Do you have an example of an infrastructure decision that you would have gone back and done differently?

It's not something I would have done differently. I think I would have prioritized maybe more effort around even more so is we have a lot of infrastructure built around experimentation. And I think it's obvious now, like given all the different tooling, like, you know, especially you have a big user base, experimentation is a key to velocity.

And, you know, we did do some of that pretty early on, but it was more of a sort of gradual. I think we would have, you know, really taken our time to think about, okay, what should we do and like put more weight behind it?

If it were to change anything, I'm not sure, but I think that's one thing I would have kept in mind. We have to go here and then here.

You might already be there. At some point, you probably will have to bring in people, whether they're like communication experts or legal experts, that maybe don't gel quite as much with maybe like the technical or engineering-led culture you might have.

Yeah.

Do you have any advice for like how to not like ruin some of that culture, but also make sure that they don't feel completely excluded?

Yeah, the way we've been trying to do it is for the founders or other leaders to try to do the job first. So yeah, the question is outside of engineering, basically how do you, you know, potentially not mess things up by growing too fast?

And yeah, we're still learning there. Oftentimes, a lot of the jobs, for me, for instance, a lot of marketing, sales, customer experience was all done by me first. So I have some sort of baseline understanding because, you know, I, as in a previous life, I've never hired for those functions.

So how do I even know what good looks like? I try to do the job myself, oftentimes not a great job at it, but understand all the nuances that take the, that really goes into that job, know what great looks like, and then go on, finally hire that person.

We going back to the player coach, we still go out and find player coaches for that role so that it doesn't end up becoming this sort of cascading effect of like really, really big and bloated teams.

Some of the player coach stuff sounds like you're hiring a lot of high-agency people. How do you judge high agency when you're hiring people? That does not necessarily come from their resumes. What kinds of questions do you ask?

What kinds of processes do you follow during hiring to judge for high agency?

Yeah, totally. It's probably stuff that you have heard before, but a lot of times, you know, you want to, if someone has prior work experience, you dig into their most challenging project or problem they had to encounter and you ask them, you know, basically how they solved it.

What you'll find is people that have high agency or just a sense of ownership in general, they don't immediately jump to what the solution was. They'll talk about how they tried to understand the problem and then how the problem, what they understood at the surface level was actually five levels too high.

You had to keep on drilling. And if they can articulate what the true problem was, like keep on going down and then not only talk about what the solution was, but all the attempts at the solution, I think that goes to show that someone wasn't just like taking orders and like, hey, I'm going to do this.

It was like, I need to, one, understand the layers of the problem and then two, navigate and actually explore. Most people, when you start asking them like the second order or third order whys, they can't get there. And if they can't, then it's pretty clear that they probably weren't doing much of the thinking themselves.

Hey, thanks for the comments. So hiring is probably one of the most important things that a company can do,right? I mean, either for better or worse. What are some, if there were any major failures that you have experienced and you could share with us, that would be very helpful.

Yeah, the biggest failures were actually when we didn't, when there was a role that there was some ambiguity and we weren't able to do a work trial. So work trial is also something I didn't talk about, something we deploy where people actually do the job for a certain amount of time.

Much easier if they're obviously not currently working. And we've found great success when someone's in between or has been doing fractional work. We bring them to do the job first. And we do that for a few months where we had some roles where we weren't yet sure what we're looking for and we brought them on and they didn't do a work trial.

They just went straight in. Oftentimes it wasn't a good fit because neither them nor us knew kind of like, okay, what were we actually, what was going to be that sort of good fit? So if you can, if you're lucky enough to be able to do a work trial, whether it's two days or three months, in our case, we default to three months.

I would encourage you to try to do that, especially if it's a role you haven't done yourself.

And you had situations where it didn't work out then.

The work trials have actually all worked out, which is great, and a few data points, and we've done five plus of them. And then, yeah, in the cases where we didn't, it's actually pretty high. Again, going back to the role that we weren't certain about what we're hiring for, it's actually pretty high failure rate for us.

Is that it? Allright. Thank you, everyone. I'm on LinkedIn if anyone wants to connect.