Rethinking Team Building: How a 30-Person Startup Serves 50 Million Users — Grant Lee, Gamma

[upbeat music] Thanks so much, uh, for having me.

It's, uh, it's great to be here. Uh, my name is Grant. Uh, I am one of the co-founders and the CEO of Gamma. Uh, we are basically, uh, as alluded to, building the anti-PowerPoint.

So we're trying to reimagine how people create and share content. We ma-- wanna make that dead simple. And this all started with kinda just trying to solve my own problem.

I was previously doing consulting and, like many of us, have probably seen, uh, a page or a slide that looks like this, the blank slide, and just had this feeling like there's gotta be a better way.

And so we've been spending the past four 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 the right layers?

We can focus on the content itself and let it feel more like a content-first approach versus a di- design-first approach. And so, you know, we have, uh, 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, uh, 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, 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, uh, any of that because, you know, most of the talks today, really great talks around, uh, really innovation, obviously AI. It's very much a product, you know, centric lens that people are applying, which is amazing.

I wanna take a step back and, you know, I think a lot of founders are great at applying sorta 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. Uh, 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, uh, once a startup starts scaling, uh, 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, of startups and, um, you know, some of that still exists, but I do think there today can be maybe a, a new way.

And for us, you know, we've reached, uh, over fifty million users now. We're still a, a team of thirty, uh, and in fact, this is only more recently that we've become a team of thirty.

And so, you know, again, these are things that we're still learning a-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, 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 wanna 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 wanna 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 ten, thirty, 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, uh, to, 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've been if we were started just a few years ago.

So it's just a different, uh, way of like framing it.

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

It applies to many different disciplines. Um, this, uh, one concrete example I'll provide is, you know, a generalist on our team is our head of design. Uh, he was also happens to be our fir- 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, or he loves researching, talking to users, doing all of that.

So that empowers him to really what I call kinda 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 ca-- what are we actually capable of building so that when you go off and vibe code a, go code a prototype, it's

actually something you can ship and pr- and actually, uh, 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.

We-- He also has this really willingness to sort of adapt and reinvent himself, so every phase of growth, he's had to kinda 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 a com-- 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 al-also able to, to, uh, look across the team and actually provide, you know, g-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 are usually are great at learning can also be a great teacher.

Um, when we look for an interview process is someone that can teach some-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 kinda share in that understanding? Those are all things that I think a great generalist can encapsulate and, and certainly stuff where we try to suss out, uh, during the interview process.

The second notion is just, uh, introducing the notion of player-coach, and some of you may have heard of this, uh, before. This, uh, metaphor or analogy comes from sports.

In American football, uh, you have a, you have a, a sport that there's so much action going on all the time. It-- 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 play-- 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 top-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, uh, every single one of them is a player-coach. On our engineering side, we have player-coaches that, uh, have had 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, um, uniquely valuable. One, they're all 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, um, consider the things that are in flight and, and maybe change things, that player-coach has a ton of context, understands the nuances, can make the right 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 gonna 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, 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, uh, brand and, and culture?

Uh, uh, I say brand and culture because for me, brand and culture, they're, 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, to go hand-in-hand.

Culture, I mean, this piece of it is, 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 gonna 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 in pr- in 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, uh, 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, um, you are in it together. And if you have that continuity, there's just so much, like...

It's har-har-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, um, transparency, shared context amongst all things. Um, we have in our, 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 dogfood 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 just allows everyone to feel like we're still in a small room sharing this, you know, big, ambitious, uh, long-term vision and doing it together. I know there's a lot of talk of, like, oh, maybe there'll be the one 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 wanna, 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 gotta 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 out a team, and that's, 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, uh, you know, do this together.

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

Um, with AI 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 gonna probably spend some time in the idea maze. You're really trying to navigate, figure out where is there true user need and what problems are we solving.

And I do think there, 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 go be much more patient.

And I think even for us, like when we initially started doing our first AI launch, which 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, um, uh, I think realization that we did have bu- 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, um, impossible to unwind, and I think it's helpful to think a little bit more about that way earlier on in the process.

Doesn't mean you should slow down, 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?

Um, it's not something I would've done differently. I think I would've 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 if you have a big user base, experimentation's a key to velocity.

And, you know, we, we did do some of that, um, pretty early on, but it was more of a sort of gradual. I think we would've, you know, really taken our time to think about, okay, what should we do?

And like put more weight behind it. Um, if it would've changed anything, I'm not sure. But I think that's one thing, you know, I would've kept in mind. We have two.

Go here and then here.

Perfect. Um, 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, uh, gel quite as much with maybe like the technical or engineering-led culture you might have.

Yep.

Do you have any advice for like how to ma-- how to not like ruin some of that culture, but also n-- 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, uh, you know, how do you not mess things up by growing too fast?

And, you know, we're, 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 'cause, 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 takes the, to, that really goes into that job, know what great looks like, and then go on and finally fire, hi- hi- 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.

Uh, 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? Uh, 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 ag- high agency?

Yeah, totally. It's, it's probably stuff that you have heard before, but a lot of times, you know, you want to, uh, if someone has, uh, you know, prior work experience, you dig into their most challenging project or problem they had to en- encounter, and, uh, 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 is actually five le- like 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 gonna do this."

It was like, "I, I need to find, uh, 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. Uh, so hiring is probably one of the most important things that, uh, a company can do, right? I mean, it's either, uh, for better or worse.

What are some, uh, if there were any major failures that, uh, you have experienced and you, you know, could share with us, that'd be very helpful.

Yeah. The, the biggest failures were actually when we didn't-- when there was a role that there was some ambiguity, ambiguity, and we weren't able to do a, a work trial.

So a 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, it oftentimes wasn't a good fit.

Because neither them or us knew kind of like, okay, what were we actual-- what was going to be that sort of good fit? So if, if you can, if you're lucky enough to be able to do a work trial, whether it's two days or three months, our, 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 have you had situations where if people work out, then-

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

failure rate for us. Is that it? All right. Thank you, everyone. I'm on LinkedIn if anyone wants to connect. [upbeat music]