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

Thanks so much for having me. 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 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 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 design first approach. And so 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 innovation. It's very much a product centric lens that people are applying, which is amazing. I want to take a step back and I think a lot of founders are great at applying first principles of 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 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. 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 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 some of that still exists. But I do think there today can be maybe a new way. And for us, 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, and so 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 obvious. Where do you begin? Who do you even hire? For us, I want to talk a little bit about 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, and 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 your engineering counterpart by knowing like deeply, 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 put 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 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 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, 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 domain experts in a space, can they articulate that in a 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 like 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, 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, 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 A.I. a.I. 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, 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 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 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, consider the things that are in flight 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 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, expertise in places where 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 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 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 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 dog food 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, long term vision and doing it together. I know there's a lot of talk of like, oh, maybe there'll be the 1 billion 1 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 we really want to preserve that magic for as long as humanly possible. So this talk started with me talking about how the gamma journey began, which is me thinking about, hey, from a product perspective, there's gotta be a better way. And my, 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 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 a moving so fast, if you could go back, what would you do different, 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 four years ago, so this was before, like the more recent 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, figuring out where is their true user need and what problems are you seeing 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 go be much more patient. And I think even for us, like when we initially started doing our first AI launch 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 is 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 come 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, especially if you have a big user base. Experimentation is a key to velocity. And we did do some of that pretty early on, but it was more of a sort of gradual. I think we would have really taken our time to think about, okay, what should we do and put more weight behind it. If it would have changed anything, I'm not sure, but I think that's one thing I would have kept in mind. We have two 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 the technical or engineering LED culture you might have. Do you have any advice for how to not ruin some of that culture, but also. So 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 the question is, outside of engineering, basically, how do you potentially not mess things up by growing too fast? And we're still learning there often times 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 I in a previous life, I've never hired for the 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 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 agents 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 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 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 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 taking orders, orders and like, hey, I'm going to do this. It was like, I need to fund 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, 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, it's 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'm going to 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 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 wasn't a good fit because neither them or 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, 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. 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 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 is actually pretty high failure rate for us. Is that it? All right, thank you, everyone, I'm on LinkedIn if anyone wants to connect.