- Camille Fournier, a managing director at 2 Sigma, discusses the lack of great managers and the importance of good management in the tech industry.
- She explains that there was a negative sentiment towards management and hierarchy in the tech industry, particularly in startups, but she believes that good management is crucial for effective engineering teams and companies.
- Fournier emphasizes that management is a technical discipline and not just something anyone can do.
- She also discusses the challenges of transitioning from an individual contributor (IC) to a manager and the importance of routines like one-on-one meetings in building trust and addressing issues.
- Fournier emphasizes the need for managers to treat their team members as human beings and create a psychologically safe environment for open communication and vulnerability.

- Building psychological safety within a team is crucial for trust and open communication.
- Regular one-on-one meetings with team members are important, frequency depending on the size and nature of the team.
- Creating a sense of team identity and collaboration is essential, even in remote work settings.
- Rookie managers should avoid the mistake of trying to solve team problems by writing code themselves.
- Proactively addressing interpersonal issues within the team is necessary for a healthy work environment.
- Firing employees should be considered in cases of theft, lying, harassment, or abusive behavior.

- HR plays an important role in addressing legal issues in the workplace.
- Dealing with employees who are not producing or are negative can be challenging.
- HR can help create performance improvement plans (PIPs) to address productivity issues.
- Sometimes it is necessary to let go of employees who are consistently negative and draining the team.
- Moving negative employees to another team or out of the company can have a positive impact on team productivity.
- Becoming a manager while still wanting to code can be difficult, but it is important to push through feelings of guilt and be patient with the learning process.
- It is okay to decide that management is not the right fit and continue on a technical career path.
- Side projects can be a great way to scratch the coding itch, but leaders should be cautious not to overestimate their expertise based on side project experience.
- New managers often feel overwhelmed, but it is important to prioritize tasks, delegate when possible, and let go of unnecessary expectations.
- Delegating and learning to let go of certain tasks is a crucial skill for managers.
- Not all tasks need to be held to the highest standard, and it is important to identify what can be delegated or dropped.

- Dropping things occasionally is inevitable, so it's important to be comfortable with it and ask for help when needed.
- New managers should not feel the need to know everything and should lean on their more experienced managers for support.
- Coaches, peer mentoring, and seeking advice from friends are beneficial for new managers.
- To create a cohesive and productive team, it is important to reinforce shared cultural values and address any values mismatches.
- Hiring processes should be designed to screen for cultural fit and strengths, and trial periods can be helpful but may not always be feasible.
- Recognizing and praising employees' specific achievements is important, and encouraging peers to give praise as well creates a positive work environment.
- Non-engineers running engineering teams can be successful if they have the necessary skills and understanding of the technical aspects.

- The speaker believes that engineering teams should be run by engineers, as engineering management is a technical discipline.
- However, it is common for executives or senior managers to report to non-engineers.
- Non-technical managers can struggle to understand and communicate with engineering teams, leading to inefficiencies.
- The speaker stays informed and credible by maintaining relationships with technical senior ICs and staying up-to-date with systems and design.
- Leadership and management are closely linked, and it is difficult to be a good manager without leadership skills.
- Providing clarity in times of ambiguity is an important aspect of leadership.
- Building trust and simplifying decision-making processes are ways to develop leadership skills.
- The speaker's newest book will be published by O'Reilly and available on Safari and Amazon.

- Camille Fournier, a managing director at 2 Sigma, discusses the importance of good management in the tech industry and the challenges of transitioning from an individual contributor to a manager.
- She emphasizes the need for managers to treat team members as human beings and create a psychologically safe environment for open communication and trust.
- Regular one-on-one meetings, creating a sense of team identity, and addressing interpersonal issues are crucial for a healthy work environment.
- HR plays a role in addressing legal issues and creating performance improvement plans for unproductive or negative employees.
- New managers should prioritize tasks, delegate when possible, and seek support from experienced managers and mentors.
- Hiring processes should focus on cultural fit and recognizing and praising employees' achievements is important for a positive work environment.
- While non-engineers can run engineering teams, it is beneficial for engineering management to be conducted by engineers.
- Leadership and management are closely linked, and providing clarity and simplifying decision-making are important aspects of leadership.

Camille Fournier is a Managing Director at Two Sigma and the former CTO of Rent The Runway. She’s also the author of The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change.

https://twitter.com/skamille
https://www.twosigma.com/
https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth-ebook/dp/B06XP3GJ7F

If you’re interested in doing Startup School this year, signups are open at StartupSchool.org. The course begins on July 22nd and goes for 10 weeks. Select companies who complete the course will also receive 15,000 dollars in equity-free funding.

https://www.startupschool.org/

The YC podcast is hosted by Craig Cannon.

https://twitter.com/craigcannon

Y Combinator invests a small amount of money ($150k) in a large number of startups (recently 200), twice a year.

Learn more about YC and apply for funding here: https://www.ycombinator.com/apply/

***

Topics

00:00 - Intro

00:35 - Why do many individual contributors (ICs) never experience a good manager?

3:15 - How did the ideology of management being bad become pervasive in startups?

5:15 - What should a new manager do in their first 90 days?

8:45 - Getting better at 1:1s

11:05 - More tips for the first 90 days

13:05 - Remote work

15:00 - Mistakes rookie managers make

19:15 - Letting people go

23:25 - Being a manager and still wanting to write code

27:45 - Feeling overwhelmed as a manager

31:15 - Getting a team to gel

38:30 - Giving people kudos

39:45 - Non-engineers running engineering teams

41:55 - Staying legit technically as a manager

43:15 - Management vs leadership

All right, Camille Fournier, welcome to the podcast.

So you are a managing director at 2 Sigma, former CTO of Rent the Runway, former VP of technology at Goldman Sachs, also an author.

Your first book was the manager's path, a guide for tech leaders navigating growth and change.

And you also have a book coming out this year that you're editing called 97 things every engineering manager should know.

We have a lot of management questions for

So 1 of the things you mentioned in the book that I found particularly interesting was a lot of people as I see never experienced great managers.

I mean, first of all, I think there's just a lot of bad managers out there.

Part of the reason I wrote the book was that I had seen a lot of people who had never had a good manager, and I felt like there were a lot of people who wanted to be good managers, but didn't even really know where to try or where to start, especially when it comes to engineering management, which I feel like is a little bit different than just generic people management.

So first of all, I just think there's not that many good managers out there.

And then it's interesting that I'm talking on this Y Combinator podcast because I think the thing that got me really writing a lot about management in the first place when I started blogging about it, was actually that there was this really big sentiment in the tech industry and particularly in startups right around like 2010, 2011 when I was first sort of doing the startup thing myself, which was that like management is bad, management is overhead, flat structures are the best, hire smart people and get out of their way.

I think at that time, Google still had their 50 people to 1 manager kind of structure.

All of these companies and a lot of successful companies that had started in Silicon Valley and that were startups really had this very negative reaction to management and hierarchy.

They thought it was bureaucratic and a waste of time.

And so I had worked at Goldman Sachs where there was management, and I had come to this startup and I was looking around and I was like, you know, the thing that I'm observing is that actually, management is pretty important, that good management is actually a pretty important part of making engineering teams effective, making companies effective.

It just simply isn't true that management is overhead or waste, that I had all these friends who had had really bad management experiences.

And I was like, you know, I think there's something to be said about this.

I think there's something for people to learn about this so that they can appreciate it more.

And that's kind of what got me into writing about the topic in the first place.

And, you know, that's part of why I wrote the book, was that I wanted there to be more good material for people that would help them appreciate management, help them understand that it's kind of a hard and special discipline, but it's also a technical discipline and not just something that any random people manager can do.

Right, and it's addressed in the book, but you're like, this is not a bullshit job.

Now, why do you think that ideology, because it was definitely pervasive, and it still is to a certain extent.

Why did that become so common within tech and more specifically within startups?

I mean, I think the thing is like, when you're a really, really small startup, like, yeah, you don't necessarily need to think that much about management.

When it's a very small group of people that are all just really, very closely working together on very obvious objectives.

And, you know, you've all already agreed to have a lot of skin in the game because you're probably not getting paid all that much money and you know, it's all about sort of these future rewards.

I don't think that management, I'm sure a great manager in that situation who also happened to be like a great founder and a strategic thinker might be great or super helpful, I don't know.

But you know, like realistically there are other more important things, but at some point you get enough people that you need to really coordinate work amongst people who are not just like joined at the hip, talking to each other all the time, completely on the same wavelength.

And that's when structure and hierarchy and some kind of management starts to become more important.

And so I think it's really just, I think like when you have a lot of people who have seen success at these very small stages and they believe incorrectly that the thing that made them successful was just like, well, we just got these smart people together and let them do what they thought was right and success happened.

You can take the kind of wrong lesson from that.

And I think that contributes to this sort of, not a disregard for management.

Right, And what stuck out to me was the book's focus on that transition from IC to manager.

Like so many other things are about like org structure and like motivating the team and all that kind of stuff.

This is very much about like, this is your technical job.

And then all of a sudden you're transitioning to another job, which is technical just in a different way.

So I think maybe what would be most helpful for us to talk about are those like early days that like, you know, first year maybe of an IC's transition from an engineer full-time to a manager.

I mean, you have different like tech lead and all kinds of different roles for that, right?

So say I just got promoted, I'm a new manager.

What should I try and do in the first quarter that I'm managing a team?

Oh, I mean, so I think a lot of it is just getting comfortable with the routines of management that are different than what you were doing before.

So it a little bit depends on what your job was before.

There are plenty of tech leads who are already comfortable with, I don't write code all the time because, you know, my job is doing a lot of project management already and sort of leadership and whatever, code reviews and things like that.

So that maybe you're already used to not having to type code all day, But you probably still aren't comfortable with things like having one-on-ones, for example.

One-on-ones are super awkward the first time you do them, the first many, many times you do them.

Like, if you've never been the person who is the manager in a one-on-one situation, it just is weird.

Like I remember it being really weird when I first started.

So one-on-one in the sense of transitioning from peer to tech lead in the most part, or.

From transitioning into a position where, yeah, like you're kind of the manager.

Like people expect you not only to be there to give them technical advice maybe and guidance, but actually to like, I'm having interpersonal issues with someone, help me out with this, or tell me where my career should go, or explain my benefits to me, even, you know, all of these different, like little things that maybe you've occasionally talked about, but it's always been a little bit more of like a friend talk.

And now you actually have power to do something about them, potentially to, to influence them.

You have the responsibility to do something about them.

Maybe not for everyone, but certainly for me, it felt like a really heavy change in focus and the way I had to interact with people.

I remember you were describing yourself as kind of an introvert and not necessarily like buddy, buddy with people on the team.

And so how, so Max from FAIR, a YC company has been on the podcast and he's actually talked about that too.

But he said that in doing so, people stopped coming to him with little things, but then those little things got to be increasingly bigger things because they were intimidated.

Yeah, I think that's part of why the one-on-one regularity is so important, because you want to make people feel like they have a time that you respect for them to bring things to you.

So I think that's why I feel like surely everyone has heard this message already, but there are a lot of people who still kind of haven't, they still haven't really internalized.

Like the reason that you have one-on-ones, the reason that you try very hard to honor whatever frequency is the right frequency for your team, even if you don't have anything planned to talk about, is that, like, you need to make it comfortable for them to feel like they're not interrupting you.

So that when it's like they have some nagging little thing, they don't just leave it aside and leave it aside and leave it aside until it's like a raging fire or leave it aside until they've decided there's no job for me here and I'm quitting and I'm going somewhere else.

And you're scrambling to like recover this person that if you had just heard 3 months ago, they were kind of bored and feeling, you know, disaffected with their project or they wanted to move on to something else, you could have actually done something about it.

Right, And so do you train yourself for certain vocabularies that like people are saying around like, you know, this time feeling about a certain project, you just get better, you know, developing empathy, like,

yeah, I mean, I think you certainly get better at kind of detecting cues and different kinds of people.

You get better at like part of what you need to get better at is getting people to talk to you and getting people to, to open up to you.

So that's, that's part of why, it is important to treat people like human beings at work and to open up about personal things a little bit, right?

Again, you don't have to tell people all of the details of your personal life and you shouldn't pry in all the details of theirs, but appreciating people as human beings is important so that, you know, they don't feel like they have to just be all business with you.

And I think that, in turn, just builds up vulnerability.

There's a whole psychological safety is a really important research concept in building good teams.

Teams that feel psychologically safe are able to ask each other questions that are maybe like, they're not afraid to look dumb in front of 1 another, they're not afraid to like admit that they're mistakes and learn and they don't feel competitive.

And that's really important in building trust in the team.

And so again, part of what a manager needs to do is they need to get good at opening themselves up a little bit so that people will open up to them.

They can build that safety and they can hear about things earlier.

People will start to be unafraid to mention things to them.

So in addition to setting up regular one-on-ones with everyone on your team, which you say like every 2 weeks at most, right?

Every 2 weeks, every 2 weeks is would be my, my recommendation would be, weekly or every 2 weeks, depending on the kind of work and how often you interact with them in other ways.

So like I do weekly one-on-ones with all of my directs but I manage managers of managers so I need to talk to them every week because they've got a huge team that they need to tell me lots and lots of things about.

But if you are managing a team of 5 who's working on a project that you're also doing a little bit of work on, you may only need to do a one-on-one every other week because a lot of the project work and conversation is gonna come out in other ways.

Okay, and So what else do you think is part of like an effective recipe for the first 90 days?

So something that I just recently, I don't think I ever wrote about this or I don't know if I've written about it yet, but like something that came up to me was I was coaching someone recently who was like, yeah, so I'm just, she's a new manager and she's like, and I've just started this team and like, you know, I'm seeing these problems between these people on the team and we're talking about it, we're talking about it.

And I was like, you know, well, like, how does your team work together?

And she was like, well, they don't really, like they each have their own little thing that they're working on.

So you have a team, presumably you're, you know, if you are a manager of a concrete, something set of projects or project or whatever, make your team a team.

And that means make them sit down together as a team on some cadence to just talk about the work, talk about the projects, talk about what's going well and what isn't, help them think of their identity as a team, so that they feel comfortable working with 1 another.

It can be very easy, I think, for engineers with certain kinds of backgrounds to think of engineering as really like individuals, kind of like If anyone listening to this has kids, you know that when kids are like a certain stage of development, they do this called parallel play, where like, you know, you've got 2 like 3 year olds or 2 year olds, they're not really playing together, they're kind of playing next to each other, right?

And I think that a lot of engineering sometimes feels like parallel play, where it's like, people, they aren't really working together exactly.

They're kind of each working on their own project separately and maybe they give each other code reviews, but making your team actually like feel like a coherent group so that every teammate understands their role on the team, but also, you know, hopefully can cover for 1 another a little bit, you know, sharing support burdens, you know, code reviewing, doing design together.

That's another big thing to do in your first 90 days that I don't think I've written about yet.

And it's actually something important that not everybody realizes.

And now in terms of remote work, which is increasing, your book came out a couple of years ago.

So even now it's more so than it was a couple of years ago.

I will be the first to admit that I am not an expert at remote work, because I've never really managed a fully remote workforce.

So I have a team in Houston, and I have some people in London right now, but they are in offices in those locations.

But I have a lot of friends who do, and I've talked to them a lot about it because I think it's really interesting.

And my understanding is that it still applies, it might even apply even more in certain ways in remote work because you don't have the natural occurrence of just seeing each other every day in the office when you're remote.

So some of the best practices I've heard about in helping your team kind of feel like a team when you have a remote team, obviously if you can get people physically together for a few days every quarter or twice a year or whatever, that helps a lot.

Some teams I know do something that they call like afternoon tea, where everybody just turns on Zoom or whatever video chat thing that they use.

And they all get tea or Coke or coffee or whatever they like and sit around and talk about not work for half an hour.

And whoever, you know, wants to stop by and just like hang out an afternoon, it's a chance to like see people and have a specific kind of ritual that would be like talking at the water cooler at the coffee pot at work.

So those are, those are pretty important ways of just like kind of building that camaraderie and team, team culture, even when you have a remote team.

Like I know a few companies that are basically like you have to, you can be remote, but you have to be within like these 4 time zones basically.

Because otherwise we have no overlap and it's really hard.

Because you don't want to force someone to stay up till 2am.

So now like if we expand to the first year, of becoming a manager, what are the, the big, super common mistakes that a rookie manager often makes but can avoid?

So the big mistakes that a rookie manager often makes and can avoid, I mean, okay, so 1 of the big mistakes that I see that's hard to avoid and has a little nuance, but new managers tend to default to writing code to solve their problems.

So new managers who used to be ICs, they look at a team and they look at a team that's struggling and the thing that they want to do is be like, I can just take some of these tickets, I can take some of these features, I'll bang it out over the weekend, I'll bang it out tonight, I'll get us back on track, no problem, And that very rarely works well.

Usually, if your team is struggling to ship or they're, you know, they've got a tight deadline that they're not meeting, the right thing for you to do is not to jump in there and add more code, but is to figure out what went wrong in your planning that got you to this point, is to figure out how you can unblock them in other ways.

How can you get design to get them assets faster or whatever, how can you work with the product team to downscope what needs to be delivered instead of just jumping in and writing code.

Because it is very difficult to switch between the really deep focus work of writing code and the kind of broader focus work of making sure that a team is delivering well and executing well.

And that is definitely 1 of the very, very common rookie mistakes I see new managers make that you can't avoid.

Now, I always want to be a little careful because I do think that it's okay for new managers of small teams to stay somewhat hands-on in the first few years.

There's different technical skills needed at different levels of management.

But if you're managing 5 or 6 people, especially if they're fairly mature people that you don't really need to like handhold through a lot of stuff.

Staying in the code a little bit just so that you kind of know what's going on can be helpful.

So I always want to be a little careful with that advice because I don't want people to think that I'm saying never, ever, ever write code.

But at the same time, if you're in a problem situation and your default is I'm going to code my way out

Other mistakes that I see rookie managers make, I mean, a big mistake that I see rookie managers make is like just not dealing with interpersonal issues on their team proactively.

If 2 people are not getting along and you just let that sit and fester, it's just, it's just going to cause you problems.

There's, you can't just be like, well, I'm just going to have them work on completely different things and you know, we'll be fine Yeah, you've got to figure out some way of dealing with it Whether it's move the person 1 of the people to a different team Whether it's talk it out with them and try to figure out the root of it and remove whatever that is, whether it's, you know, there's a lot of different approaches, you know, whether it's fire 1 of them, sometimes that's the right thing to do.

But you, it is your job to address those interpersonal issues between people on your team, And that is something I think a lot of new rookie managers are very uncomfortable with.

They're uncomfortable with having those just unpleasant and kind of like gray area conversations where maybe it's not clear that 1 of the 2 people is wrong.

Maybe they're both a little bit wrong, and you've got to figure out how to tell each of them, you need to flex a little bit more on this thing, and you need to stop doing that thing that's driving that person crazy.

And so practicing, I would say, rookie managers often avoid having hard conversations.

And so when you see yourself in a situation where you do need to have a hard conversation, just practicing the muscle of getting comfortable having those conversations is pretty important.

Yeah, that was 1 of the things I really enjoyed about the book, where you basically put a name on all these different personality types, you know, like the people who are like working in private and then they show up all of a sudden with like all this code and like a million other types all the way to the point of these are the people that are end up being like toxic for your company.

So In terms of like firing, as far as I understand, it's like 1 of the hardest things for an average manager, manager in general, but new manager in particular.

What are, what are the signs that a new manager should be looking for?

It's like, you know what, I might actually have to step up and do this.

So like, first of all, let's go through the obvious ones.

Stealing from the company, lying, harassing their colleagues, screaming at people like that stuff is just, it's not okay.

I know while management might be sort of regaining a little bit of popularity in tech, HR still seems to be kind of less, let's see, less popular.

But there are important things that HR knows about that are legally important for you to be aware of.

So the harder ones are someone who's just not producing, and then someone who is a drain on the team and very negative on the team, but isn't like actively harassing people or, you know, something where it's just super, very obviously over

Not producing is still hard because I think often we really want to make excuses for people and say, like, well, they're on this really hard project.

That kind of situation is where, if you have an HR team, they'll help you come up with a performance improvement plan, a PIP.

And you don't have to have an HR team to do this.

That's really just, you have to sit down and think to yourself, what would I need to see from this person over the next 90 days, 30 days, whatever makes sense, to know that they are able to produce at the level that we need them to be able to produce?

Whether it's finish this project, submit this many features without bugs or with minimal bugs.

And getting specific is hard, and it often feels a little scary, I think, for managers, right?

Getting specific about, like, these are the things that you absolutely have to do to not get fired is kind of terrifying, but it is pretty important to get as specific as you can on that side.

On the personal, interpersonal interaction side, I think is a little harder.

Because I do think that there are sometimes when you shouldn't pip someone, you should just say, you know what, this is just not working out and we just need to part ways.

And I think that people who clearly are just unhappy, that they clearly don't want to be there, they're super negative about everything.

You've talked to them in the past and said, hey, can you be more positive?

And they just don't take the feedback that they're draining the team.

And you kind of see them just draining the productivity of the team.

Those are the people that a pip just does not always make sense, right?

When your PIP is like change your personality.

I just, I think that's, that's kind of a hard thing to ask of someone.

You can, I've seen, so I will say that I have never, I I've always said this, but I'm always surprised when I do it and I watch it happen, which is like when you have someone on a team, who's just clearly a big negative drain, move them, you know, moving to them, to another team, another area, or, or moving them out of the company.

Even if you don't have Like, even if they're very productive or you think of them as like very smart and very productive, the impact, the positive impact on the team, when you get rid of that negative energy is always shocking to me because it's always more than you think it's going to be.

Like the team is always so much happier and healthier and therefore more productive once they get rid of those kind of like super dragged down individuals.

In a way that to this day, like I've, and I've done this a bunch of times and I'm still always a little bit surprised.

It's like, wow, gosh, just a negative person on a team can really drag a whole team down.

To step back a little bit, you were talking about becoming a manager and still wanting to write code.

I know a lot of people who have made that transition really struggle.

I mean, I would say like the first 2 years that I was a hands-off manager, I felt, the thing is, part of it is that you feel guilty.

Like I actually think a lot of it is just that you have this guilt that you're like not productive, right?

Because if you have been a really good productive engineer for a number of years, you are just used to that dopamine hit of like, I committed some code, the tests passed, it's in production.

Like I, you know, I see myself burning down the tickets.

I see these fast feedback loops and management is slow, slow feedback loops.

And so I think that, like I do think some of it is like you've just kind of pushed through that feeling of you're not being productive.

You're doing something you're not as good at also.

So it's going to take you a while to get that mastery that you probably have with code.

Now, if after 6 months or a year, you've given it your all and tried to get better and you're still hating it, don't force yourself to be a manager.

Like, I think the industry has done a really good job over the last 10, 20 years of good companies try very hard not to force good engineers to be managers, to continue to get promoted.

most companies that I see that I would consider it to be quality companies, they have separate tracks that do not require Like you managing a lot of people or any people at all to become a very senior person, a very well-paid, you have a career.

I actually, you know, these days I'm always thrilled when I find someone who is like a really good engineer who said they wanted to manage and maybe they did start managing a little bit.

is great because like there are so few really great seasoned, experienced engineers who are comfortable not having to manage a whole, they're comfortable with like leading through influence instead of having the actual authority of managing people and they kind of know what to do around big projects.

I just, you know, that skill set is so rare.

So do you have an opinion on side projects to scratch that itch?

I mean, like, I think both, I both think side projects are great and that you shouldn't feel like you have to have side projects.

You know, if you're a side projects person, you were probably already a side projects person before you became a manager, and so you'll probably continue to be 1.

I actually have not really mostly been a side projects person.

I kind of like working on and thinking about things that I feel like are really directly relevant to like kind of immediate goals in front of me.

I would say the downside of side projects, especially, so look, I do platform engineering, infrastructure engineering, big distributed systems.

Knowing a little bit of Go or having spun up Kubernetes on a test cluster at home is not nearly enough to have an informed good opinion about a new language or like a new system.

Like you have to run those systems in production, in anger and get cut and burnt and, you know, hurt by them, to really understand them.

And so I would say the 1 risk of side projects is that sometimes when I see leaders who are really obsessed with their side projects, they're always kind of trying to tell their engineers like, Oh, like I know better and this is like totally easy.

I played around with this and I think this is super cool.

Like, that's not the thing that you've actually spent 40 hours a week for the last few years, like really focused on and you don't really know what you're talking about.

So you want to be a little careful about letting your side project teach you things that it's not actually teaching you.

It can also, it can change people in the way that they always feel like they have to jump from the new coolest thing to the new coolest thing.

When in reality, they have no experience scaling that thing.

So I think another common thing that new managers feel is just being overwhelmed.

And so as a new manager, when you're feeling like this is so much, like, I don't know what to do, what, what do you tell that person?

So, I mean, I, what, 1 of the things I tell them is like, welcome to management, you know, because I actually feel like management is being overwhelmed a little bit.

Like management is, especially at a startup, is sort of having more things going on than you can possibly know all the details of.

And you have to get comfortable making decisions without knowing all of the details of things.

So some of the things I tell people are like, you know, first of all, like, what could you just stop doing?

And maybe it will fail, but it's just not that important, and so whatever, right?

You know, What is something that you are just stressing out about that's just like, is this really a thing for you to even be worrying about?

Can you give it to someone else to do who may not do as good a job as you would, but it will get done, they'll learn something, and you will get some time back.

I'm learning how to delegate is definitely a huge part of that.

You know, what are you holding to, to highest standard that just isn't.

Important enough to hold to that highest standard.

See all Y Combinator transcripts on Youtube

Camille Fournier on Managing Technical Teams