In the latest episode of To Be Continuous, Edith and Paul discuss 5 topics that are relevant to most startups. They first examine how you can constructively tell someone that their startup sucks. They then look at why it’s a bad idea to outsource early-stage development. They also discuss what makes a good gift and delve into the downsides of flat organizational structures. Paul also shares his impression that Hacker News comments are becoming too Redditified. This is episode #33 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.
TRANSCRIPT
Edith Harbaugh: So, I actually am the opposite. I hate telling people their startups suck, because usually I don’t know anything about their field. I don’t know anything about their area. So I do advising for my accelerator, and they asked me to give feedback on their pitch but I tell them, “I don’t know the drone business”.
Paul Biggar: I think it’s generally, fairly easy to tell whether someone’s startup sucks. I don’t think it actually relates to the content of their thing. So, someone’s startup usually will suck if they have a very strong idea of what they want to build and haven’t done much validating. That’s typically how I tell people that their startup sucks, that you haven’t validated this at all, all you have is an idea. There’s a 99% chance that this is going to fail because everybody else’s startups in the same position would fail, they validated their way into something that succeeds.
Edith: I mean that’s fair. I guess, so why do you enjoy it, though?
Paul: It’s just super high value.
When you tell someone that their startup sucks and they internalize it, they go back and they look at what they were doing and realize that they’ve been wasting all this time. But they also come out of it and say, “I’m dedicated to doing this thing and now I know that I need to validate, I need to build, I need to take the thing that I’m doing”.
So, I was talking to my friend about this and she had this idea about startups about sharing hotel rooms, right? Yeah, exactly, right? So, I’m like “I can’t tell you whether that idea itself is bad but I can tell you that if you build it it will be bad.” What you should do is you should just go talk to people, stop them on the street, and ask them, would they use this. And or what would make them use this, and she did, and what she learned was that people under 30, sometimes, people over 30, absolutely no way. That was valuable feedback.
Edith: I mean, I don’t even like to share a hotel room with my sister anymore.
Paul: Yeah, absolutely. But like, I didn’t know whether it was a bad idea. I mean, I sensed that it was a bad idea, but all you have to do is ask a bunch of potential customers, you’ll figure out whether it’s a bad idea.
Edith: Well, I think the key is potential customers, like I got really tired of the lean hacks or like asking people at a coffee shop. If you asked 10 people in a coffee shop about Circle CI they would be like pff.
Paul: I think asking people in a coffee shop is wonderful.
Edith: I think it’s wonderful if you’re a certain kind of idea, but like.
Paul: Yes, consumer obviously.
Edith: Yes, so if you asked 10 people in a coffee shop, not in the Bay Area, if they’re in favor of automated continuous integration.
Paul: No, of course not, that’s obvious, but if you asked 10 people in a coffee shop in Milan what they think about your fashion startup, you’d probably get some good feedback.
Edith: You might not be able to understand it if you don’t speak Italian, though.
Paul: So, the reason I like telling them is that just you rarely have the opportunity to change someone’s life, right? But, someone where when you give them successful career advice, you can literally change their future. So, I talked to these guys who had spent like 70K of their parents money on a startup and they had 30K left, and they were just like going the same way, they were going to lose it all.
Edith: Well, I guess the hard part is when you see people going off of a cliff and they don’t really see that cliff.
Paul: They don’t see the cliff? Right but you can tell them, “look, you can’t see it,” but there’s a cliff right there.
Edith: Like a good friend of mine, he came to me because he’s like “we got about three months of cash left, we’re not able to raise money, what should we be doing?” And I ran through everything I thought they should be doing, like lay off half the people, try to start charging as much as you can right now, and they took one piece of advice, which they did try to start charging and they couldn’t make enough money, but it was not enough to raise an A, and so they had to lay off everybody and shut down.
Paul: It’s better that you told them that than that you didn’t tell them that, right?
Edith: I think he was looking for a magic answer.
Paul: Yeah, there isn’t a magic thing. Validating is as close to magic as you get, but you have to ask those questions when there’s a reasonable amount of time left. If you ask the question when you have no money left, “we’re going to shut down today, wave your magic wand”. It’s like “no, there is no magic wand.”
Edith: Yeah, well it’s good that you’re around to tell people that their startups suck. How do you do this as a service? What if a lister wanted advice?
Paul: I’ve thought about this, I’ve thought about creating a little landing page and you can pay me $100 and I’ll tell you how your startup sucks.
Edith: Great.
Paul: That’s $100, not because I want your $100, but because I want someone who’s actually cares enough to listen to my advice to pay $100.
Edith: Well, we’ll see by the time this show comes out if we have that up.
Paul: So why does outsourcing early development suck?
Edith: Oh my God, on so many levels. Number one, you want people who are part of your company and part of your culture and talking to your customers.
Paul: You mean the people who build your product should be…
Edith: Yes. They should be as close to your customers as humanly possible. This is why, for example that our engineers took support tickets.
Paul: Right, ours did that for the first two years.
Edith: Yeah, so number one,
You want to have rock step alignment between engineers and customers,and you do that by all being co-located in the same place so that you’re allcontinually breathing the same air, talking the same talk.
Paul: So you don’t even believe in having a distributed team at this stage?
Edith: Not super early, no. I know people who make it work and maybe they’re better than us, I know other companies who do it but for us, it was very important that we all be co-located. We’ll work from home some days, but we’ll come into the office every day.
Paul: Right. So, I had very much the same idea. Like, outsourcing anything, whenever someone comes to me and asks how do we outsource, I’m like don’t. And especially if it’s a time zone that’s not your time zone.
Edith: I think there’s plenty of things that an early stage startup could outsource, like accounting.
Paul: Oh, absolutely, yeah, but not product development.
Edith: Your business is two things when you’re early and that’s building a product and building a culture. And if you’re outsourcing your development, you’re doing neither.
Paul: So, when you outsource your development, the whole point of early startups is validation.
Edith: Right.
Paul: You’ve got some experiments that you want to validate and you need to turn it around immediately. And having a time period where you need to email someone and then you get the response the next day because they’re in Ukraine or they’re in India or wherever they are, is just ridiculous.
Edith: And so there’s number one, there’s the lag, there’s the gap then between potential customer empathy.
Paul: Tell me more about that.
Edith: Like for example, I was on a product where we sold to newspaper editors, and we tried to outsource to India. They just didn’t really understand the culture.
Paul: They don’t know what a newspaper editor in the US needs.
Edith: And then you just have a lot of cultural differences.
Paul: So you find it hard to explain to them what it is that you’re really trying to build?
Edith: Cultural differences about like I found in particular, America has a very adversarial culture sometimes, they’ll just say, “hey that idea’s bullshit, or what do you mean, or that doesn’t make sense”. Versus other cultures, where they don’t want to challenge authority, where they’ll go away for two weeks and come back, and you’re like, this isn’t what I wanted at all.
Paul: Right, okay yeah.
Edith: And they’re like, “well I was afraid to ask”. I didn’t want to look dumb and ask.
Paul: Gotcha, and so if there’s no connection, if they don’t see you every day in the office, that sort of thing that they’re not going to have the ability to talk to you and ask, basically.
Edith: Even that that there’s a cultural gap, it’s only the worst case was somebody said they were going to build, what was it, an Apache 5 updater, and after three weeks we were like, “hey, where’s the code” and it turned out he’d written zero code, he had no idea how to do it, but he was too ashamed to admit it.
Paul: Wow.
Edith: So, culture differences, time lag differences, cultural within the team and then within the customer itself, speed?
Paul: So the biggest thing for me isn’t necessarily speed so much, but it’s sort of tangentially related. I get startups that ask me like, “oh I have this really good idea, I just need to raise a bit of money so that we can outsource the development and they can build the thing”. And the problem is, that what they’re hoping to happen is that they will get back a working product.
But the working product is not useful anyway, because you need to keep iterating, and you need to build that into your company that we understand the product space, we understand where things have gone right, where things could go wrong, and the optimal solution for outsourcing is they actually do what you tell them and reply with the thing that you wanted them to build.
And the best case isn’t sufficient, either. Because the thing that you wanted to build is right today until you talk to customers, and then it’s wrong tomorrow, and then you need to go do that again, and you spent your 25K or 50K or 100K on development, and you got the product back and the product almost definitionally can’t be the right product.
Edith: Yeah, and there’s so much last minute fit and finish. So I used to be a spec writer, I would write requirements, and invariably, there’s interpretation when it comes to a spec, and the reaction at one point was like let’s try to put more and more into the spec until basically they collapse under their own weight, that nobody can lift them.
Paul: You might as well write the code at that point.
Edith: Yeah, but you still miss a lot of nuance in the final steps.
Paul: Right.
Edith: Like hey, we have all this spec, but when we started to put it together, like hey, maybe we need this other use case or we notice that.
Paul: Yeah, there’s no type checking or unit tests in the spec and so when you start to actually try to build it you realize that these two things are contradictory and then what are you going to do?
Edith: Yeah, or just all the fit and finish stuff, or what if you realize that there’s actually this corner case that you design a lot for but that you don’t need anymore?
Paul: Mhm. So to finish this out, what would you say to a startup which told you we’re planning to outsource?
Edith: I would say, what is your core competency? And I come back to what I said before that
The core competency of a startup should be building a culture and building a product. And by outsourcing building a product you’re not doing either.
Edith: So Paul, what do you like about chocolate so much?
Paul: I think it’s sugar. I think I’m fundamentally addicted to sugar. And I think as far as I can tell from everything I’ve read, sugar is a poison, and you really shouldn’t eat sugar, but my three favorite foods are ice cream, pastries and chocolate, and I don’t think there’s very much I can do about this, unfortunately.
Edith: So, it’s funny because as I’ve gotten older, I’ve started to like sugar less and less. I was a little kid who literally, when I went to church, I would leap up at the end of the service and run down the aisle.
Paul: Because there’s like donuts downstairs or something?
Edith: Yeah, because my parents would have sweets, but there would be cookies, I would weave around all the old ladies, like hugging each other and dive into the cookie jar. But now, I don’t really like sweets anymore.
Paul: I think when I was a kid I didn’t have ready access to sweets.
Edith: Oh, it was only at church.
Paul: Oh, only at church, okay.
Edith: That’s why I was so excited, because every Sunday I got a cookie.
Paul: Right. Well, we didn’t necessarily have, like we weren’t sugarless, but I think once I sort of had my own money, and I was just like, I can buy chocolate any time I like now. It’s like when you’re an adult, you can suddenly buy bacon any time you like, and it’s not very good.
Edith: I did like sugar a lot as a kid, I remember I would buy Pixie sticks, which to me now seem revolting, like do they have Pixie sticks?
Paul: No, it doesn’t ring a bell.
Edith: It’s literally a stick full of powdered sugar.
Paul: Oh so I don’t even like just pure sugar, I like milk chocolate and people complain a lot about milk chocolate. People are like on the dark chocolate bandwagon a lot these days, all the hippies with their coffee and their strange mustaches. They like dark chocolate, but I think dark chocolate isn’t sweet enough for me. I like a really creamy, sweet chocolate.
Edith: So it’s the sugar you like.
Paul: It’s the sugar, yeah. I gave it up for a month, and I had withdrawal symptoms. I had like headaches and lucid dreams and nightmares and waking up in a cold sweat in the middle of the night.
Edith: Did you ever have a lucid dream within a lucid dream?
Paul: You know, I may have had.
Edith: I have those and they’re really freaky.
Paul: That is fucking freaky.
Edith: No, it happens to me.
Paul: Frequently? Oh. I do have dreams where I realize that they’re a dream and I can sort of make a decision as to whether I’m going to stop, but they’re usually not about chocolate.
Edith: Well, the freakiest dreams are you realize you’re in a dream and you wake up, but you’re really still in a dream.
Paul: You wake up from the dream in the dream, interesting. And this is completely unrelated to sugar. Because you, from the sound of it, don’t go nuts on sugar.
Edith: Yeah, so I think your lucid dreams are independent of sugar.
Paul: They only happen when I give up sugar for a month which is something I need to do routinely to scale back my sugar consumption.
Edith: So you’re saying if I eat more sugar I would stop having these weird dreams.
Paul: Well, I was confused as to whether it was sugar withdrawal or whether it was theobromine withdrawal.
Edith: Say that again?
Paul: Theobromine, it’s the caffeine-like active ingredient in chocolate.
Edith: I learned something new today.
Paul: And it’s addictive in the same way that caffeine is and it has a lot of the same properties and I had basically coffee-like withdrawal symptoms.
Edith: It’s interesting, so the Mormons used to be a huge customer of mine.
Paul: Really?
Edith: When I was at a different company.
Paul: Did you say the Mormons? So the Church of Latter Day Saints.
Edith: So they have very strict rules.
Paul: The Church itself was your customer?
Edith: Because they have a ton of content that they want to manage. They’re not allowed to drink alcohol, or caffeine. So the salesperson would bring them chocolate.
Paul: Oh, okay. So just like you bringing me chocolate for every podcast episode.
Edith: Well, you know, I got to bring you something.
Paul: Sweetening them up a little bit.
Edith: Yeah, I guess that’s true, I mean. Well, thank you for wearing your Launch Darkly T-shirt. Yeah, so chocolate. It’s funny because I could take it or leave it, but you seem to love it.
Paul: No, I love it. Today’s brand, Nirvana Belgian chocolates, organic Belgian milk chocolate with Spek-Ah-Loos cookie. This is, I think the best one that we’ve had so far.
Edith: Really?
Paul: Yeah.
Edith: This gets into the whole topic of customer gifts. Which I’ve started to get as we moved up the food chain.
Paul: I get gifts from VC’s.
Edith: What do you get?
Paul: I got a jacket from DFJ. I got a Chromecast from Bessemer.
Edith: What? Like for the Holidays or?
Paul: Yeah, and Bessemer actually sent me like a rickshaw carrier bag.
Edith: You got a jacket from DFJ?
Paul: Yeah. It’s a little too big for me but it’s like a big, puffy sort of thing you get from Uniqlo.
Edith: I saw Shirag wearing one of those.
Paul: Yeah.
Edith: I feel so, is that like what you get after you get a B round?
Paul: Well, they did our A.
Edith: They did our A too.
Paul: Well, but they only just did your A. Maybe you’ll get it next Christmas.
Edith: I’m going to text my VC.
Paul: You closed before Christmas?
Edith: Oh yeah.
Paul: Oh and they didn’t send you a gift?
Edith: No
Paul: Rude.
Edith: Well they sent us hoodies. So they sent us hoodies, it’s pretty standard. I actually have this burgeoning collection of hoodies.
Paul: Do you have a shelf of startup t-shirts and a shelf of startup hoodies?
Edith: Uh, I try to be pretty vigilant. The reason why I always ask people if they want a t-shirt before I give it to them is because otherwise you just end up with hundreds of T-shirts.
Paul: Right.
Edith: New Years last year I took 60 shirts to Goodwill.
Paul: Oh. I give away or get rid of them often. If you’re a startup and you have ill fitting t-shirt, it’s like, no one wants to wear that.
Edith: Yes.
Paul: I don’t understand why people make shitty t-shirts. Like, American Apparel, that half the startups are using, is a wonderful fitted shirt. The 50-50s, and if you’re making this shitty, cotton, it feels awful, looks awful.
Edith: No, a big thing for us is that people like our shirts.
Paul: Yeah. Same with Circle shirts.
Edith: Yeah, no it was actually really cool so John, my co-founder’s our chief t-shirt officer.
Paul: Right.
Edith: Because he’d been at Atlassian, so he could tell, he’s like “Okay. Here is the kind of shirts we need to get”.
Paul: Yeah. I really wanted to make a T-shirt, and we meant to do this but we never did. From the it’s the future thing, put it in a container and continuously deliver that shit. That needs to be a T-shirt.
Edith: Yeah, it’s funny like I wanted to do them yellow, and John’s like “navy, everybody wears navy”.
Paul: He’s right. You can have some form of gray, some form of black, some form of navy, but yellow is not a color anyone wears.
Edith: I wear yellow. Yeah, it’s funny, it makes me really happy. I went over to hang out with my friend Matt, and he was wearing a Launch Darkly T-shirt.
Paul: Nice. But it wasn’t yellow.
Edith: No, it was navy. And even our Ed wears his Launch Darkly shirt.
Paul: Yeah, and I wear mine all the time, I’m wearing it right now.
Edith: Yes you are and it looks lovely on you. So, chocolate, good vendor gift or bad vendor gift?
Paul: Strong vendor gift.
Edith: Perishable, though.
Paul: Eh, this chocolate lasts a while. The problem is that they might be allergic to dairy or sugar.
Edith: Yeah, what else did I get, I got coffee, and I got wine.
Paul: Coffee definitely perishes. Well, wine is a good gift. I feel in San Francisco, you give people whiskey instead.
Edith: Really?
Paul: Yeah, like giving someone a nice whiskey.
Edith: I don’t drink whiskey.
Paul: Well, my friend worked at Stripe and they just get all sorts of gifts, like just baskets and so you can kind of wander over to their desk and if you want the really nice whiskey just take it, because what are they going to do with their hundredth bottle of really nice whiskey?
Edith: I don’t know. So, it is interesting, though that I think we’re a Circle customer, we’ve never got a gift.
Paul: Circle doesn’t really do gifts to people. We do some if people have been very helpful. We had one vendor who sent us cake.
Edith: Oh wow.
Paul: I wouldn’t say that they screwed us but the bug in their application completely screwed us. This is a story that we still can’t really tell, but as a result of them we ended up doing something really bad accidentally to customers.
Edith: This would be a really interesting story if there were any details.
Paul: I’m going to wait until the people go public, and then yeah.
Edith: This one time, this bad thing happened, but I can’t tell you any details. Great story, Paul.
Paul: In the end, they sent us cake and it was happily ever after.
Edith: Anyway, Paul. Why do flat organizations suck?
Paul: I could tell you about 20 million different reasons why flat organizations suck, but basically they’re founded on, I think this incorrect premise that hierarchy is bad.
Edith: Yeah, that hierarchy is bad and should be avoided at all costs.
Paul: Right. And there’s sort of a school of though that everything that engineers don’t really like is bad and so we should cut them out.
Edith: Meetings are bad.
Paul: Meetings are bad, hierarchy is bad, process is bad. Project management is bad. Managers are bad.
Edith: It’s a like a Dilbert cartoon where it’s like.
Paul: Right.
Edith: Everybody around me is pointy headed.
Paul: Right, and I think it originates because everyone has really bad experiences with a bad manager, with a bad organization, with something that was poisonous or toxic, and so that’s definitely true. But, when you see it done really well, or
When you see the kind of logical implication of flatness, and when you can’t really make it work, then you end up reinventing hierarchy in a flat-ish kind of way.
Edith: I got happy hour with some friends yesterday and we were talking about the fact that if you claim you have a flat org you have a hierarchy, but it’s just unacknowledged.
Paul: Right.
Edith: And unofficial, which is even more awful, because people don’t know how to get stuff done. This person’s doing a bad job, who do I complain to? We want to hire four more people. Or this business unit isn’t doing well.
Paul: There’s an essay called “The Tyranny of Structurelessness” and it’s about the womens feminism movement in the ’70s, and maybe earlier where they deliberately went for a structurelessness organization. I think the idea was that part of the problem of the patriarchy is hierarchy, and they ended up just having tyranny. It’s the word that they used, and it came about that just power wasn’t earned anymore, power was sort of like politic’d in.
It became who you knew, people formed cliques and power formed into those cliques, and in order to get anything done it all became about who you knew in order to make anything happen. And when you hear about, let’s say GitHub, famously had that flat organization, and what you hear from insiders at GitHub, is “yeah, any engineer could work on anything that they found important, if they were friends with the co-founders, or maybe one of the first 10 engineers”.
Edith: Yeah, and then it’s just, I liked your word poisonous, because there is a structure, there is a hierarchy, it’s just under-acknowledged.
Paul: I spent some time trying to figure out how to work around this, because we really tried hard for flat at Circle, and the answer that I had was areas of responsibility. That’s Asana’s form of flatness, or they have a little bit of flatness. And the idea is that basically everyone in the organization has things that they’re responsible for and there’s a document that says this person is the number one person who knows about T-shirts, or the number one person who knows about this product area. And they’re simultaneously responsible and knowledgeable about that.
Edith: And an owner.
Paul: An owner is a good way of thinking about it. You can build all sorts of processes around how ownership transitions and or how you can take ownership or that sort of thing.
Edith: Fit inputs and outputs.
Paul: Right. And I think it’s a very good idea if you’re into the flatness, because
One of the things that’s missing from flatness is ownership and accountability
and this institutes that some amount of ownership and accountability. And accountability I think is the essential thing that flatness doesn’t really encourage.
Edith: I think flatness is not the same as organization.
Paul: I’m not sure what you mean by that.
Edith: I just took Michael During’s course on management.
Paul: Oh really, I did his finance course, it was amazing.
Edith: His course was so good. We read Andy Grove’s book, which I love. Because I’m an engineer.
Paul: This is High Output Management?
Edith: Yeah, have you read it?
Paul: I’ve started to read it several times.
Edith: It’s great, you can borrow my copy now but it’s great because he looked at management as a system, and I’m a Systems Engineer and he says the job of a good manager is to get high output out of their organization.
Paul: Right. He invented OKR’s, right, in that book?
Edith: Pretty much, yeah.
Paul: Okay, yeah.
Edith: I liked it, he was very much pro-managers. Your responsibility is to make sure your organization performs. Which I think a flat, what you just said, is kind of missing that, that who tunes all these pieces?
Paul:
The assumption is with flat is that everyone that you hire is amazing and knows exactly what needs to get done, and perhaps that survives at five people, maybe as far as 10 people, but there comes a point where the overhead of trying to understand what you need to do is so high that it just doesn’t make sense anymore.
Edith: Yeah, I mean and then there’s things that need to have some sort of higher function, like what three people are we going to hire next year?
Paul: Yes. Or, what is the product road map? You can have 10 people each decide what their own version of the product road map should be and the end result is that no product road map will be built, or 10 10%’s of a road map will be built and everyone’s going in different directions and no one is on the same page.
Edith: It’s kind of the bizarre theory of management, then.
Paul: So actually, I think this is responsible for this. When you say Bazaar, I’m thinking of.
Edith: The Cathedral.
Paul: Yep. Raymond’s essay. And people have this open source development methodology, right, in their minds. Developers understand how open source works. You come up with a pull request, code talks, talk walks or whatever that thing is.
And it’s just complete crap. Because you need to have everyone on the same page, and this is why so many open source products are shit, because they don’t have a single person who’s saying this is the page that we’re on, this is what’s getting built next, don’t bring me your shitty pull request, bring me something that’s on the product road map.
Edith: Well, and even more than that, it’s very painful to that person.
Paul: Yeah there’s nothing worse. This is where I lost a lot of almost a lot of friends and certainly a lot of employee love, is that I would kill their PR’s just before they were ready to ship. They spent so long on them and just, I hadn’t gotten in my head the idea that we need to decide what to build before we spend a whole bunch of time on it.
Edith: Yeah, because it’s extremely expensive then, not just expensive for time, but expensive in opportunity cost and employee morale. This happened to me. We built something for several months, we went to present it to the VP of Product, he’s like this is shit. I don’t want to ship it. Crushing.
Paul: Of course, yeah. The way around that is to take the product road map, the direction that the company wants to go, find the bit of it that’s most exciting to you and then take ownership of that. And then when you ship that you already know and obviously you’re not just shipping it, you’re bringing it back in multiple steps and getting feedback along the way. There’s a really good article by a guy called Sean Lynch who was a PM at DropBox.
He said that one of the things that really enabled them to grow was their shared vocabulary around how to ship products, and they called it Phase Zero, Phase One and Phase Two. And in Phase Zero, you’re kind of getting rough alignment on what is the build, but we don’t want to hear any of your bullshit about the words are wrong, that’s a Phase Two problem. The Phase Two is the time that you sweat all of the details and Phase One is somewhere in between.
Edith: Yeah, I mean, so I learned this back when I was a consultant, so you know I would have projects and we would be very careful about not putting too much detail into wire frame.
Paul: Right, because once people figured the wire frame looks done, then they think it’s done.
Edith: And then they fixate on that and you’re like no no no, this was just trying to get consensus. So I know you hate waterfall, but I think waterfall’s actually very good if you think of it as, let’s have checkpoints before we continue to invest in something.
Paul: Yeah. There’s definitely some value to that.
Edith: You admit there’s value in waterfall?
Paul: I admit there’s value in checkpoints.
Edith: Can we just..?
Paul: No, because I did not agree that waterfall is good, I agreed with the principle of knowing what it is you’re building before you’re building it. Can I just say that that’s not actually what waterfall means.
Edith: Generally, that was the intent of it was that you have different phases and you have checkpoints of “is this ready to go to the next phase”.
Paul: Yes, but each of those phases was like, there’s the spec phase and there’s the engineering phase whereas when we talk about what DropBox was doing, there’s engineering in each phase, there’s customer validation, there’s feedback. There’s not a concept that we know what we’re building and we’re just going to drive that through five phases to the end.
Edith: I did experience waterfall and there was some extent of like you would get to a different phase and he’d be like, “Hey, we’re not going to try this to the end”.
Paul: So what you’re saying is there’s good waterfall and bad waterfall.
Edith: I think waterfall, we’ve talked about this before. I think waterfall gets maligned and what it was trying to prevent was what you just said of if you allow the wrong side of feedback at the wrong time, it can be very destructive.
Paul: It seems like it is possible that there’s, just like there’s good waterfall, but maybe 99% of waterfall is bad waterfall. I think probably the same as true in flat.
Edith: I think what you just said resonated a lot about GitHub and how the way
They thought the open source world worked, which was people just contribute and if it’s good it gets in, and when you look at it there’s actually a lot of hurt feelings.
And the same with the org structure. They’re like, well good ideas will win, it’s like well, win what? And if I don’t get along with somebody or if there’s a disagreement, who do I go to?
Paul: I think it is possible to do flat well, but I think the problem is that almost every attempt to do flat well has failed.
Edith: Well, let’s define what you mean by flat.
Paul: That’s a really good point, because I think most people don’t define what they mean by flat. This was a problem at Circle, that everyone had their own version of what flat was and what flat meant and to some it was like no one will tell me what to do and to some it was like, everyone takes responsibility for their own thing and some it was like ideas will find their way to the top.
Edith: Yeah, you should read Andy Grove’s book, but he talks about how this guy hated the Intel style, not as an insult, but management driven. Like you have people who approve decisions, and who coordinate between groups and he’s like, I’m tired of this, I’m going to go to this other company where I can do whatever I want to do.
And he came back in six months, they asked him why and he’s like, because everybody at that company did whatever they wanted to do. And so everybody was just cowboying.
Paul: There’s this idea that in your startup, you basically get one innovation, and the number one innovation that you should be doing is your product, right? Any time spent innovating on management structure and many other things is time that could be spent innovating on product.
Edith: I initially thought I completely disagreed with you, but now I circled back and agree with you, so we talked about this in another episode, but I think you’re doing two things when you’re a startup. You’re defining your product, and you’re defining your culture. And I think where people go awry is when they try to be too innovative.
Paul: Yeah, you can have a little bit of innovation, you can decide that there’s going to be a pool table rather than the traditional ping pong table. But
If you spend too much time innovating, and if you spend too much time on that innovation rather than on your product innovations, you’re probly going to end up in a bad place.
Edith: Well, like Zappos is kind of struggling with this right now.
Paul: Their holacracy thing?
Edith: Yeah.
Paul: It did them well for many years.
Edith: They didn’t have holacracy.
Paul: Oh did they?
Edith: No. They’ve tried to implement holacracy and it’s.
Paul: Well like Google did the same thing, they fired all their PM’s in like 2001.
Edith: Tell me more.
Paul: Well, as I understand it, Larry, who was CEO at the time, said that there’s too much distance between the CEO and the engineers, so he fired all the PM’s.
Edith: Sounds like a line from Shakespeare, like first thing we do.
Paul: And then very shortly afterwards, Eric Schmidt was brought in as the CEO to be Larry’s like adult supervision.
Edith: And then?
Paul: Then they hired PM’s later.
Edith: Yeah, this reminds me of, it was at a company that got acquired as a product manager, and this other company had no product manager, so I was like, “did they take them all out and shoot them?”
Paul: Well, it can be like Circle, we just never hired PM’s.
Edith: But you have them now.
Paul: We have them now, because that was lunacy.
Edith: It was a limitation.
Paul: Yeah.
Edith: I think everybody has a different idea of what flat means.
Paul: Yeah. Have you heard of the Heroku way? This is something I’ve heard from several prominent, early Heroku people that they had this sort of unspoken thing about how stuff was done at Heroku, it was the Heroku way.
But no one ever defined what the Heroku way was. And whenever some team would go off and do things, their opinion of the Heroku way, basically they would get subtly corrected by Adam, and it turned out that the Heroku way was really like Adam’s vision.
Edith: So tell, what was the Heroku way?
Paul: No one ever knew. It was like everyone had their own idea of what the Heroku way. It was like flat, it was undefined, and it was just a disaster.
Edith: Yeah, I mean because ultimately it’s very harmful, because you don’t know what you’re working towards.
Paul: Right.
Edith: And you develop a culture, we talked about this before. If you have animals that get an unexpected pattern for food, they basically go insane.
Paul: Right. So you think flat is like insanity for engineers?
Edith: Sometimes, if what you said is if I did all this work, I wrote all this code, and you don’t like it.
Paul: It doesn’t ship. Engineers go insane when things don’t ship.
Edith: And well, when that happens three times and you’re like, what am I doing wrong?
Paul: You start to burn out.
Edith: Yeah, and you start to say fuck this, why do I come to work every day?
Paul: Exactly, right and that, very succinctly, is why flat sucks.
Paul: Okay, so you wanted to talk about Hacker News comments, but I have no idea what you want to say about Hacker News comments.
Edith: What do you think about Hacker News comments?
Paul: Modern comments? They are alternately phenomenally shit, and utterly amazing. I’ve noticed in particular, like Hacker News has gotten Reddit-ified. There’s a whole bunch of really low value quips that actually are what make Reddit really good. If you’re deep in the Reddit community, as I once was. I had a very strong Reddit addiction for many years.
Edith: As a poster or as a reader?
Paul: Almost entirely as a reader.
Edith: Yeah, those are two different things.
Paul: Yeah. But it’s very funny. And you often get the high quality humor voted to the top, it’s kind of low quality humor, it’s like puns and memes and that sort of thing.
Edith: Hey.
Paul: Let’s not get excited about puns. But it’s like Reddit memes, right. Someone says something that’s hilarious because it’s a pun on something the entire community understands. And people are trying to bring this to Hacker News and it’s just utter low value there. The thing that’s amazing about Hacker News is that people who really understand their shit, they’ll be a comment about “oh, Google did this and it was terrible, and someone was like, oh, I worked at Google during that period on that team and here’s how it actually went down”.
Or someone will say something about a programming language and then Walter Bright, who wrote D, will come along and say well, here’s how we actually think about this thing or the Rust team or all that shit.
Edith: Like when Atlassian acquired Trello, the Trello CEO was jumping in on threads.
Paul: Yeah, exactly. So, I think a lot of the value of Hacker News is that its sort of the community water cooler, and everyone who’s in the community is on Hacker News and reads Hacker News and you can’t get to the top of Hacker News without the people involved noticing and often getting involved.
Edith: Yeah, it was funny like, I was at a Microsoft event and the VP was there. One of the VP’s was proud they got onto Hacker News a couple times for some big news.
Paul: Yeah yeah, that used to be a thing for startups. I was talking to some people at Google, and I was like, what are your goals for this launch? And it’s like, well we want it to be number one on Hacker News.
Edith: But I think it’s kind of a vanity metric in some ways.
Paul: It is and it isn’t. If you do something which doesn’t rate in some way on Hacker News, and it’s for the developer community or for the startup community, is it really that much value?
Edith: Well, I guess something that we talk about is do VP of Engineering at non-Silicon Valley, if that’s your market, read Hacker News?
Paul: Should they, or do they?
Edith: Do they.
Paul: That’s a good question. I would say they probably do. So I moved to New York recently, everyone there reads Hacker News, just as much.
Edith: Well, not to pick on you, Paul, but you’re a little bit probly in your own little Silicon Valley bubble there.
Paul: Yeah. I went into the office one day, and people said to me, oh you’re number one on Hacker News. And that was people who I didn’t know. I don’t know how this happened, I don’t want to talk about this but like I had a thing where I was number one on Hacker News earlier this year, and everyone knows, because everyone reads it.
Edith: What were you number one for?
Paul: It was for It’s the Future.
Edith: Oh, it was resurface?
Paul: Yeah, sometime in in like August or September.
Edith: That’s a good article.
Paul: Yeah, it’s good, I liked it.
Edith: If anybody who missed it, they can go read it or check out our podcast.
Paul: Yeah, we did a whole podcast about it. So, that’s kind of a good example of it, that you see the people in the comments on that, you see a bunch of people who really understand the topics and can really dig in and explain how we got there, but also it’s mired with low quality comments and people who are being assholes and it’s getting a lot worse as well. It’s been getting a lot worse for seven years.
Edith: Yeah, I was about to say. I mean, I know that sometimes there can be people, just like with any anonymous board, you get people with axes to grind.
Paul: But even without axes to grind, I feel that there needs to be some form of curation that is more than there currently is. There’s upvotes and there’s downvotes, but there’s too much shit for the downvotes to deal with it effectively.
A standard comment that you get on Hacker News is people who just take the worst possible reading of what just happened.
If Google launches a product, there’s going to be a comment, guaranteed, that “oh, how long ’til they shut this down, I wonder if someone made an open source version of this, so they don’t shut this down”. And that brings no value to the conversation on the particular topic.
Edith: Wait, that Google will build a competitor.
Paul: No, that Google will shut it down.
Edith: Will shut down?
Paul: Well, whatever service they built, or acquire or. Maybe you get acquired by Google, and someone will be like, oh great, how do I export this?
Edith: Oh, I see what you’re saying So, your use case is somebody got acquired by Google, how long ’til Google shuts it down.
Paul: Exactly, that is the sort of comment that you would see on Hacker News, and it’s not valued to discuss that for the 17th time in a row.
Edith: Yeah, I mean it’s the one that touches a little nerve with me is people make fun of our company.
Paul: Right. I mean, you’re like a bullion flag as service, it’s kind of ludicrous.
Edith: We’re case management at scale, dude.
Paul: Case management at scale, okay. I had a friend in college who would make fun of our undergrad dissertations, and he’d be like okay, well, you fix the bug, you wrote a sorting algorithm, just give very small denigrating descriptions of what we actually did, and I feel Hacker News does that quite a bit.
Edith: Well, so I’ll say though, at the beginning, it annoyed me and now I love it.
Paul: Really?
Edith: Yeah.
Paul: You love people being dicks on Hacker News?
Edith: No, I love people making fun of what we’re doing.
Paul: Oh, because it means they don’t really understand the value of it and they won’t compete? It increases your moat?
Edith: Or that they’re like, “oh, my intern will build this in a weekend with two arms behind their back”. And I’m like great, they’re going to build a really shitty implementation in a year.
Paul: It’s wonderful to have the conversation after they build that. It’s like, all of a sudden you don’t really need to convince them of the value of your product anymore. CI is totally a thing that you could totally build in a weekend, right?
Edith: Yeah, of course. Except for why.
Paul: Except for making it actually work.
Edith: Yeah, so I used to me like oh, people don’t think this is important, now I’m like, “great. That’s fine”.
Paul: So, the problem that I have is not that they make these comments, right? It’s that they just continually make the same thing. I feel that ever since the DropBox launch where someone said, oh I can build this with R-Sync and whatever, right, there hasn’t been a single comment like that that has brought any value.
Edith: Well, I mean that’s why again, so we announced our round of funding and several people went off on protracted rants.
Paul: Right, exactly.
Edith: No, I mean like against like, this is so. Like, of course, we’re developers. We could build everything, but why?
Paul: Is your argument that there’s just little value to having that discussion?
Edith: No, I thought it was good that people are starting to fight back.
Paul: But even then, so I agree, great that they’re fighting back, but why have this discussion again? I see comments on Hacker News where I’m like I can write a response that says why you’re wrong because I’ve seen it, and I’m just like why, where’s the value with arguing with strangers on the internet?
Edith: If you’ve gotten tired of Hacker News. Have you gotten tired of?
Paul: I haven’t gotten tired of Hacker News. Because the good stuff on Hacker News is still really good.
Edith: What do you consider good stuff?
Paul: Where someone gives an insightful anecdote about the time they worked on that thing. Or where someone who works on the language itself or whatever the topic is comes in and answers questions on it.
And where those questions are asked in good faith and where someone’s like, I’m interested in how you dealt with the technical challenges of X as opposed to like, “oh this is bullshit, your product is shit because X” and then they have to answer from a defensive position, rather than everyone trying to learn stuff from each other. Actually, that’s it. Hacker News is great because it’s a community learning from each other and Hacker News is shit when people are subverting that for status and points.
Edith: So you like the Quora, not the Reddit.
Paul: Yeah.
