SPEAKERS

Bill Coughran Founder's Coach & Partner @ Sequoia Capital; Former SVP Engineering @ Google

Bill Coughran works as a founders' coach and partner at Sequoia Capital to help build spectacular technology-centric companies. Previously, Bill was Senior Vice President of Engineering at Google with oversight of Chrome, YouTube, maps, google.com, underlying infrastructure systems, and security.

"As startups evolve into growth companies and eventually into public companies... you have to figure out how to transition from the heroes who helped start the company and who carried a lot of the burden...

They can sometimes become single points of failure in the organization. And you have to figure out how to change wonderful individual contributors into teams in critical parts of the organization. Those are all things you have to be able to work through."

<cite>- Bill Coughran </cite>

David Singleton, CTO @ Stripe

David Singleton is Stripe’s Chief Technology Officer.

He joined Stripe from Google, where he was VP of Engineering, leading the Android Wear and Google Fit teams, which included product development and coordinating more than 15 different hardware partnerships. Over the course of his 11-year career at Google, David led teams that built some of the company’s most ambitious products, including its first apps with voice search; publisher products for Google Adsense; Google Offers; and Google Mobile Search Apps. He was also one of the first engineers at Google London and oversaw much of the growth of the London engineering office from inception to the large scale it has today.

Prior to Google, David spent three years as a senior engineer at Symbian, the pioneering mobile phone operating system. At Symbian, he developed software for Nokia and Samsung smartphones and worked on both the Bluetooth stack and PC Connect software.

David has a bachelor’s degree in Computer Science from St. John’s College at the University of Cambridge. In his spare time, he enjoys cooking, skiing, and tinkering with neural networks. He lives in San Francisco with his wife and two kids.

This Episode Is Brought To You By

Jellyfish

Jellyfish helps you align engineering work with business priorities and enables you to make better strategic decisions. Learn more at Jellyfish.co/elc

Listen to our Bonus Episode with Guillermo Fisher, Director of Engineering, Infrastructure @ Handshake

A great conversation covering Guillermo's leadership story, impact of internal mobility, making mission-driven decisions, & self-service infrastructure! Check it out HERE

Special thanks to our exclusive accessibility partner Mesmer!

Mesmer's AI-bots automate mobile app accessibility testing to ensure your app is always accessible to everybody.

To jump start your accessibility and inclusion initiative, visit mesmerhq.com/ELC

Show Notes

• What are the most common mistakes scaling organizations make? (2:24)
• What's the best way to add managers to a technology organization? (4:40)
• Signals to identify potential engineering managers to develop from inside the organization (7:32)
• Finding the right external hires while in hyper-growth (signals & warning signs) (8:41)
• What questions do you ask for hiring references? (11:23)
• Navigating doing things that don’t scale in the short term (16:17)
• “Second system syndrome” & avoiding the urge to rewrite your system (19:12)
• How to retain early employees at a hyper-growth startup (21:30)
• What Bill’s most excited about in the tech industry right now (24:18)
• Tips to help turn ICs into leaders (25:20)
• Deciding on org structure when you’re scaling fast (27:26)
• Navigating speed & long-term quality building your architecture at an early-stage company (29:43)
• Final advice from Bill & David (31:37)

Transcript

What are the most common mistakes scaling organizations make?

Patrick Gallagher: Welcome Bill and David. Thank you both so much for joining us.

David Singleton: Thanks Patrick! Thanks for having us.

Bill Coughran: Thank you, Patrick.

David Singleton: And Bill it's, it's a real privilege to be here with you today. I've also had the privilege of working directly with Bill at Google and then also benefiting from a lot of your time advice and mentorship as I've been growing at Stripe. So thank you for that. I'm pretty excited that we get an opportunity for you to share some of your insight with everyone here at the conference today.

So I guess the topic is about you've reached product market fit and it's time to actually scale the team. And I'm sure that this is a position that a lot of folks who are here today are in. I think that it's always interesting in a, in a scenario like that to... you know, find your network and have the ability to learn from the experience experiences of others.

And Bill I know you've advised a lot of founders around Silicon Valley and elsewhere. So hopefully we can learn from some of of those experiences today.

You've overseen hyper growth of teams directly at Google. And then of course, many of the companies that you advise and spend time with are the fastest growing companies in the world. What would you say are the most common mistakes that you see scaling organizations making?

Bill Coughran: Yeah, there's lots of ways scaling could go wrong. A lot of founders think that once you found product market fit, it's easy after that. I think it actually gets harder.

Some of the things that happen are as your organizations get larger, the sort of chaos management and the self-organizing teams and so forth doesn't work as well. You have to build more structure and you have to build more processes. You have to figure out how to inject leadership into the organization and add structure in that regard.

And I think the other thing, for me, is as startups evolve into growth companies and eventually into public companies... you have to figure out how to transition from the heroes who helped start the company and who carried a lot of the burden... can sometimes become single points of failure in the organization. And you have to figure out how to change you know, wonderful individual contributors into teams in critical parts of the organization. Those are all things you have to be able to work through.

What's the best way to add managers to a technology organization?

David Singleton: Thinking about adding structure... When I talked to a lot of growth founders, I think of growth as kind of, you've hit that spot where it's time to scale. I feel like they often want to maintain a flat structure to keep that kind of scrappy startup culture alive. And I think... you've probably experienced this directly... I remember hearing an anecdote that at some point at Google, you had over a hundred direct reports personally.

First of all, Wow! How on earth did you do that? Maybe there's some fun stories or things that you learned from that you could share.

But more broadly, what is the best way to add managers to a technology organization? Can you preserve this scrappy startup feeling that ideas can come from anywhere?

Bill Coughran: Good question. Very good question, David.

So yes, I did early on at Google in the, in the days before and, and during the period of the IPO have a very large number of reports. It was over a hundred. I'll try to avoid mentioning the actual number. It's a little scary. I would certainly not recommend that to anyone.

I think what I see with a lot of startups is they worry that management slows things down. And they worry that managers want to "add value" if I can use that term... and get involved in every decision, which makes them a bottleneck on make making decisions.

So I think to me, a lot of the best practices to allow companies to scale from that point of view is make sure... and I think Apple first coined this phrase... having directly responsible individuals, who are often technical people, who are responsible for particular projects, particular systems, particular feature developments. They may or may not be managers. But you want to ensure you press the decision-making down as low as you can in the organization.

And then for me, the best managers as you start introducing managers and adding more management structure in a company... you want to add people who are technical. And you know, I think being an effective manager, you need, you need some people skills and you need some technical skills.

So I have been, for instance, I was at Bell Labs for many years where a lot of the managers were some of the best technical people. Purely technical people don't always make the best managers. So you need people who are a blend.

But in high-performing engineering cultures, you need to make sure that the managers, that you introduce are respected.

And so best practice for me is to try to promote people from within that are part of the organization, are well-regarded in the organization. And, and bring them up and mentor them into effective leaders. But you still have to also recruit people from the outside.

Signals to identify potential engineering managers to develop from inside the organization

David Singleton: When you're thinking about developing folks from inside, what do you actually look out for?

You know, everyone maybe is a brilliant technical person, but how do you spot what's going to make a good manager in those folks?

Bill Coughran: I think for me, people that make good managers are people who know how to listen. I've occasionally run into people who want to be... they don't want to be leaders, they don't want to be managers. They want to be the boss. And they want to be able to tell other people what to do.

I actually I think the best forms of leadership is what people often call servant leadership, where you're trying to get the best out of the people that you're working with. And you're trying to give them the most latitudes.

So you want manager, you want managers you introduce certain people you promote into management to be good listeners, be comfortable with different styles. A lot of people have different communication styles. And in a lot of engineering organizations, many of the engineers are introverted. And so you have to you have to have some degree of emotional intelligence and be able to intuit some the, you know, some behavior and state of mind on the part of employees.

Finding the right external hires while in hyper-growth (signals & warning signs)

David Singleton: Cool. So good listeners make good managers. You also mentioned hiring managers and technical leaders from outside of a fast-growing company. And I guess that's inevitable because it's the only way to grow quickly is to bring people in from outside.

But what tips would you have for hiring in hypergrowth, technical organizations? How much time should everyone be spending on that? And how do you spot the folks that are going to be the right hires?

Bill Coughran: Yeah, it's interesting. I, as I said earlier, I, I like to... when I've done this myself, I prefer to promote from within. But it's also the case... I've been known to joke with people that it takes a year to get a year of experience.

If you need somebody if you're a young company and you had people managing groups of 10 or 20. And now suddenly you need to have people who can manage groups of a hundred, 200 or larger, you probably end up recruiting people from the outside who have some experience working with larger groups because there's different needs.

Often those people are managing leaders who themselves are leaders of other groups. And so they have to be comfortable working through a management layer rather than directly with engineers and so forth.

And so for me, when you're recruiting people from the outside, a lot of it is hearing about their previous experiences. I like to hear about where they failed. Because I often find out more about people who learned something during the, during a failure period. I've certainly learned most of my lessons during those.

And I look for warning signs. One of the things I learned a long time ago, if you're interviewing somebody for a leadership position and they talk about, "I did this and I did that" and so forth...

It indicates that they don't really realize that the projects that were done, you know, with their help were really done by a team. And they w they may have helped. But they, they didn't drive It.

I was affiliated with a lot of the major projects at Google during the time I was there. You know, in some ways I was a coordinator and an advocate for what they were doing. Not, I didn't do the actual work. And I try to be very careful not to claim credit for it.

And then referencing, you got to reference candidates. People who are experienced managers, when you're recruiting them, they often know how to be, how to talk in interviews and how to respond to interviews. You need to find people who've worked with them, worked for them, or that they reported to and get feedback on them.

What questions do you ask for hiring references?

David Singleton: When you're referencing, what kind of questions do you ask? I mean, I'm sure probably many of us have done the reference call where they're like "This person's the best person I've ever worked with!"

And you know, you need to dig under that somehow. Tell me how you do those reference calls to really learn what's going on.

Bill Coughran: Yeah, it's interesting. It's, hard, right? Because I think people are often very cautious about how they do references.

I remember years ago... I've also been a professor off and on a few times... I remember writing a tenure letter for some supporting a tenure case at a major university. But I added a couple paragraphs where I thought that the assistant professor could do a little better. And the department chair turned around and handed the letter to the candidate, and exposed my concern. Which was fine, but it didn't help the personal relationship.

I guess what I normally do on a reference call is, I try to ask about a specific project. Try to get a sense of how involved the person was with a particular project. I try to find out if they dealt with performance problems on the team and how they dealt with it, how they were perceived, were they effective at managing performance? And then I usually ask... you know, none of us are perfect and we all have failings of different kinds... I usually will press for and a suggestion of an area of improvement and if I get the "this person's perfect" That's actually a big warning sign for me.

David Singleton: Yeah. I take that tactic as well. And I mean, honestly, if someone can't offer an area for development, I'm just like, "okay, well that's just not signal. Let's go talk to someone else."

Bill Coughran:

Correct. Yeah. I agree with that very much.

Navigating doing things that don't scale in the short term

David Singleton: Bill, changing gears a little bit... we talked a bit about, you know, building the team and people thinking about technology systems, something that I think certainly I've seen including at my time at Google was in the early days, it makes sense to do things that don't scale to, to, to just do whatever it takes to find product market fit.

But as soon as growth kicks in all of those shortcuts that you've taken come back to bite you very quick. And I, I think it means approximately everything needs to be rewritten or redesigned from the ground up at some point. Did you see that at Google? And either from your Google experience or elsewhere, how can folks here today, think about how to navigate that for their own orgs?

Bill Coughran: Yeah, I think Google, certainly during the period I was there, we rearchitected things and rebuild things with some frequency. I think a lot of people have probably seen or heard of the Google file system "paper" But there were, you know, at least two or three other systems that came after that. Each one higher performance capable of doing a broader set of tasks and so forth.

And so they, I would say, depending on your needs, there are reasons to rearchitect. And one very common thing I see with a lot of startups that I work with as part of Sequoia Capital, usually in the early days of a company, as it's finding product-market fit, you cut a lot of corners. You create a lot of technical debt, you abandoned code paths and so forth. But you leave them in the codebase. And you often have a monolith that delivers the product to the web or to mobile or whatever.

And what I've seen at a number of the companies that I've helped advise, is they often end up rebuilding things in some sort of a service-oriented architecture, microservices architecture, where they try to get the possibility of, kind of, " independent release cycles" for different pieces in their product.

And those are major projects. They require rethinking APIs between components in your system. They may require rethinking APIs to your end customer and almost every company I've worked with... and we certainly did this at Google... we went through major re-engineering efforts and it's part of what you have to do.

The challenge though, for me, is most of the more creative and high-profile engineers like to build new things. So you have this desire to always rewrite systems and redo things. And so you need to have a pretty balanced view about what can you do with refactoring and cleaning things up as opposed to going off and writing, writing another system.

Because I think all of us probably have heard of the "second-system syndrome." And I have seen that many, many times in different companies.

“Second-system syndrome” & avoiding the urge to rewrite your system

David Singleton: Right, so when an engineering DRI comes along and tells you, "Hey Bill, we're going to rewrite this thing and it's gonna be so much better." How do you help them avoid the second system syndrome and actually, you know, deliver something that's going to make an impact.

Bill Coughran: Yeah, I think there has to be a clear understanding of why there is a need to rewrite this system.

So for example, things that are fairly common that happen often is you may have a transactional data system that, that has a natural scaling limit. You know, the CPUs start running hot or, you know, the memory exhaustion starts to set in and you're near a cliff and you have to think about some other system or some other model.

If you have a clear business need, you need to identify it upfront. So that you're not just building against a, "we want to do this" kind of a model.

I think the other thing that I've tried to do with the people I've worked with is for a number of years, I was part of the group at Bell Labs that's best known for creating Unix and C and C++ and so forth. And one of the things I learned there was: Systems simplicity is actually a feature.

And so one of the things I've always tried to do, I tried to do a Google was insist on thinking about what is the simplest thing and the simplest API you can develop. And then write down you know, clear specification of what you're going to try to build.

And then the last thing I normally do is try to get a fairly concrete set of goals with timing. Cause I've had the experience myself and I've seen it a handful of other companies where you have a very good set of engineers that say, "We're going to build this wonderful thing. Leave us alone for a year and we'll come back with something interesting" that's very dangerous.

And so I don't think you can manage those kinds of projects week by week, but you need some way to measure consistent progress against the plan.

David Singleton: Those are great tips. Thank you very much. I think that the interim milestones to make sure that you're actually delivering something, hopefully, maybe all the way out to production that demonstrates is making progress is, has been pretty important for me.

How to retain early employees at a hyper-growth startup

David Singleton: Thinking a little bit more about early-stage companies... I think, you know, early employees do a lot, they wear a lot of different hats. They are responsible for building, you know, everything across the company.

I think one thing is kind of cool at Google is a lot of those folks were retained for a very long time. But as you start to grow and hire, how have you seen the ability to, kind of, help those folks feel part of the org and part of the future destiny? Even as a lot of people come in and take over stuff that they were previously responsible for?

Bill Coughran: Yeah, it's interesting. My experience at Google was there were a number of early employees who became... that kind of grew with the company and their scope and what they were responsible for grew.

I think, and I've seen this at other companies as they've matured and grown into larger companies and... and you want to give those people chances to stretch themselves. You want to put them in roles that are probably a little bit too big. Make sure they have some contact with mentors to help them develop and so forth.

But you want to encourage that as much as possible because they know how to get stuff done. They're looked up to and respected and they carry the culture.

Having said that, there are other early employees that you know, they liked being part of a smaller company. They don't like being, you know, they don't like the fact that the company they joined is not the same company.

Their skills may top out at a certain, you know, scope and scale range and they need you know, they, they may want bigger and bigger jobs, but it may not be the right thing for them. And so you have to make some pretty hard judgments.

And one of the things I've seen with founders of a number of companies is they're often the early employee group is very bonded together because they're in a sort of crucible, created something that's now working and you're growing it.

And founders are often very loyal to those early employees, but sometimes it's natural and it's time for those people to move out and do something new. Maybe they start a company of their own or join another smaller company. But that's often a very emotional decision both for the early employees and for the founders.

And then the other thing, which I think is a challenge for leaders, and certainly it was a challenge for me, and I suspect a number of people in the audiences... Often the early employees are right in the center of the web and they know how to get stuff done and they control kind of all the...you know, ... they're in charge of the most important things and so forth.

And sometimes those people have trouble letting go. And so helping them bring in new people and kind of let other people into the center of the web is pretty critical. And some people can do that and some people can't.

What Bill’s most excited about in the tech industry right now

David Singleton: Cool. Thanks for sharing. So we're going to cut over to audience Q and A in just a second, but before we do...

2020 I think it's been a pretty tough year for, well... essentially everybody. I'm sure as you're advising folks, you probably ended up mostly working through problems with them. But Bill, what are you most excited about in the tech industry right now?

Bill Coughran: I think there's lots of interesting things happening.

They, you know, I think one of the things that is good for the tech industry is, I think it's accelerated a bunch of changes.

We're seeing acceleration towards the use of public clouds instead of building your own infrastructure. I think there's just a lot more places that software and automation is showing up. see fascinating things happening in robotics, quantum computing, they're all kinds of things. But even in kind of straight software businesses, I just see more and more applications developing.

David Singleton: Cool. Well, let's cut over for some quick audience Q and A. Before we wrap up here.

Tips to help turn ICs into leaders

Patrick Gallagher: Bill, David, thank you so much for such an incredible conversation. I mean, there are so many comments coming in that just really appreciate and value the precision and depth that you two have gone into this, this topic. So there are quite an extensive amount of questions. So I'm gonna do my best to try to consolidate a few of them together.

And so since you've all talked about people in systems, I wanted to first talk about a question related to people. And so in this one, in, in scaling and growing your organization, people are a big function of that.

What tips do you have for turning maybe followers or people that don't see themselves as leaders or potential managers? What tips would you have for turning them into leaders?

Bill Coughran: I'll give it a go, but I bet David has a good answer too.

I think one of the things that... you see this often where somebody who's a very good individual contributor is ... and as an engineer, doesn't see being a leader or a manager being valuable.

And I think one of the ways I've been able to convince a number of people that they could actually be more valuable as a leader is... you get leverage. If you're a leader of a group of 10, you can help shape much larger projects than you can as an individual. And to me, that's the fulcrum under which this turns. And David, I don't know if you have a different opinion.

David Singleton: Yeah, I think one of the things you mentioned, servant leadership while we were talking. I agree that so many of those concepts are important and having good managers who will actually help enable impact from people.

But I, sometimes see that overused. Where folks can feel like, because they hear a lot about that. That their job is just to facilitate others. And actually, I think, you know, really good leaders have a very strong sense of what they are responsible for. And while it's facilitating the work of the whole team, it is also about knowing what are objectively good results. And you need to know when to push. You need to know when to say "no, we don't actually have the goals quite right. Let's restate what we're really trying to do and push towards execution."

And actually knowing that that second part is a kind of expectation and a tool in your aresenal is, pretty important I find.

Deciding on org structure when you're scaling fast

Patrick Gallagher: So this next one is related to systems. So when you're growing quickly, is there a playbook or a framework in which you would recommend to decide on org structure? So navigating, deciding between product versus matrix for, for instance, is there anything that you would recommend when you're scaling fast to have to start to think about the org structure as you get to that next level?

Bill Coughran: My first comment is I think sometimes people get overly fixed on org charts. My sense is that organizations are much more fluid and there are usually are things that are not by the book in an organization.

The rule of thumb I use is... I think if you're working in a company where the engineers do not... are not necessarily the consumers of the product they're working on, you probably want a product management function that represents the kind of voice of the customer. And then I would think of a separate product management and an engineering function. Or having one or the other at the top of the pyramid.

And it's kind of a coin flip in my mind about which way you go. The other issue on the org chart in engineering is what's the fan out. You know, David was teasing me for having more than a hundred reports at one time. But some of those reports were people like Rob Pike or Jeff Dean or people like that, that were probably... didn't really need a manager.

So I think part of the fan out question is how experienced, how junior, or how senior are the management groups that you have. You can get away with larger fan out if you have more experienced people. If you have a lot of junior people, they probably need more feedback and support. You need less fan.

David Singleton: Thank you,

Patrick Gallagher: David, do you have any comments?

David Singleton: Yeah, I mean, to build on that... all of that like completely agree with, but there's also Conway's Law, which is essentially "You're going to ship your org chart if you're not careful."

Well, actually I just lean into that! Make sure that you're organized so that the way that you want your customers, your users to perceive your product, is actually how the teams are themselves set up. And that's actually very powerful because then you can give teams responsibility and autonomy for whole areas. And that lines up with how you want your customers to, you know, perceive things.

Navigating speed & long-term quality building your architecture at an early-stage company

Patrick Gallagher: I think that's a great comment that leads into one of the other questions that we have.

So one of the questions is about, do you think the way startups sometimes cut technical corners in the early stages is the best strategy? Or does there generally need to be more attention to long-term architecture from the beginning?

So I guess navigating the tension between speed and high-quality architecture... what is your decision-making process when navigating that problem?

Bill Coughran: Well being a venture capitalist these days, you know, usually the first funding round of a startup, you need to get to some indication that people like and want your product. At the end of that... whenever that money runs out, you better have a good story about why people want the product.

And so. Yeah, I think a lot, even though I don't like it as an engineer. I think the right answer is you need to do what you need to do. You need to be able to iterate fast and try new things. And if it clicks, you're off to the races and you can raise more money.

I mean, Google, for example, did a lot of work early on, on a search product. I think history shows it clicked. And then they were off to the races. And so, but early on you do cut corners. You need to iterate fast to get there.

David Singleton: Yeah, I agree. I mean, I think it's extremely... there's a vast litany of companies that had beautifully designed infrastructure and didn't actually, you know, find a market for what they were building. And the flip side.

But then the important thing is at such a time, as you have hit product markets, I find it important to actually have a very clear view at any given moment of where you need to get to in essentially the timeframe that is about double the amount of time you already existed. That's where you can have a fairly clear view.

And then when you are designing systems to be reimplemented or rewritten, it's important to actually know where you're trying to get them to. And that's worked pretty well.

Final advice from Bill & David

Patrick Gallagher: Wonderful. Well, thank you both. Those are all the time we have for Q and A questions, but I was hoping to open it up to both of you to, to close us off for today with any final thoughts or words of wisdom that maybe are on top of your mind related to this topic or otherwise.

And so, would you mind leaving us with any of your final thoughts for today?

Bill Coughran: Yeah, it's interesting. I think one of the things that happens, particularly if you're in a position where you're in a growing organization and leading a what is a larger and larger organization... the jobs get very lonely and they're very stressful.

And so one of the things for those of you in the audience that are going through that experience... I recommend you find a mentor or you find a peer that you can talk to because even if you're a fairly, you know, resolute and resilient person. I think it does put a lot of personal pressure on you.

And David mentioned 2020 may not be the best year in our lives. I think the combination of COVID and fires and elections and whatever other evil things lurk up, lurk in our future... puts a lot of personal stress on us. And I think you need to take care of yourself while you're trying to build your organization.

David Singleton: Yeah, I totally agree. An engineering leader at Stripe recently was talking to a bunch of our engineering managers and said, "Hey, don't be afraid to put on your own oxygen mask first."

You know, there's a lot going on and take a break, go for a walk. It really is the case that these can be lonely jobs. And I think Bill's advice is wonderful.

Bill Coughran: Thank you very much for the opportunity.

Patrick Gallagher: Thank you both so much for your time and for your insights. Just the comments and the chat section are overwhelming gratitude for the insights and support that you've provided.

So thank you both so much.