LongCut logo

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

By AI Engineer

Summary

## Key takeaways - **Reject Blitzscaling: Focus on Lean Teams**: Startups in the AI era should move away from traditional blitzscaling and hyper-growth. Instead, focus on building lean, agile teams of generalists who can adapt quickly. [02:42], [04:05] - **Hire Generalists, Not Just Specialists**: Generalists, like Gamma's head of design who codes and researches UX, can connect dots across disciplines, understand technical constraints, and adapt to changing product phases. [04:18], [04:44] - **Embrace the Player-Coach Leadership Model**: Player-coaches are on the field, making real-time adjustments like a quarterback in football. This model allows leaders to stay close to the work, mentor effectively, and make quick technical trade-offs. [06:48], [07:43] - **Scale with Brand and Culture from Day One**: Investing in brand and culture is crucial for scaling, especially for small teams. A strong culture, reflected in a living culture deck, creates a 'small tribe' feeling with continuity and shared context. [08:54], [09:43] - **Prioritize Experimentation Infrastructure Early**: Given the rapid pace of AI evolution, it's vital to build infrastructure for experimentation early on, even if it requires more upfront effort, to maintain velocity and avoid costly unwinding later. [13:34], [13:54]

Topics Covered

  • The rise of the generalist is crucial for lean teams.
  • Player coaches are essential for rapid adaptation.
  • Invest in culture to build a cohesive, high-performing tribe.
  • AI's rapid pace demands patient exploration, not just speed.
  • Work trials are critical for assessing fit in ambiguous roles.

Full Transcript

[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 as alluded to building the

anti-P PowerPoint. So we are trying to

reimagine how people create and share

content. We make 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 uh 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, 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

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. 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 blitz scaling phase

of of startups and um 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 uh over 50

million users now we're still a team of

30 uh 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 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 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

uh to to companies before you're just

much smaller. For us, you know, at our

scale, I would say we're probably

onetenth the size of what we would have

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 an idea this

notion of like a full stack engineer and

applies to many different disciplines.

Um this 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 very 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 go code a prototype,

it's actually something you can ship and

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 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 the user as a 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, 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 is 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. 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 kind

of share in that understanding those are

all things that I think a great

generalist can encapsulate and and

certainly stuff we try to sus 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 you

have a 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 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, rep prioritize 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 tradeoffs

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 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

culture? 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. It's 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 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 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 companywide

showand 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 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 1 billion

oneperson 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 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

going to 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

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 a 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

because part of that um 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 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?

Um it's not something we 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 have a big user

base experimentation is 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 have 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 have changed anything I'm

not sure but I think that's one thing

you know I would have kept in mind we

got to 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 culture you might have.

Yeah. Do you have any advice for like

how to make 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 uh 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 takes the that really goes into

that job know what great looks like and

then go out and finally fire 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 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 prior work experience, you

dig into their most challenging project

or problem they had 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 was

actually five 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 going to do this. It

was like, I 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 or

third order or wise, 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 uh a company can do, right?

I mean, it's either 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 would 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 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

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 often

times 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 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 if didn't work out then

the work trials have actually all worked

out which is great and 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

pretty high failure rate for us.

Is that it? All right. Thank you

everyone. I'm on LinkedIn if anyone

wants to connect.

[Music]

Loading...

Loading video analysis...