Ep. #49, Another Look at Product Management
In episode 49 of To Be Continuous, Edith and Paul discuss how to lead and manage a developer product to success.
In episode 49 of To Be Continuous, Edith and Paul discuss how to lead and manage a developer product to success.
transcript
Edith Harbaugh: There's still this cult of the lone wolf banging out code in a corner, that is very harmful.
Paul Biggar: Organizations often optimize for that. Especially ones that are, and again I'm not naming names here, but I can think of organizations that deliberately hire solo engineers, and as a result there is no appetite for team. Everyone's just working on their own.
Edith: Yeah, and I've seen that really blow up. Because you're not producing anything bigger than one person.
If your unit is, "How hard can one person work?" You're not going to produce anything bigger.
Paul: This is the model that I see in open source a lot. Organizations make room for lots of individuals, but there's nothing that's team related. Very often there won't be roadmaps. You saw GitHub talk about this, "and the code talks," and something else.
Edith: "Code talks, bullshit walks?"
Paul: Yes. Something along those lines. The idea that the right way to approach a project is to come with a code written, and then we'll have a conversation. Rather than having a direction and a road map or a list of things that we want people to fix.
Edith: That's so wasteful if you just think about it.
Paul: Yeah, that's the point.
Edith: If you just think about it from manufacturing terms, if you just think about it in terms of, you're trying to optimize for reduction of inventory. Code is inventory. If you've had 10 people go out and write 1,000 lines of code, you don't have 10,000 lines of code. You probably have 100 lines of working code.
Paul: But if you're not paying for the work that comes in--
Edith: Ah.
Paul: In open source terms, you set it up to get drive-by contributions or something like that. Or there's a lot of people who want to contribute and you spend more time trying to keep them at arm's length, than actually wanting to accept their code.
Edith: That's a really interesting way to put it. Because it's a supply/demand problem.
Paul: Yeah.
Edith: Because there are a couple extremely popular open source projects where they do have this oversupply.
Paul: Yeah.
And everyone else is starving.
Edith: Everyone else is starving. And then maintainers pick up this bad model like, "Oh I'm the maintainer."
Paul: Yeah, "I'm going to pick up the Linus Torvalds model."
Edith: Yeah. Instead of being like, "My biggest problem is not people bringing all this dumb code that need to screen with them. My biggest problem is that nobody cares." And even worse, somebody does care, and they spent a week writing this code. And then I have to break it to them that it's not actually--
Paul: It's not necessary, it's not valuable. Or you see teams or you see products accepting PR just because they're there.
Edith: And then you have this very real churn problem.
Paul: Related to that is the problem. Do you ever go to one of these projects on GitHub and there's 50 open PRs and they're just inundated with PRs that are all wrong because they haven't set up their environment, or they haven't set up their project in a way that they can actually accept incoming work.
Edith: It goes back to how I studied economics as well as engineering, and there's a whole thing about behavioral economics. About, "How do you encourage people to do something bigger than they are?"
You have to set up a framework where people feel like they can contribute and be valued.
That is the heart of being a good manager, setting up a path where people feel it. I talked a lot about this with a friend, this idea of "Contributed, valued, respected." That is my definition of a good manager. That they're encouraging people on the right path.
Paul: And in open source this doesn't exist. You're not employing the people on your project, for the most part. Someone else might be employing them, but you're not.
Edith: There's a ton of volunteer projects and they see outside of open source, most volunteer organizations have to set up a structure like this.
Paul: That's interesting. Because they're meeting in person and they're not-- I'm going to correct myself there. I was going to say, not made up of introverts and engineers, but I think that is also a faulty model.
Edith: There are volunteers all over the world who have never met each other. If you look in an organization like, I don't want to say the Red Cross, but there are many volunteer organizations where they're widely distributed throughout the world. And they have to coordinate and they have to be able to get people to work for free. And they somehow successfully do it because they've set up a structure where people--
Paul: It's probably because they don't only communicate via an issue tracker.
Edith: Every now and then you make me laugh.
Paul: It's a crazy idea. It is how open source projects do it, and it's often how companies that model themselves after, Mozilla is a good example here. Mozilla does everything in Bugzilla. That is becoming less true, but certainly when I was there if you wanted to get an air conditioning event fixed, you filed an issue in Bugzilla.
Edith: My theory about
waiting until you've already built something to give feedback is exactly the wrong time to give it.
Because this person has worked on it. And they have this endowment effect and they take it very personally.
Paul: Of course. They wrote this code and often they had this idea. And you're telling them that one or both are bad.
Edith: And they've probably worked on their own time, and they were really proud and happy, and ready to get the little pat on the head and show it off. Instead you're just slapping it out of their hands and being like, "This is stupid." Literally.
Paul: This was my major failure mode at Circle. We believed in "flat." We didn't believe in product managers and so on. We didn't particularly like meetings. That culture was from the founders and also from the early employees. We had hired people who were on the same page. As a result we didn't have a shared direction.
If we didn't have a shared direction and everyone is figuring it out on their own what to build, the result is when I am, as the CEO, able to exert direct influence on the outcomes. It's after the pull request is made.
Edith: Which is the worst time.
Paul: It was so bad. And people got pissed off, and they were right to get pissed off as well. So we set up this environment where people would build things and then they would show up at the end like, "Ta-da!" And then I'd be like, "No. That's wrong."
Edith: You know what they were waiting for, Paul?
Paul: What were they waiting for?
Edith: They were waiting for the CEO to say, "This is awesome. Thank you so much for contributing. We're happy you're here."
Paul: Right. And instead I'm like, "This isn't the right direction." Yeah, I know. I know. I'm feeling shame as you stare at me, as I should be feeling shame.
Edith: Literally, this is their moment to shine.
Paul: I know, I know. This was a major, early problem that we had. That because we believed so strongly in flat, even though we had no definition of what that meant, we wouldn't even set ourselves roadmaps or sprints. We wouldn't even talk about what we're going to do. It's just like, "I hope everyone figures it out for themselves." Don't do this.
Edith: But it wasn't flat, because at the end of the day it was like Flatland but with a point.
Paul: Yeah exactly.
Edith: Those poor people.
Paul: Yeah. I know. And ironically, people had this complaint, but the method that they wanted to change it to was where I don't do that. Which makes sense. But it wasn't addressing the other problems of, "We need a project in the same direction."
People didn't want more meetings, they didn't want more management, they didn't want more process. All these were dirty words.
Edith: But you had a process.
Paul: Well, we had a process and it was terrible and we needed to change to a different process. But that seemed more, and they wanted less.
Edith: So you had a process and it was people who squandered weeks of their time, if not months, and had their feelings hurt.
Paul: Yeah. That is exactly right.
Edith: That is the process?
Paul: That was the process we had. Yeah, I know. The feeling you have is a feeling that was had.
Edith: Of just the waste?
Paul: Yeah. The waste, the hurt feelings, the anger.
Edith: So how did you become not that person?
Paul: Well, let me just clarify. I don't think it's about being "that kind of person." It's that we set up that kind of process.
Edith: There's this term called psychological safety. It's that you feel safe making mistakes. I try really hard to encourage that at my own company.
It's OK to make mistakes as long as we iterate quickly and move.
And I want to create that attitude. That's why we'd have stuff like, "Here's our road map." We have our weekly goals. We try to have enough meetings.
Paul: Yeah, for sure. No meetings as an antipattern. Me and Ellen, when we started the new company, we had weekly two person meetings even though we talked all the time. "Here's what we're going to do this week, here are the things we're looking to accomplish, here is the ideas that we're going to validate," and our rough plan of attack for it.
Edith: And it's really important to do that officially because otherwise you just get caught up in just, oh my God, there's always something happening.
Paul: There always is.
Edith: And then next week you say, "OK. We want to do this, we didn't do this, why not?" And a lot of times it's just like, "This other thing happened." And that's fine, but let's acknowledge that.
Paul: The antipattern that people have is that they think "process" is a bad word when in fact--
Edith: You always have a process.
Paul: Yes. But no process is worse than the minimum amount of process that--
Edith: My thing is there's always a process you're following.
Paul: True, true.
Edith: Your process was people built stuff and presented it to you and you rejected or blessed.
Paul: Yeah. But I think people think of process as like, you set up a process and it's almost a sunk cost fallacy thing. But when you look at something that you didn't build, that just happened, that's not really process. But when you look at, "We have a list of things that we're going to do and we're going to do them in a meeting on Monday at 9:00 AM," then that's process.
There isn't a great realization that there is real process in no process. But that is the worst possible process.
Edith: Yeah, because I saw it so often. Because it would be like, "The lack of a decision is a decision." So here's a real-world example from 10 years ago. It's like, "Should we keep working on fixed packs for old customers, or new features for new customers?" Nobody made a decision, and what happened was all the individual developers--
Paul: Made decisions themselves. And what did they work on?
Edith: They worked on all these new shiny features, which were not actually new shiny features that the business wanted, and we didn't fix the bugs the customers wanted.
Paul: Wonderful.
Edith: All these developers had these great intentions, and it was the worst of all decisions. Because we didn't fix the bugs, we didn't build the right features. And we end up with all this other random stuff.
Paul: There is this idea of, "The hero developer." The hero developer sees that this thing can be done in better ways, comes up with the idea themselves, and then it is much beloved by the organization. The customers are in love with it and there are like four or five skunkworks project stories at Google or Facebook--
Edith: Gmail is the classic one.
Paul: Gmail is a great example. There's a couple of Apple stories like it that that are just like, "This thing was amazing." If they'd just kept it down and snuck it in, and everyone else is copying this. It's terrible in the general case.
Edith: There's always going to be these wild flash that pans that are going to happen. A lot of times what happens, and I saw this over and over and over again, is you build stuff that nobody wants. Which is the worst case.
I've seen so much, I call it wasted, because you build stuff nobody wants. Or what's better is, you build stuff that somebody wants, and nobody knows about it.
I'll add to this fallacy. I'll say something I said when I was younger which is, "This is a great product. We don't need marketing."
Paul: Oh.
Edith: "The product will market itself." No, you need somebody. This is why I do the podcast, this is why I go to talk at conferences.
This is why we write blogs. People don't organically know that you exist.
Paul: I'm completely agreeing with you. I've seen so many startups that have that exact problem and they're often, especially if they're developers, they're dismissive of marketing. They don't know the difference between marketing and sales and they're dismissive of all of it.
Edith: I've seen it over and over and over again, "We'll just focus on building the product." How will people know that you exist?
Paul: There is a pattern of people who see successful products, and they don't see the marketing that was behind the successful products because they were so good at the marketing.
Edith: Yeah.
Paul: A lot of people in developer tools modeled themselves off either Stripe or GitHub. And both of those are terrible examples to model themselves out of, because one, they were so successful that any flaw they had they could just overcome by the strength of their product market fit, or in GitHub's case the virality of it.
People looked at it, and we were talking about flatness earlier, people took flatness direct from GitHub and Stripe. I know we did. It didn't work for them, and it didn't work for anyone else either. But those companies survived and did well because they were so successful anyway.
Edith: There's a company called Valve which is--
Paul: Oh my god, the original!
Edith: Which is held up as the, "We don't need managers. Everybody just wields their chairs." They never managed to ship.
Paul: They never managed to ship? Oh, Half-Life 3. Yeah. Does it matter? They're making money hand over fist on Steam.
And that's the thing, if you're making money hand over fist it doesn't matter. You can delay your flagship product for 10 years.
I think there's been four or five different attempts to build Half-Life 3 that have all failed. It doesn't matter if the money's coming in.
Edith: It's like Google, they had this one core thing that they could do all these moonshots. You should take Dearing's class.
Paul: I should take Dearing's class. It's on my to do list. What will I learn during his class?
Edith: He has another book about orbiting the giant hairball, which is that you have to have some core engine. Which is basically the hairball, which gets stuff done. And then you also have to have creativity which is orbiting it, but you do need to have both. You can't just have these people out orbiting in outer space.
Paul: Is that the hero engineers in our analogy?
Edith: I do think engineers are heroes. I just think--
Paul: No, I mean the specific ones who think they're heroes, or who are planning for the grand heroic gesture. Grand heroic pull request, maybe.
Edith: Yeah. The thing that will save the entire company.
Paul: Yes, exactly. I noticed at Circle and this generalizes, the thing that you're good at your company does not become good at, because you can do it. And in our case it was content marketing. I was pretty good at content marketing. So we never built, while I was in charge, we never built a content marketing team. In fact, any real marketing team, because--
Edith: "Paul will just whip out a post."
Paul: Something like that. Yeah. Mostly because I never gave myself time to write them, because I was doing everything else.
Edith: It's funny. I ran into Des.
Paul: Yeah.
Edith: I'd known who he was, and it was weird because I finally met him in person.
Paul: It's funny, you can you can say Des and a large number of people will know exactly who you're talking about. No surname, no company name required.
Edith: Yeah. Well, I knew that you knew, because all Irish know each other.
Paul: Oh, right. Of course.
Edith: He was talking about how he'd built his blog--
Paul: We should clarify that we're talking about Des Traynor from Intercom.
Edith: Yeah.
Paul: OK.
Edith: He was giving tips on content marketing. And he did. He was good at content marketing but he built a machine.
Paul: The early success of Intercom, and I could be wrong about this, and apologies if you disagree with this, but to me it was built on the amazing and the extraordinary content marketing that Des did on the Intercom blog.
Edith: I think all companies have one, hopefully two, and maybe three things they are really good at. And you've just got to really double down on those.
Paul: Yeah. And that's what he did really well that most companies don't do really well. They see the skills of their founders not as things that need to be taken away from the founders, but things that need to be kept with the founders.
Edith: And that's what I'm trying to do. We hired a dev evangelist because I was like, "I can't keep giving talks. The travel was killing me."
Paul: And I'll bet, and you probably shouldn't answer this, but I'll bet that the dev evangelist is not as good at it as you are. Because you've been doing it for years and they will take time to get to the level of success that you get out of it.
Edith: The joke is that I was a terrible speaker when I started.
Paul: But you've been doing it for years now.
Edith: I literally remember that the reason why I started the podcast with you is that I wasn't very good at talks. It was easier when a I felt like I was just talking to a friend. It was much easier for me to get in a room and just talk, than to get up on a stage. Because I remember I was awful. I remember when I went to Web Summit I went into the bathroom and I just felt like I was going to be physically ill.
Paul: You were great at Web Summit. The one we went to, or a different one?
Edith: The one we went to.
Paul: You were great.
Edith: That's because I looked at you, I looked at Matt, "I'm just hanging out with my friends. This is OK." But it was bad.
Paul: Wow. I didn't even notice. You hid that well.
Edith: I used to literally hide in the bathroom. And the joke is that people think I'm a good speaker, but I was like, "No I was very bad."
Paul: But you got good.
Edith: Yeah.
Paul: There's a lot of things mostly related to marketing where the founder has a natural talent at it. Because you are the founder people give you the benefit of the doubt on it, because there's an authentic voice.
There's the authenticity of the founder selling, the authenticity of the founder going on stage and talking about it. You lose a bunch of that when you start to try to outsource it to someone else on your team. But there is no alternative. You can't keep doing it.
Edith: Because literally I was like, "I cannot keep doing this." It's funny. I hate to name-drop him, I met him once. But that's what Des says. Des is like, he used to go to every conference. Now he's just like, "I can't."
Paul: Yeah. Looking at how they think there's a book about this, about how they built that team up.
Edith: Yeah.
Paul: Did you know the editor of--
Edith: The Irish Times.
Paul: Of the Irish Times, became the editor of the Intercom content marketing team?
Edith: Yeah.
Paul: That's the kind of bold step they did, or innovative step they did to make their content as good as it is.
Edith: I asked the same conference, I talked to Nicholas from Algolia.
Paul: Oh yeah.
Edith: Such a nice guy.
Paul: Was this at the Heavybit Content Marketing Conference?
Edith: No, this was at Web Summit.
Paul: Oh, Web Summit.
Edith: OK. But I knew him from meeting him a couple times in the States. He was talking about how he gave speech training to all their engineers.
Paul: So that they can give talks. That that's a great idea.
Edith: Yeah. Because I was talking about how I feel like I've always encouraged people to give talks and they never want to do them.
Paul: I see this at the current marketing team at Circle, which is excellent. One of the realizations and the phrase our VP of marketing uses is, "By developers, for developers." And the marketing team is not developers. It has some developers on it who code, but for the most part it's experience marketers, and what they know is that the authentic voice is something that can't come directly from the marketer as it might in another vertical.
They have to pull content out of engineers. They have to have engineers go give talks. And the marketing teams are not people necessarily who market, but they become people who coordinate.
At least on the content side.
Edith: Oh my gosh, when I started the company I spoke once to two people. And I was happy two people came because that was far less humiliating than no one.
Paul: Yeah, zero would be--
Edith: I think our developers they'd go give these talks and they're like, "This is awful." Like, "What if somebody went to meet up and nobody came?"
Paul: Oh, no.
Edith: They get really shy and they don't want to do it again. I'm just like, "No!"
Paul: I went to this talk years ago, I was speaking at it. The stack overflow did a conference once in 2009, and people reviewed every speaker who spoke at stack overflow, and they did it in like 16 cities or something like that. So you could see it happening. The LA thing was held, and there was reviews, and then some people were panned. So I talked at the London one and there was two speakers who wrote public apologies on their blogs afterwards because the reviews were so critical.
Edith: Oh no.
Paul: Could you imagine?
Edith: Were they really that bad, or were people just very critical?
Paul: They weren't great. But bad talks happen.
Edith: Bad talks happen.
Paul:
You're not a bad person if you had a bad talk, you misjudged the audience, the audio was bad.
I don't know what causes people to have bad talks.
Edith: I had this bad talk, SoftTech wanted me to speak at their summit.
Paul: I hear they're not SoftTech anymore.
Edith: They're Uncork now, thanks for asking. And I was very proud. Annie, my VC and our investors said, "I want you to talk about your running." I said, "Great. I have this talk I gave in Oslo." And he got the slides and he's like, "Are you sure you can do this in five minutes? All you have is ten minutes." And I'm like, well "I did it before when the slides auto advanced. Giving this lightning talk. That'll be fine."
Paul: Oh, and they didn't auto advance? And you kept talking?
Edith: It's worse. They auto advanced.
Paul: Oh, they did auto advance.
Edith: And I'm like, "You've got to be in a mood."
Paul: Interesting.
Edith: They auto advance at a speed of five minutes.
Paul: Yeah.
Edith: The talk was supposed to be ten minutes.
Paul: Oh, interesting. You had set them to auto advance.
Edith: But I thought they would clean it out, because they put this into the master deck. So I reviewed them with the lady before on stage everything. Everything looked great. I got up on stage, and the slides are moving at double speed.
Paul: And you don't have a control?
Edith: I have a control, and I keep hitting it, and I'm like, "The slides are moving!" And it was one of those awful things where they'd put it into this huge master deck.
Paul: Oh no. You can't go back and change it. For all the hassle of swapping out laptops, at least you know what you're getting.
Edith: And so I said, "Look, just please stop it. I'll just talk. This is far less stressful than me trying to talk double speed."
Paul: "Fuck it, we'll do it live."
Edith: Yeah. So I did it live. It was not the greatest talk I ever gave, but oh my gosh. Do you give talks now for Dark? Or are you still keeping it Dark?
Paul: Still keeping it Dark. We haven't decided on the name. And until we get a name, which I think we are rushing for, because it is hard to hire people when your company name is EllenandPaulsNewStartup.com.
Edith: Why is that so?
Paul: It's because it just feels a little too early for people. A name appears to be a big deal for seeming credible as a small company.
Edith: A turning point for us was when we got a logo.
Paul: Interesting. I wonder if that'll become the next bottleneck? Just remove bottleneck after bottleneck. We're nowhere near a logo either.
Edith: I literally remember, it was the second day after John and I started working full time. We came up with our name, because we need to tell people where we work.
Paul: We had a plan of buying Dark.ly. And then setting up a launch page on it, at launch.dark.ly.
Edith: Yeah you told me about this and I was not pleased.
Paul: Unfortunately Dark.ly is $1,500. It's not that much, but it's a lot to prank you.
Edith: I'm honored that this would cross your mind.
Paul: For $30 I'd have pranked you, but for $1,500 I don't think it's worth it.
Edith: What's the breakpoint? Is it once you get into triple digits?
Paul: I think so, yeah. I think maybe $80. I think this might be worth about $100.
Edith: Yeah, and once you've minted your millions on your new thing--
Paul: Exactly, yeah.
Edith: That'll just be something you dash off to your admin.
Paul: Yeah.
Edith: "Purchase Dark."
Paul: "Mock Edith." We could just have a standing task every month, "Have we mocked Edith this month?" "Not yet."
Edith: I have a friend, and I won't say his name but he was in McCellerator. And his company got acquired two years ago.
Paul: I'm sure with just that information we could figure out who it is.
Edith: I fudged the date a little.
Paul: OK.
Edith: But I found this out because I was visiting a customer and I saw him walking down the stairs, and the customer is like, "Oh yeah, we just acquired so-and-so's company." And I was just like, "Oh." So I texted him, "You got acquired?" And he was like, "Yeah. But we're keeping it secret. I'm going to have a party soon."
I was like, "Great." And then I saw him two months later, and I'm like, "What about the party?" And he's like, "I'll have it next month." So every month I text him, and I say, "When is the party going to be?" Because he still hasn't had his acquisition party.
Paul: Or he had the party and he didn't invite you.
Edith: Oh.
Paul: I'm sure that's not true.
Edith: It's funny, in February of this year he said he would do by end of year. So now I'm at the point where every month I'm like, "Hey dude."
Paul: Yeah. "I'm dying for this fucking party. It's built up so much at this point."
Edith: I'm like, "I will have IPO'd before you have your party." So, we've got some exciting guests coming up.
Paul: Oh, who do we have?
Edith: Should we tease them?
Paul: Sure. Let's do this.
Edith: It's both of their birthdays that day.
Paul: Who is it?
Edith: Somebody who is going to say a lot of interesting things.
Paul: Can you give me a first name?
Edith: Armon.
Paul: There's another person, right?
Edith: Glenn.
Paul: Armon and Glenn, whoever they are.
Edith: Their birthday is the day they're coming in.
Paul: So you will hear this three months after that.
Subscribe to Heavybit Updates
You don’t have to build on your own. We help you stay ahead with the hottest resources, latest product updates, and top job opportunities from the community. Don’t miss out—subscribe now.
Content from the Library
How It's Tested Ep. #3, Balancing the Ownership of Testing with Alan Page
In episode 3 of How It’s Tested, Eden speaks with Alan Page. The conversation begins by exploring why developers should own the...
How It's Tested Ep. #1, A Closer Look at Product Testing with Ian Brillembourg of Plunk
In this debut episode of How It’s Tested, Eden Full Goh of Mobot speaks with Ian Brillembourg of Plunk. Together they explore...
Jamstack Radio Ep. #119, Customer Retention with James Hawkins of PostHog
In episode 119 of Jamstack Radio, Brian speaks with James Hawkins of PostHog. In this talk, James shares insights on utilizing...