To Be Continuous: Organizational Scaling
In this episode, Edith and Paul discuss the steps that a startup can take for successful organizational scaling. They bring up important questions including: What roles should your team members play as your company grows? How do you prioritize resources? Is Paul a good coder? This is episode #26 in the To Be Continuous podcast series all about continuous delivery and software development.
This episode of To Be Continuous, brought to you by Heavybit. To learn more about Heavybit, visit heavybit.com. While you’re there, check out their library, home to great educational talks from other developer company founders and industry leaders.
Paul Biggar: This week we’re talking about scaling.
Edith Harbaugh: We started to talk about this last week. We talked about specialization versus scaling.
Paul: Versus generalization?
Paul: Specifically, the scaling that we’re talking about is organizational scaling, rather than our team scaling prep, not infrastructure scaling.
Edith: Correct. Though, I think they go along.
I think there’s two big sins, which are premature scaling and waiting too late to scale. And they kind of go hand in hand.
Paul: Right. Yeah, you can say the same for organizations as well.
Edith: I think I’ve seen the mistake of startups that have raised a lot of money and have acted like they already made it.
Paul: Was it you that wrote a scathing blog post about Lasers? No, Famo.us!
Paul: Famo.us, yeah.
Edith: It wasn’t scathing. It was meant to be kind. But basically, you can have hubris when you raise $20-30 million and think that you have already made it.
Paul:I remember meeting their head-of-something at a Heavybit function, and they hadn’t released their product yet. They had a Head of Marketing or something, and I was like, “You did not make the product before you built the team that does the marketing for the product.”
Edith: I’d say, actually, I think you should build your marketing and product together, because they go hand in hand.
Paul:It was like a VP-level sort of thing. So I would say don’t hire VP levels for your seed-stage stuff.
Edith: I’d say hire a VP-level person if they can also do individual-level work.
Paul:We should step back a little bit.The thing I think that we’re talking about is, when you’re starting a new team or a new company, you’re in the range of two-to-five people. And the steps, the things and the activities, and all the stuff that you do at two-to-five people, should be suitable for, I’m going to say, getting product-market fit on that.
Edith: When you’re two-to-five people, you’re constantly iterating on, “What is our product? What is our market?” And that’s why I say it’s good to have a marketing person.
Paul: Because we talk about this all the time. And so what we’re going to talk about this week is the next level. So you’re taking it from the five people to 21-to-20 people, at the next level of scale, and what’s involved in that.
Edith: Well, I’ll be honest, that my company has eight people.So I don’t know how qualified I am to participate in this podcast.
Paul: You’ve done this before in various organizations, I think, or been part of various organization that go in that.
Edith: Yeah, of course.
Paul: I’ve only been part of very large organizations and one organization that scaled. And then I have the collective wisdom of many, many startup-founder commiserations, “Here’s how we fucked up,” and “Oh my god, you should see the problems that we went through when we were scaling.”
Edith: What are some of the common mistakes that you’ve seen?
Paul: Well, not scaling early enough. In particular, organizations outside of engineering. It’s very common to have engineer founders hire more engineers. And in particular, to not build the product org. That, I feel, is a mistake people keep making.
Edith: Why do you think that is?
Paul: I think engineers have a world view that is influenced by open source. Very, very strongly influenced by open source. Open source, for the most part, is engineers building and engineers PM-ing a sort of unified function. I would say that the PM function is also very restricted in open source.
The things that you build are the things that scratch your itch, and any pull requests that come your way. It’s a real lead-with-code sort of thing, and I actually think that that’s completely unsuitable for open-source products, but it’s particularly unsuitable for startups or any products.
Edith: I think the critique is that it’s reactive, and some might say, Linus Torvalds, that the reason why some people think that he’s a jerk is that he’s like, “I don’t want to take every pull request. I have a vision and I’m trying to make sure that the only thing I accept is the things that fit the vision.” But what ends up happening then is you end up rejecting people extremely late in the process.
Paul: Exactly. This is the problem with open source.I made a contribution to something the other day, and before I made a contribution I made an issue saying, “If I made this, would you accept it?” Crickets.
And so then I built it and made a pull request, and there’s still crickets.It’s been like four days, which, I don’t know, maybe that’s a bit quick, but you kind of expect an answer in four days.
Edith: I think it goes along with the value of product management, in some ways, validating that there’s a need or a market for something before you do the work to build in it.
Whereas open source has it backwards, where people go off and build their code and then get their noses, rightfully, a little bit out of joint.
Edith: But, it’s like, “I did all this work!”
Paul: This is a problem that I had at Circle, that I wasn’t very good at articulating what our direction was and what the product vision was. And so people would routinely build stuff, where I stuck my nose in like literally at the last minute and said, “We can’t ship this, because it doesn’t fit within the product vision.”
Edith: And that’s heartbreaking for everybody.
Paul: Oh god, yeah. That was the worst thing. If I would run a company again? Advice for people managing this transition of the new startup: the most important thing is to set out your company mission, your company vision, your culture and your product vision.
You want to really establish who you are, what you want to be, where you want to go, what you want to do as a collective unit, so that everyone is on the same page about that.
That solves all sorts of problem. When you’re hiring someone, it’s like, “Does this person agree with the vision? Are they part of the mission? Is that a mission that they agree with?” And the same thing at the company level, and also the product level.
If someone joins your company and wants to take the product in a radically different direction, then either they need to change their mind, or you need to change your mind. Otherwise you’re just going to be pulling opposite directions from each other.
Edith: Two examples. You put your finger on why I became a product manager. I was an engineer and I was tired of building stuff that the product managers would just reject after it’s built. It was extremely painful, from us who’d built it. And I was like, “We need to stop doing this. This is not what I want to do anymore. If I’m a product manager, this won’t happen.”
And of course it still happens, but you understand why, and you have more empathy, and you try to fix it. You inadvertently build an organization that reflects your own mission, or lack of mission.
Paul: You want to say more about that?
Edith: I’ve heard that GitHub has gone through a lot of strife right now because they had built a company that was very much out of bottom-up: “We sell to individual developers.” And now they’re trying to get more enterprise-y for very obvious reasons. That’s why there’s a lot more money. And a lot of people are just like, “We can’t work here anymore.”
Paul: A specific about GitHub, I heard that they’ve gone through many different transitions of that size. But I guess every company goes through major transitions.In particular, there’s a saying in the Valley that, I forgot what exactly it is, but the people who are your heroes up front are not going to be the people who are there in your organization later.
Edith: Well, since it’s a classic, have you read “The Innovator’s Dilemma”?
Paul: I wish I had.
Edith: It’s a really good book. This is not new; this is a book from 20 years ago. But it’s talking about how the innovators are the prototypers, the people who are willing to wear a lot of different hats, who are willing to be wronged very quickly. And then you have a transition point to more lieutenants.
Paul: Right. That goes right into our last week’s discussion of generalization versus specialization.
Edith: Yeah, it’s not anything unique to software. It’s unique to any new thing.
Paul: The problem, then, with product managers when you bring them in, is often engineers feel that there’s a lack of autonomy that they’re getting out of it. They used to be the ones who were the decision makers about what to build, and all that sort of thing. And then there’s a feeling that the product managers are going to tell them what to build, and often that feeling is based on reality.
Edith: Like I said, I’ve been on both sides of this. I don’t have a clean answer. It really depends on your engineers. I have an engineer friend who says, “I have a lot of personal stuff going on right now, and I just want to be told what to do.”
Edith: He wants to be an engineer. Other people are like, “I think of myself as a product manager/engineer/marketing,” and you’re like, “Woah, okay. You’re none of these things very well right now.”
Paul: Right. People think that product managers are managers. Engineers, I think, often feel the product manager’s a manager so they’re people who tell them what to do.
Edith: Oh no.
Product managers are persuaders.
Paul: Exactly right. A good product manager is a persuader, exactly.
Edith: Well, a persuader or a facilitator, a consultant.
Paul: A researcher.
Edith: I think the greatest strength of a product manager is to knit together a group of people all with different ideas and make them collaborate on a common goal.
Paul: If your organization is entirely engineers at the start, I think the first thing you’re going to need when you’re scaling is to get the start of a product organization together. Someone who has the skillset and who has the experience to be a product manager, or who has been a product manager before and understands what a successful product organization looks like, is going to be a really good thing to get in, especially if they can work together with the engineers and not against them.
Edith: Yeah, I think that’s key.
If they think of themselves at odds, it will not succeed.
Paul: There’s a saying that the project manager’s like the CEO of their organization or of their sub product. I kind of feel that. I don’t think that that’s a very apt definition of what a good product manager does, but there’s a lot of people who feel that way.
Edith: It’s funny because, like I said, I was a product manager, and now I’m a CEO.
Paul: Right. But you wouldn’t have a product manager and give them CEO level. Well, I guess it depends on what you see as a CEO’s role. But a lot of the CEOs, and I include myself in this, work towards building by consensus and trying to get the direction the same. I don’t actually tell people what to do. But I think the traditional view of a CEO is someone who tells people what to do, and then is responsible when it all fails.
Edith: Yeah, I think I was fortunate that I was basically given a managerial role at my past companies, where I had responsibility for revenue. Not just for product, but revenue, how many sales were made, marketing. And it was very good for me to think that way, that you can tell people what to do, but if you talk to them and listen and come up with a sure path forward, things go better.
Paul: Right. Speaking of talking and listening, I think management is a good thing to talk about in the context of the scaling that we’re talking about. You should have managers. That’s a controversial thing.
Edith: It’s funny. I love talking to you, Paul, because I think I’ve talked to post-transition Paul.
Paul: I think you have. Yeah, pre-transition Paul had a different point of view.
Edith: I’ve heard rumors that, before, you were very much like, “We never need PMs. Everybody can self-manage.”
Paul: Right. Well, a little bit. But I think the position that I used to have is that everyone should be ICs of various kinds. In particular, I think it’s interesting, related to management, in that a traditional view of a manager, someone who is the manager of an engineering team, let’s say, often someone who is making technical decisions, who’s making architectural decisions, who’s hiring and firing and all that sort of thing, doing HR stuff, and also is responsible for the people stuff, the career development, the “How are you feeling today? Let me get you a glass of orange juice so that you can crank this code out.” And sometimes, on top of that, they also write code.
It occurred to me, I think it’s very obvious, in fact, that the idea that the best person on your team, who’s usually the person who gets promoted to engineer manager, do they also happen to have all these skills? They’re your best coder. Do they also have people skills and that sort of thing? So, instead, you need to break it out into different roles.
I think the people manager role is necessarily one that the organization needs. And then the product manager role is necessarily one that the team needs. And then, possibly, there’s some sort of architecture or technical decision-making sort of role. I think this is actually what modern companies look like.
The thing I found interesting before, pre-transition Paul would have said that you can have all this without hierarchy. And I think post-transition Paul is like, “Yeah, I suppose you could. But I haven’t seen it work.”
Edith: It’s interesting because Google did a big longitudinal study. They had a theory that the best engineering manager is the best technical person, because people need to respect their acumen. And then they did a lot of studies, and it turns out, of their own managers, that no, the people who had the best technical skills were sometimes the worst managers.
Paul: Right, I wouldn’t be surprised.
Edith: Well, you’re not surprised. Butit was a surprise for them.
Paul: I had a surprise around product management. I’ll relate this back. My surprise was that not all engineers can do product management. And when I say product management, let’s say, can have good product vision and insights. And I was surprised because I thought, inherently, that’s a part of building a product. Or at least, inherently, what was part of being an engineer.
And then I thought back. I was like, “Well actually, we’ve never been trained in building products. We’ve never been trained in product vision.” What we’ve been taught to do, at least if you go to computer science courses or whatever, is you’re taught to write code and sometimes think about formal methods. But, generally, you’re there to write code.
People who are engineers have 10 years of experience of writing code, and not necessarily, although sometimes, there are very talented product-vision people in there as well. And they go nicely hand in hand, but very often are missing.
The assumption that I had had was, “Everyone’s going to be good at product vision.” And that assumption was flawed, and I think it’s the same thing that, maybe, Google had made that. Maybe Larry and Sergey were particularly good at this, or some of the early people that they hired or the first people who got promoted into management or excellent technical people who thought, “Oh, excellent technical people are also obviously going to have excellent communication skills.” And I think you could make some sort of intransitive argument there that wouldn’t necessarily hold up too well.
Edith: You think everybody is like yourself.
Paul: You think everybody is like yourself or the examples that you can see in front of you.
Edith: I know that you’re an excellent coder, and you have an excellent product vision.
Paul: Actually, you have no idea that I’m an excellent coder at all. You’re assuming I’m an excellent coder, but there’s no evidence of this whatsoever.
Edith: People have told me this.
Paul: Who has told you this? I can’t think of anyone who would say I’m an excellent coder, who has knowledge that I’m an excellent coder.
Edith: There is no one that would vouch for you?
Paul: I mean, when I’m looking closely at who has worked for me or worked with me, or who I’ve worked for, the amount of people who would have closely looked at my code or the speed at which I put out code or how my code holds up in production, that sort of thing, there might be two or three people, in total, who could say I’m an excellent coder. I don’t think I’m an excellent coder.
Edith: But you do look excellent in a LaunchDarkly T-shirt.
Paul: Thank you. It’s a constant reminder that I don’t have all the good ideas.
Edith: I don’t understand.
Paul: I mean that LaunchDarkly is a good idea.
Edith: Oh, thanks Paul.
Paul: And I didn’t think of it. In fact, when I first heard of it, I thought, “This is stupid.”
Edith: Wait, did you really ?
Paul: Yeah. And I was like, Feature Flags as a Service? That doesn’t make sense.
Edith: Why did you think it was stupid?
Paul: Because it’s a small library, right? I mean, it’s not.
Edith: This is fascinating. Why did you think I was stupid?
Paul: I didn’t say you’re stupid.
Edith: Oh, no.
Paul: I thought, there’s no way you can possibly use that. We build that in 50 lines. I don’t understand how there’s a whole company behind this.
Edith: That’s a common evolution. We’re creating a category, and the first part of it is, “Why would you need that?”
Edith: “Okay, maybe I might need that. But if so, I would build it myself.”
Edith: “Okay, wait a second. Maybe I’ll buy this.” It’s funny because I’ve seen so many people go through that evolution in the past two years.
Paul: By the time that we built our fourth feature flag-ish thing in the code base, that was different to all the others for some specific reason.We’re like, “Maybe we should stop building these things ourselves.”
Edith: Yeah, that’s level four. Level zero is, “Why the hell would anybody ever need this?”
Paul: And so level five is where you buy LaunchDarkly?
Paul: That’s where we are happy customers.
Edith: It’s really funny, though, because people go through these stages.
Paul: Oh yeah, I totally see it. It’s the same with CI, right? People are like, “Oh well, at first I can just run tests on my own machine.” And then some problems with that. “Oh I can setup Jenkins now.” Three days into setting up Jenkins, “All right, maybe I will, try this CircleCI thing.
Edith: I love it when people acknowledge that we exist. I think I told you, I went to this conference in Sydney, I cited feature flags. I was going to say a comma, say who it was, and they all just started talking about feature flags, why they were or weren’t a good idea. I loved it. Nobody knew who I was.
Edith: I feature flagged myself.
Edith: This is a long detour.
Paul: We were at managers?
Edith: We were at whether or not Paul is a good coder.
Paul: Oh, okay. Let’s just go with “maybe.”
Edith: All right, so the original point was that people assume that everybody is like them. So as a founder of a company, of course you have to have some sort of vision. And you have to have some sort of way to build what you’re building. And then you think, “Everybody I hire will be just like me. It’s just another tittle, a product manager, and they’ll perform like a product manager.”
Paul: Yeah, exactly.
Edith: I get very annoyed at companies that require all product managers to have a CS degree. I think that’s extremely foolhardy and short-sided.
Paul: Someone explained to me the Google- versus the Facebook-school of product managers. And apparently at Google, and I haven’t worked at Google or Facebook, so correct me if I’m wrong…
Edith: And you’re a terrible coder.
Paul: Yeah, I probably wouldn’t even get in. The Google product managers have a CS background, and the Facebook product managers have a design background.
Edith: Okay, that explains a lot.
Paul: That’s actually all I have on this topic.
Edith: No, I think it explains a lot. I think you sell for what you know, and Google’s kind of legendary for its non-existent support, its complicated systems, and that’s why they’re really floundering with Google Cloud Engine.
Paul: I tried to build something on Google Cloud, it was an on app engine, and I thought it would be super simple to throw up a single-page app on it. No!
Paul: So much.
Edith: Was it just over-engineered?
Paul: There were just so so many steps involved. And I was thinking, “Maybe I can avoid AWS, because AWS is so many steps involved. My idea of it is that Google Cloud platform is sort of like a second generation of AWS.
Edith: No, it’s not a second generation. It’s its own genetic offshoot. I read a lot of evolutionary psychology when I was on the plane.
Paul: Oh nice. Did you read, “Why Beautiful People Have More Daughters”?
Edith: I have that book, but it’s been a long time since I read it.
Paul: I love that book. As I understand it, the entire field of evolutionary psychology is questionable. But it’s one of those books where it’s kind of like “Freakonomics,” that maybe each individual chapter is questionable in some way, but the overall idea in Freakonomics’ case, the idea of incentives, and in evolutionary psychology the idea that maybe we do things because 10,000 years ago we did things. I think they’re great.
Edith:I think there’s this idea that everything as a straight forward evolution it’s better than the thing before it. Sometimes they’re not, sometimes they’re just sideshoots.
Paul: So, you think Google Cloud platform is a sideshoot of AWS?
Edith: It could still evolve to be better, but everything I’ve heard right now is that everybody’s consolidating on AWS.
Paul: Funny thing about AWS services…
Edith: That everybody loves to hate on them?
Paul: Yeah so, my sense is that there’s two classes of AWS services. There’s the things that they built themselves, which are usually great. And there’s the things where they copied other people, which are usually crap.
I think that when you see AWS copying your startup, generally that’s very little to worry about.
Edith: Well, except they have the might of AWS.
Paul: Sure, they’ll make more money from the AWS version of it than you’ll ever make. Because they have that. But you’ll still have a better product that you’re able to carve out a very successful, large business out of. But I think if you’re building something that AWS built themselves, you don’t really see people…
Edith: I see your point.
Paul: AWS built EC2. They’re excellent at building EC2. But then they built code pipelines, and… not so much.
Paul: Martin came and made a podcast with us a couple weeks ago, and this kind of goes contrary to dogfooding. What you’re basically saying is Amazon is really good at building stuff of something they built from themselves. But they’re bad at being product managers for stuff that they’re not building in-house.
Paul: Yeah, roughly. So the dogfooding, I get it. And what? You take someone else’s dog food?
Edith: Well, basically acting like a product manager for external customers.
Paul: Yes, that seems very right to me.
Edith: Yeah, where as, I think Facebook has been so good because they focus on a single product.
Paul: It’s really easy to do if you’re Facebook. Also, Facebook has thousands of products. It’s just depending where you draw your lines.
Edith: Yeah. I’ve talked to a pretty sizeable company that are 40 people. They don’t have a product manager. I was kind of amazed.
Paul: It’s not that it’s impossible to build a successful company without any of these things, it’s just that you’re making it much much harder on yourself.
Edith: What my question then is, you have people acting as product managers. Probably your SCs, your CTOs, or somebody’s acting as a product manager. And it’s sucking up a lot of their time. It’s just you’re not giving them their title, and it’s not getting first-level support.
Paul: Yeah, and they’re probably not particularly good at it.
Edith: When I talked to them, it turned out that one of their SCs was basically acting as a product manager but with a very limited view of the world.
The thing that the product manager does, or one of the things that you start to need to do at the second stage of scaling, is you start to need to prioritize.
Edith: Yeah, before I was a product manager I thought my biggest issue would be coming up with the things to do. I really thought this. So I was like “How am I going to still get ideas?” Once you’re product manager, there is no shortage of ideas. Everybody has ideas.
Paul: I guess it’s a saying that’s organic at five people, what it is you’re going to build. Because someone has a really strong vision, and it doesn’t really need to be that informed by customers, perhaps. Or there doesn’t necessarily need the feedback, the emails coming in from existing customers, or there’s conversations as you’re on your way to product-market fit.
It’s kind of obvious what prioritization is. I think Paul Graham said you don’t need a bug tracker, because the things that are most obvious are the things that you need to fix. And you don’t need to write anything, then. And that holds to three, four people.
Edith: It should be very obvious. Let me give a slight shade.
The micro things are very obvious to people. The macro things sometimes can be much harder.
Paul: I look at it a slightly different way. I look at it like: the things that you do yourself, the things that you’re dogfooding are obvious, and the other use cases, other parts of the products, things that you know yourself, your support forums might get neglected.
Stuff that you don’t need yourself need explicit support at the second level of staging. And in particular, if there’s a thing that you’re slightly talented at, where you’re doing well with it, that a thing that you especially need to get head from under you.
For example, let’s say that you’re particularly good at writing blog posts that drive traffic. When you start to scale your company, you need to hire someone whose explicit job that is. Because you will stop doing it and you won’t really get a focus on it.Because you’re kind of good enough at it, and you think it kind of comes naturally.
You can say the same thing with support, you can say the same thing with really any part of marketing. You can say the same thing with product design, you can say the same thing with product vision. If you’re vaguely kind of good at it, then that needs to become its own area of responsibility with someone responsible for it as soon as possible, or else you’ll flounder at the next stage.
Edith: Yeah, definitely. We went through those transitions. I think the thing that struck home close to me is that there’s only so much time. But community is something interesting. You had some opinions about community and the culture at a company, how the culture of one company might mot work for another culture.
Paul: What I was saying before, about, “You have to set your mission and your vision” and that sort of thing. Really, what those are are elements of company culture. You have to know what it is that you’re building as a company. And you want all the people who are on board for that ride to be compatible with that culture.
There’s a great chart that Rand Fishkin made, that’s the CEO of Moz.com, or former founder of Moz. And what he said is it’s, “Who do you fire?” You’ve got someone who’s maybe not so great at their job, or someone that’s maybe not so great at their culture. Or, on the other axis, they’re good at it. So you got four stages, good at their job, good at their culture. And he said that people who aren’t necessarily doing great at their job, but they’re great in the culture, you keep them. And people who are doing badly in their culture, but doing great at their job, you let them go.
Edith: I agree, except for I think that’s where a lot of concerns about Silicon Valley and diversity come from. Because culture can be such a catch-all for, “Do you like to go play basketball at lunch?” And I’d say some people are just not suited for that.
Paul: We were talking a little bit about how you have to have product managers or you have to have prioritization, and that you have to have explicit human interaction and that sort of thing.
Edith: I think you need to have ruthless prioritization. And I think you have to have prioritization not just in what you’re going to do but in how well you’re going to do anything.
Paul: What do you mean by that?
Edith: You could spend a long time on one feature.
Paul: Oh yeah.
Edith: And it’s really painful, particularly at your, at any, size.
Paul: It depends on how important that feature is.
Edith: It’s really hard. People hate hearing that this is a check-box feature, but sometimes they are. Sometimes we’re just doing this for competitive pressure.
Paul: I think the one that every SaaS company learns is they need invoice emails and they need to have a PDF attached. No one cares about this feature except the accountants of the people who pay you. And we got this feature request so many times before we built it, and it’s just so unimportant as far as the product goes, but its essential in terms of what our customers need.
Edith: We built it just because every month, people would email us, “Where is our invoice?” and we would handmake them. It was mainly that we got to the point were it’s costing us a couple hours a month to handmake invoices.
Paul: And the irony is that, I think, Stripe has it built in there.
Edith: Yeah. Actually, CircleCI was one of the people who wanted invoices, I recall.
Paul: Oh really?
Paul: Oh man, it’s good to come in full circle. That’s because we’ve scaled to the 50-people size now, and we need things that we didn’t need when we were five.
Edith: Full circle… Did you do want to go