AA242 - Move Fast & Break Things: The Dark Side of Silicon Valley's Favorite Mantra
Arguing AgileDecember 24, 2025x
242
00:47:2032.56 MB

AA242 - Move Fast & Break Things: The Dark Side of Silicon Valley's Favorite Mantra

Is 'Move Fast & Break Things' just permission to be reckless?

Join Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel as they examine Mark Zuckerberg's (in)famous mantra and reveal how it may have metastasized from breaking code to breaking laws, teams, and even contributing to real human harm.

Watch or listen as we explore the critical dimensions of this philosophy, including:

  1. BREAKING SOFTWARE: How the original meaning of 'break things' (emphasizing first-mover advantage) evolved from rapid iteration of code to justifying regulatory evasion and monopolistic behavior.
  2. BREAKING TEAMS: Using Harvard research that shows 'always-on' cultures decrease productivity by 20% and spike turnover to discuss how intensity without recovery is just exploitation (and what to do instead).
  3. BREAKING PEOPLE: Discussing the human costs of unchecked speed, from Facebook's alleged role in the Myanmar genocide to Uber's systemic harassment culture to Theranos's fraud.
  4. LEARNING OVER SPEED: We discuss Eric Ries's seminal work: The Lean Startup and how it went out of it's way to emphasize learning velocity over shipping velocity. WRONG (we guess)!
  5. PUSHING BACK (WITHOUT GETTING FIRED): We brainstorm for frameworks to use for challenging speed-obsessed leadership, including trade-off and discuss real-world experiences.

Whether you're running a business, a product manager, or a team member just trying to keep up, this episode arms you with arguments and frameworks to advocate for ethical innovation.

What's your take on 'move fast' culture? Have you seen it more of a positive or negative?

#ProductManagement #TechEthics #AgileLeadership

REFERENCES
Move Fast and Break Things by Jonathan Taplin (2017), Careless People: A Cautionary Tale of Power Greed and Lost Idealism by Sarah Wynn Williams, The Lean Startup by Eric Ries (2011), The Fearless Organization by Amy Edmondson (2018), Susan Fowler's blog 'Reflecting on One Very Very Strange Year at Uber' (February 2017), UN Human Rights Council 2018 report on Facebook and Myanmar, Harvard Business School research on always-on cultures (2009), Agile Podcast E22 - Interview with a Scrum Trainer: Fred Mastropasqua (August 2021), Extreme Ownership by Jocko Willink, The Social Network (film, 2010)

LINKS
YouTube https://www.youtube.com/@arguingagile
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Website: https://arguingagile.com/

INTRO MUSIC
Toronto Is My Beat
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Brian:

So Hey, om, every time I hear a founder say, move fast and break things. Well, what I really hear in my head is move fast and break other people's things. AKA other people's businesses or maybe the law.

Om:

I sincerely hope it's not the law. Well, so that sounds like. Courage it, it sounds like innovation. But when you strip away the hoodie and the ping pong table, it's just permission to skip the hard work of thinking through the consequences.

Brian:

So you're giving me permission to be reckless and then calling that vision, that's what's happening?

Om:

That I think so, yeah.

Brian:

That's a good podcast then.

Om:

Let's do it.

Brian:

Welcome back to Arguing Agile. If this is your first time, I'm your host product manager, Brian Orlando. This is my co-host enterprise agility coach. To the stars, Mr. Om Patel.

Om:

Hey everybody.

Brian:

today we're talking about the Sacred Cow of Silicon Valley. Move fast and break things or move fast and break the law. Move fast and break your teams up.

Om:

Move fast, fall down. Maybe

Brian:

move fast and break your leg. Anyway, spoiler alert right now. Real early. Maybe I'll be on the Zuckerberg side of this podcast because I understand the appeal, the biased for action. The concept of just ship it and then we'll fix it later. we'll learn from the failure. We'll fix it later. I completely understand, but no, what I don't hear a lot of people talking about is using this mantra, can I say mantra? Using it to justify everything from toxic workplace culture to actual human harm. Like we don't get any money from it. So by the end of this podcast you'll understand how to spot, when the bias for action becomes the bias for recklessness, or if that's your starting position. You'll understand the arguments to push back on the speed obsessed leadership as a culture. Yeah. And then we'll talk a little bit about how this framework app applies Moving fast safely. Yeah. Safely without breaking people in teams,

Om:

people and when you understand all that, let us know. That's right. Yeah. For that you need to like and subscribe

Brian:

So you know, who invented Move fast and break things? Well, it was friend of the show, mark Zuckerberg. That's who it was.

Om:

Yes.

Brian:

And you know what, Facebook was breaking at the time when they came up with that mantra.

Om:

Pretty much everything

Brian:

I was gonna say, they were doing hot or not, it was privacy laws on campus that got, if you ever watch the social network that got them pulled in front of the review board or whatever. Yeah. Privacy laws, but they weren't really laws, they were more like guidelines.

Om:

Well, this is gonna be a juicy one today.

Brian:

I'm trying. So in jonathan Taplin's book Move Fast and Break Things How Facebook, Google, and Amazon Cornered Culture and Undermined Democracy 2017. It documents how this philosophy enabled monopolistic behavior and regulatory evasion. and I don't think this book talks about the genocide. I think that's another book. Yeah, it talks about the genocide. But we're gonna go straight into the steel man I think this is where we need to start with two big points here. perfection, like perfectionism, voice of God, like building too long, like all the quality in the world like this, this hits me straight in the fields as a QA person is, listen, we don't need perfection. the four letter word that people will use against qa, people that's gonna kill the startup, that's gonna bankrupt us shipping beats planning, number one, and number two, before I turn the floor over to you First. Move for advantage requires accepting that some things are just gonna break. two solid points there, that you're gonna have a hard time pushing back on is like, listen, we can't be perfectionist. We gotta get something to the client. ASAP. We need their feedback. We know it's not gonna be perfect. They know it's not gonna be perfect. We've had a discussion and let's just keep going. And first mover in the market, we can make some serious impact where other people are all gonna be following us.

Om:

So this one, right? Perfectionism. Yeah. Ship it. That's what pays the bills, right? Okay. So ship fast, but if you're shipping crap, it will come back and hit you right? Sure. So that's the thing. Yes. Okay. You'll get first mover advantage, but you can't capitalize on it unless the quality is there. Where have we seen that before? Right? You think about some of the horror stories out there with software that just doesn't hit the mark initially, and there's some growing pains that a company has to go through.

Brian:

Well, I can tell you like the first, this one's for IO here is like your two things that we pointed out. if you're not following from the steelman points where perfectionism kills your startup and you need to move first over everything else. That was your two points. So number one, break things in the complete Zuck form. Sorry, I almost said suck. it was so, they were so close together. I mean yikes. Anyway, I might cut this out. break things originally meant code it, only later metastasized into breaking trust in your teams and maybe conduct. Between male and female employees, or female and female employees, depending on what book you read. And, and, and, and also laws. Yeah. And maybe a genocide or too like, like that, that like, that's breaking things. But also like first mover advantage you see here in our bullet points here, that doesn't mean anything if you get sued out of existence or if you have a PR nightmare on the scale of, I don't know, starting a genocide like that.

Om:

Yeah. Really that, so those two points, breaking things meant code at one point and now it's way more and it has real impact for a company, right? It's not just that you put out a version of the software that blew up or whatever,'cause that can be remediated, and you get a little bit of leeway with that because you were the first, and you go in and quickly fix things up.

Brian:

What if it blew up with the dictators all around the world?

Om:

that would be completely different.

Brian:

So what if it blew up and started a surveillance state mechanism that nobody can say no to monetarily. What if that's to your evil plan?

Om:

Well, yeah. I mean, look, if that happens and you get caught, you just have to send out your forward deployed engineers to go fix it.

Brian:

Oh, that was so good. Thanks for coming to the live podcast. my only regret on this podcast is I was like, there's, I was like, we're gonna get here late.

Om:

Second point though first mover advantage is nullified. If you end up with a bunch of lawsuits and a PR nightmare again. So true.

Brian:

But the third point here that, that phrase, Hey, move fast and break things , that gives you a lot of leeway to skip your diligence and really any, I mean, testing assumptions, anything else to be like, oh, this is just agility. This is, we're just being agile. We're moving fast and breaking things.

Om:

yeah. So this is where the proponents would say we're failing fast that's exactly we learning, right?

Brian:

Ever since we did with Ed, we did the extreme ownership, like the Jocko as podcast. Yeah. This has been stuck in my head of people exploiting extreme owner. To be like, well, you didn't own it hard enough. That's right. You didn't stay here nights and weekends and sleep under the table enough or , oh, also I'm gonna be playing golf while you work this weekend. Like this is, this is so good. the product side of this where I can I could live all day. We should probably move on because like, I, I could live all day on this point of speed without direction. Like it's, it's just chaos. It's just chaos and, and, and it's expensive chaos. Yeah. Meaning that like, your teams have to spend all their time to solve these problems while, whoever is creating this chaos in the environment and just like going along with their golf game or whatever, they're not dealing with a lick of responsibility.

Om:

Even in this container where you are going through like brown in motion. Right. Nowhere practically. But yeah, those guys are nowhere to be seen. Maybe they're out there on the golf course, like you said terrible, terrible situation to be in.

Brian:

Move fast and break things like, it's, it's an excuse to ask for forgiveness, not permission wearing a Patagonia vest. Ooh, you like that? That's, that's, I like that one. That's my, that's my shots fired on Silicon Valley right there okay. So someone walks in and invokes move fast and break things, let's, let's hit him with some ground rules. Let's say like, this'll be the Rick and Morty Rick tearing off the wallpaper meme. that'll be what this is. Yeah. Like some, some says breakage audit. Yeah. Yeah. It'll be move fast and break things will be on the left side. Yeah. And then when he tears the wallpaper off, what would be behind it? It probably would be something along the lines of, a couple questions. First of all that I can think of. It would be number one well, what do we expect to break? there'd be some documented assumptions and you should do this before you build anything anyway. What specifically might break? What, what are the assumptions? what do we think is gonna not break and what do we think might break? And that's okay if something that broke is well out of the scope of those things, but at least we're thinking about our effects and then number two, who might get. If this breaks that, let's pretend I'm a busy product manager for a moment, boy, here we go. The kind of product manager that is just checking into your standups every so often, blowing through your sprint reviews every so often, barely has any time for your team just says like, I can't believe this took the whole sprint. This, I just thought it was gonna be a two second fix. that kind of product manager. I'm this kind of product manager I'm thinking about users and saying, Hey, if we implement this and it doesn't go over well, or something happens, who bears the impact? Who bears the brunt of that impact? So meaning we are thinking about the users. Actually having some empathy.

Om:

Yeah. That user empathy side of it. I think it behooves the product manager to, to do this with the team. Really? you can't see all dimensions, right? So maybe have a little time with your team and say, what can potentially happen if things go south here? Right. Who's gonna get hurt?

Brian:

And then how hurt.

Om:

Right is it, is it irretrievably? The situation is just so bad. And it's, maybe this doesn't happen or won't happen, but it's good to think about it. So you're prepared.

Brian:

You know, that's, it's kind of crazy 'cause like you have all these fields in Jira that are useless anyway. Like I mean could impact be one of them? Like you have story points. You have business what's it called? Business value or some, something like that. Like you have a bunch of like built in fields in Jira. Sure. I mean, impact might be one of 'em. Or CRI criticality might be one of 'em. I don't know, maybe you want to do this. maybe if you're like, well Brian, I'm just building like FinTech widgets to let people make like faster stock trade or whatever. They have impact. I mean, maybe it's not like life, health tech stuff where people's eyes are on aligned Where going physical harm to them they're gonna lose a trade. They might lose a million dollars or whatever. Maybe they have a level of impact. I don't know.

Om:

Sure

Brian:

anyway, like this, that might be a good way to think about it, what Are you listening to this or watching this? What do you think about it? Let us know in the comments if you found this useful or what the next logical step might be.

Om:

Yeah. What have you found in your experience around harm that's caused by people running too fast?

Brian:

So speaking of running with scissors, if this is sketchy, then let's talk about execution. Let's talk about what actually happens to teams when leaderships adopt this as a mantra and a mindset. Let's talk about moving fast and burning your team out, moving fast and breaking your team. It really should be moving fast and breaking your team. I don't know why it didn't take two seconds and fix the slides, but you know what? We're moving fast in this practice.

Om:

Are

Brian:

moving fast and breaking the law.

Om:

So research found this was research done by Harvard, I believe back in 2009. found that always on cultures decreased productivity by 20% and increased turnover significantly.

Brian:

Not my culture, though we're special, we're unique.

Om:

We are just so far apart from the crowd. It doesn't impact us. Laws of the universe don't apply as we're saying here.

Brian:

boy listen, I got you. I see where you're pushing me into this podcast, and that's straight into the steel, man. So you know what? I got you. Here we go. Steelman points. Here we go. I got two of them. I feel they're one of 'em is good. One of 'em is, eh.

Speaker 3:

Okay.

Om:

Okay.

Brian:

And it's number one, listen, high performers, anyone who claims to be a high performer, they thrive under pressure and urgency. I would say like good leaders, should be constantly, creating a fake sense of urgency, just so people, Always feel the pressure. And then the second point is that in a startup. You're signing on for intensity, you're signing on to wear multiple hats That's the deal. Expected. Absolutely. That's the deal of a startup.

Om:

Yeah. So, yes this is expected if you're in a startup, right? This is why you have a gazillion you know, shares or whatever that one day will hopefully be worth more than Oh, oh, is that, is that what you, this is paper.

Brian:

Is that what you're getting a startup? Like, I know, I'm pretty sure I could go around the offices here and ask people, Hey, are you getting equity?

Om:

I'm talking about household name startups, right? So to retain, attract, to retain talent, that's one of the things they put out, right? Yeah. Anyway, people will swarm to these like beast of Honey or Honeycomb.

Brian:

I'm gonna be Your Beast of Burden. That's what I'm saying right now I don't know listen, I've been. In a couple startups, I will tell you. And the idea of intensity without any kind of recovery period I mean, it's cool as an idea, but in reality, like you're, squeezing people. Let me come to the point. you're exploiting people is what you're doing. And people are only gonna stick around so long being exploited. I hope your incentives really match. That's what I'm saying, because people can burn themselves working 60, 70 ish hours. And they can burn themselves working like that for a period of time, but not forever. However, I've been on many teams that can stick together and work in an indefinite amount of time at a. A solid pace that outworks a lot of other teams, but that pace is sustainable and the team and the team members together have figured out what sustainable means and nobody from the outside can push

Om:

they figured it out. The, the team's probably been around a long time together, right?

Brian:

Right. Well, oh, I didn't really explain my case very well. My, in my case it was the, the grind was you get eager new people in, you pay them less than the market tells you that they're worth 'cause that's, that's your culture. Sure. You get more junior people who are or, or more desperate people that are looking for jobs. Hey, shout out to all your startups get ready to, to, to catch onto my (evil) hiring practice here. And then you hire them in and then you burn them for 2, 3, 4 years. Yeah. And then they burn out and quit or get pushed out by your organization. And then you get new, younger people in

Om:

Yeah. So do the same. I've seen leadership you know, say things like, well that's the duration these people are good for. They're expendable. Yeah. It's terrible agriculture to be in.

Brian:

Actually, there's businesses built completely on this type of cycle for sure. It is rumored. It's not our opinion at all, but it is highly rumored that the people that work in the Amazon warehouses, like the actual, delivery folks and the people that work picking orders and stuff like that, are under such tight deadlines. And you can go read articles about this stuff where they're like, they can't even use the bathroom 'cause Amazon doesn't, they want people, they don't want long-term employees doing the job. They want this churn and burn kind of thing.

Om:

Yeah, yeah. Again, allegedly. Allegedly. So I've heard, yeah. So I've heard. Yeah. Yeah. So, so this, this kind of a, this kind of a culture so bad. Mm-hmm. If you've ever been in one, it will be indelible in your psyche For the rest of your career. it's a terrible way to treat human beings. Amazon or whoever it is that, wants these people that do not even breathe. Yeah. they should just develop robots. I mean, oh wait, I think Yeah. Oh boy.

Brian:

The high performers, they think, oh, they thrive under pressure. Oh, they thrive under pressure. I mean, it's, it's like I feel that that point is, it's like it's abuse so much, man. It's like, it's, it's like sure. One off pressure and real instances of like criticality like outages or like big upgrade type of launch events or stuff like that. Sure. Every week, every weekend

Om:

people are elastic to a degree. And so for fear to stretch them a bit during those times when you're really wanting them to be there times of outages or emergencies or whatever it might be, what's important for them to function well in that space. More of a sustainable pace outside of that and the

Brian:

sustainable pace. Like sustainable pace doesn't mean slow. That it doesn't mean slow, it means it truly means sustainable. It means I can keep this team together working on this thing, and they don't get burnt out and they don't leave. And because like, the best people, when you press'em and you treat them badly, like they got options, they can go and work anywhere else because like their skill and they're cool to work with and they're, they're like, they're curious people and they get along and they're, they're flexible, whatever, but they don't like being abused, so they'll just like, rather than trying to change the system and start a fight or do whatever, they'll walk.

Om:

That is the easy way out. Rather than change the system, most people who cannot change the system, they believe at their level, they're just gonna find, like you said, other options.

Brian:

I think about a firm that I was at when I was a manager, I was a manager at qa and the company had been bought a couple times by private equity. And like the pace just got more and more insane over time to the point where I. Again, this like, just move fast. just ship it don't, like this is the QA group, by the way. Oh, goodness. So they wanna know that things are planned. that we've like, thought about the future and like, that's just not what PE is just pressing you for like the next big bang. You know, the thing that we can tie our price increases to. Sure. The integrations and partnerships that we can upcharge or charge more or charge an additional fee or an add on to the base rate or whatever. Yeah. And it was just like every month was a new thing like that, but the development team was only like a dozen people. Like, it was not a big deal. I mean, they really needed like a three dozen person development team. If they wanted to launch brand new integrations, like I'm talking core add-ons every month. We, which we could have done. Again, if you would've put the money in the organization, but it was just like, no, there's no money here. You know, I mean, unless you want more salespeople to go out and try to bring leads in.'cause that organization was strongly understanding of these are the people that bring the money in and these are the cost center people. And the cost center people were capitalized over three years and then it was seized a cost center. So it was like their thinking was really like stuck in stone, never gonna change. And again, like the best people were just, they were just gone, you know? They were gone as soon as possible. And I remember people leaving because they didn't like this culture. They didn't like this grindhouse culture.

Om:

Yeah. So the bottom line is, as an organization, you're gonna lose some good talent And it takes, there's a cost in getting new people in and bringing them up to speed all of that is really hindering your progress, isn't it?

Brian:

I mean, and not only was it hindering the progress, but it it, it was like, clearly you can't sprint your way through a marathon. Absolutely. It's, it's a marathon. Yeah. So you, you can move fast, but you can't move fast your way through developing what should be a 10 year company plan and positioning in the market, that's like slow, intentional strategic work that's just not possible with this reckless type of thinking at the highest level of the company and, and especially not with this burn everyone out. We'll get quote fresh people in. Yeah. Meaning it will exploit new people.

Om:

Gone. New blood, that's what they say, right? New blood. We need new blood.

Brian:

There's some points I have written down. I put 'em here. If you're a leader you do the sustainability s sniff test. You ask when was the last time that this team had a slow week? Nobody asks that. Nobody asked that. But when was the last time this team had a slow week? Number two check are your best people updating their LinkedIn? I mean, that requires you to be paying attention to anything out of your little tiny lane other than your, your day to day. Right? And then I will tell you this is the best piece of advice we're gonna give on the podcast right now to. And then number three here is is the measure, ask, check measure. The measure is track the unplanned PTO. In sick days, if you're a manager, you're gonna be doing this. So I certainly did. Yeah. If you're a manager, you're gonna be doing this track the unplanned PTO in sick days. Yeah. And you'll, you'll find who is taking the stress days as sick days off like that, that those, those, that's, that's a solid. I like that one. Those, you'll find your canaries in the coal mine just by doing these simple things of, hey, like we're getting close to you know, straight up rebellion and I mean, . If you're not paying attention to these things, I mean, What are you doing with your time? That's what I'm asking. Yeah. I mean, fostering burnout, that's what you're doing.

Om:

That's exactly what you're doing

Brian:

of course. Yeah. Well, I mean, you can't say it. You can't say it. Yeah. You can't say it because we're moving fast and breaking the law. That's what we're doing. So what about this section interests you and let us know in the comments. So burnout, it's the internal cost. it's the human cost. That's what we're saying. But what about the, emotional damage? That's,

Speaker 3:

Ooh,

Brian:

where does that meme? Let's talk about what happens when Fast, when Move Fest actually meets actual humans being humans outside of your company. let me talk about what happens when move fast and break things actually applies to people. Move fast and break people. That's what I'm saying. Facebook, Facebook's algorithms. This is the, this was the the book that we never did the podcast on about what's it called? Sarah Win Williams. What's, what's the book called? Sarah Wynn Williams, careless people, A cautionary tale of power, greed, and lost idealism. that's what I was looking for right there. In that book, she talks a little bit about how Facebook's algorithms amplify the genocide in Myanmar. How and then and then that's a real thing. I mean, in the research for this podcast we read about Uber's move fast culture that enabled systemic harassment. Susan Fowler's her blog titled, reflecting on one very, very strange year at Uber from February of 2017. And then, of course the, the famous Theranos, oh, Elizabeth Theranos Move Fest and lie about your product. Oh boy. Who, how about having a product? Is she still in prison? Is she, I don't know. One pair of bands later. there may have been some more stuff cut out of the preamble to this section, but at what point do we admit that this philosophy it's got a body count. That's what I'm saying.

Om:

Well I almost don't wanna say this, but I've heard people say things like, well, people. Let's get new people. That's just, they're just basically

Brian:

collateral damage. We'll, just like, we need fresh people home. We, we need fresh. We, we do, we need fresh thinking. We need new energy. Fresh energy. Fresh energy. I can't remember. These are all

Om:

euphemisms for yeah. Replacements for people that just have had a,

Brian:

listen, you don't have to believe us, the UN Human Rights Council in 2018. cited Facebook's platform as, quote, contributing to the spread of hate speech that fueled violence. And you can go read all about it in those books that I referenced. So I want to jump into the steelman, I'll present the steelman. Go for it. And it's gonna be pretty easy because it's just two quick points. Hey, unintended consequences. or second or third order consequences. That's not what we intended. So you can't blame us. It's not malice, a forethought because all these other people got affected by this thing we didn't have malice intended. We didn't mean to hurt these people. And like in the Myanmar thing we weren't the ones running an authoritarian dictatorship over here that's not our fault.

Om:

right.

Brian:

Like that, that's that's point number one. Sorry, they're both bad points I'm gonna throw away. And then point number two is listen, like why didn't the government step in and regulate us? Why, why didn't somebody step in and stop us from using these weapons? That's, that's what I'm pointing out right now. Listen, I didn't tell you, I didn't say they were good points. That thanks Ayo, that there are arguments. Here are the two of them. Sometimes there's just not good arguments. That's what I'm saying right now. That's just the way, that's just the way it is. The way or lives. This will be a, I feel this would be a fast category because there's not a lot of good arguments in there.

Om:

There's not a lot to say, but people should think through at least some of the consequences perhaps. You know, maybe you can't avoid damage to the degree you should. Maybe you can contain it a little.

Brian:

You can blame Britney Spears oops, I didn't, again, you can break anything. This is a terrible category, like the waiting for regulation I mean, like your excuse for waiting for regulation. That's the same thing as like Uber's excuse of, well, we won our case against the black cabs, so it was always legal. Like that could have went the other way and then they would've been back to point number one of like, oh, it was unintended, but you knowingly broke the law.

Om:

Exactly. That's what I meant by thinking through a little bit,

Brian:

I mean you're, you're moving fast, you got no ethics, right? You know, you don't really care who you're hurt. I mean, it sounds very sociopathic. If your business model requires you to exploit people, right? Like, or, or break the law, right? You don't have a business model at that point like this. This goes into a whole different podcast that I want to have. Beyond that, there's another podcast I want to have about something that somebody said. Something somebody said at one of our networking events, like gamification is great, or something like that. It's like, yeah, gamification is great. I'm like, gamification is stupid and terrible. And also, like hooks onto that, like 5% or 3% of the population, whatever that has like the actual like gambling addiction. Yeah. And can't help themselves. Like those are the people that like pay for gamification in apps. Like I could, there was a bunch of people recently that were on LinkedIn saying like, oh, I went to this country and I was like, a top 1% or whatever in Duolingo. And like, I couldn't even speak a lick. Yeah. the point of their posts was not gamification is really not a good mechanism. for learning it's actually a good mechanism for keeping you addicted to doing it thing. That's exactly the point

Om:

Duolingo doesn't aim to make you linguists, right? Yeah. they aim to keep you hooked. Keep doing the app. Yeah. Keep you in the app. That's exactly it. And they succeed

Brian:

I wanna have a different podcast. Yeah, that would be a good one. That just talks about gamification and the podcast will be something along the lines of like, gamification is evil actually. If you actually sit down and think about it, Hey, how can we hijack people's brain mechanisms for the few people that are addicted to gambling? How can we hijack that? How can we get more people addicted to gambling?

Om:

As a business model, you're basically just like externalizing consequences onto the powerless people.

Brian:

Yeah.

Om:

Terrible.

Brian:

Well, I mean, you say terrible, but also like, Hey, we got widgets to sell.

Om:

Those yachts won't buy themselves.

Brian:

Those Palantir executives, like they, there's no way they can afford this amount of cocaine unless it's, it's an Adderall addiction.. It's not cocaine. That's right. So in terms of a story where like customers were harmed or whatever, I can't think of any customers being harmed, but I can think of a product that we shipped that was way too early. we really didn't understand enough about the market and we shipped it because there was a regulatory law going into effect that we were trying to beat the clock on the law. This was back when I was in logistics. there was a mandate for all trucks to have electronic log. That software required you to ship the hardware and software to test and ship the hardware and software at the same time. You can make changes to software or whatever, but, if the hardware's not aligned when you ship like you're gonna be way behind and the cost of updating your hardware is massive because then you gotta back Sure. You gotta bring the trucks back in and yeah. What are you gonna do?, , you're either gonna pay for the users to get the new device for free, or you're gonna force users to upgrade and then you're gonna create a bunch of friction with your users 'cause around the version one of the device and you came with version two and we came out with version one of the device and it just wasn't good. It just wasn't good. And these logs determine if someone is in legal compliance to drive or not.

Speaker 3:

Hmm.

Brian:

So we shipping bad software. did it cause a lot of pain and confusion and upset users? Absolutely. Absolutely.

Om:

What about an example where ac company ships you know, self-driving software for the cars?

Brian:

I can't even wait to like this has not even been a thing about the self-driving stuff. And, actually a little bit has been in the news about the self assisted suicide chat, GPT stuff. Yeah. That's hit the news occasion. Like it kind of gets buried in the news. Doesn't like the, the, but, and same thing with the self-driving. Like there, there's been a few accidents, like fatal accidents with self-driving and that stuff never bubbles up. Like, who's at fault there? That's a tough conversation that there's no winner in that conversation on either side. the companies are obviously gonna stop innovating if the companies are held at fault. And then on the other side, like someone died Like, do we believe a human life is worth an infinite amount of money? You don't know what that person would've been capable of, right. do we believe that as a base? Or not?'cause if we don't, I mean, what kind of statement?

Om:

So if you've looked at those examples, you where, you know where the chips fall, it's the companies are not held at fault necessarily. You, they come out and they apologize profusely. Mm-hmm. Fix up the bugs or whatever it is. Or, or don't fix the bugs, but you know, that they continue going along their merry way shipping, self-driving software.

Brian:

Sure. So like in, in the case of a, a major airline corporation, when one of their knowing bugs kills a bunch of people, that they're, they're immune.

Om:

Yeah. They are immune.

Brian:

I would say if you disruption, we're gonna build the newest, latest airplane that's what we're gonna do. If your disruption requires a bunch of class action lawsuits to basically stop you or to pivot your strategy, I don't really think you're a disruptor. You're not, I don't really think you're an innovator at all, actually. I think, you're a defendant at that point. Yeah, you are. And rightfully so.

Om:

There's a whole bunch of pharmaceutical companies fall under that category too.

Brian:

Oh, maybe they should. So. Hey, can this be avoided? Like, first of all, if you're a product manager, you're on a member of development team, and you've got your company pushing you to do this, like very risky type of stuff, the very heavy stuff we talked about in this category. I don't know if this can be avoided, but i'm gonna throw on the screen right now, a couple things that maybe can help you try to avoid this stuff. Hey, before you, before you run any of these major type of launches run, run the headline test. You know, the best case headline, Amazon does this with the, the, the press release before they kick off. Yeah. A project of like company X launches X, Y, Z innovation or X, Y, Z feature to their new software or whatever, right? The worst case headline, right? Who, who you cause harm to, what group you cause harm to. And then you ask yourself, if the second headline runs, can we defend our position and our process, or just our initial intent. Now, maybe you don't care about this as a team member and maybe your executive is just pushing for more, faster, whatever. Maybe they don't care about this, but as a product manager, you should care about this. As a marketer, you should care about this. Absolutely.

Om:

and this kind of an exercise, honestly, it's not very onerous this is not a huge lift at all. So what's the excuse for not doing it? I mean, I guess, right? Well, you should be doing this.

Brian:

Mean, the excuse for not doing this is you don't care

Om:

well, yeah. Then you're not gonna do it at all. And by this

Brian:

I mean people.

Om:

Yeah.

Brian:

So the human costs wow. we don't hear about it a lot. Even if it ends up being a small section in this podcast, I want it to land somewhere in the podcast. Sure. So we can talk about the human cost. So we cover the human cost. What do you think about the human cost? Do you even talk about it at your company? That's what I'm interested to know. Let us know in the comments.

Om:

If you do still, let us know why.

Brian:

All right. So we covered the human cost. So let's talk about the version of Move Fast that actually matters. And that actually should mean something to you. Let's talk about move Fast and the learn things. That was only because I can't use the four letter word I want to use in the slide, it should be move fast and quote, learn things. Eric Reese in the Lean Startup 2011, by the way, he explicitly states like validated learning over raw speed. Yeah. Like the goal is a, a velocity of learning. The goal is not the velocity of shipping. And here we are many years later, like over a decade later, and like Eric Reese, who's that guy not invited to my party, can't learn anything from him.

Om:

Should know that song.

Brian:

So if we're talking steel man, then we're talking hey, oh, learning loops slow us down. Competitors, they're not gonna wait on us to quote, learn.

Om:

Oh man, this one really gets me every time I hear that. It's, I mean, listen, so what will you do, right? You just gonna be reckless. A wrecking, wrecking. Well you are shipping things like maybe the Disney rides. You're not gonna test them thoroughly. Let the customers test for you.

Brian:

We call those fair rides

Om:

Yeah.

Brian:

I mean, the learning loop slow you down. that's basically the, I have it listed at, I had it listed as two points. It's really the same points. It's analysis paralysis. that's what the claim is oh, you're just gonna be stuck in analysis. You're gonna be doing retrospective over and over again. we're just gonna like, get together and send our forward deployed engineer in there and they'll learn with the customer and they'll just, yeah.

Om:

Right. So there's a medium in between there somewhere, right?'Cause otherwise most companies will be like gone by now. Analysis paralysis suggests that you're really just not moving much, right? There's a case to be made for just enough analysis And then getting on with things. Which suggests that analysis isn't something that just is front ended.

Brian:

Thing is the, the same people that are using this as an excuse, oh, learning loops, oh, they're, they're, that just retros me. That's more meetings that just slows you down. But they're, they're the same people saying that like, oh, we just need like less meetings. We that's, that's just, they're the same people saying I don't need retrospectives.

Om:

Yeah. They're pushing the efficiency angle

Brian:

and also they're the same people that are saying like, well, we don't need like scrums just a bunch of meetings. We don't need that. The funny thing is like if you are using Scrum out of the box sorry, not to go back to episode 22, whenever Fred was on, arguing Agile 22, August 31st, 2021.

Om:

Wow.

Brian:

By the time he came back out. That episode was super early. The funny thing is they'll use this excuse to be like, oh, scrum has just got a bunch of meetings. It's a framework and we don't need, we can move fast. We don't need all that. It's funny is like, well the point of using a framework like Scrum is there is time built in for you to do the retrospective, whereas in this other culture where you're not checked there, there's no checks and balances, your manager says, you don't need to, you don't need to. I'll tell you what was wrong. You don't need to do a planning. I'll tell you what the next thing you should plan is.

Om:

The teams like that absolutely do not learn, right? They're just simply doing. They're too busy doing. And they're going somewhere with eyes wide shirt, don't know where they're going.

Brian:

Hey, going to a party where they might be nevermind. No, no, let's not go there the points here the learning loop, like it's not slower. It prevents rework. That's the point. It prevents re rework in the form of you don't repeat the same silly mistakes. Mm-hmm. If you're doing it right, if you're treating the retrospective correctly, you're, you're learning something and you're not making the same mistake again and again and again. Right. As opposed to we're gonna move fast and break the law and hopefully our lawyers bail us out or some other team bails us out. And then the analysis paralysis one like that. It's not recklessness, it's time boxed experiments. And if you're not time boxing, then like, what, what are you doing in your life? Right? You like,

Speaker 3:

Yeah.

Brian:

Winging a prayer, like a look and a feel.

Speaker 3:

Ooh,

Brian:

gimme a feel. Like what, what are we doing here? The fastest path to product market fit. Like it's learning. It's, it's this, it's a time box. You're learning, figure out how long you need to do a thing or figure out what you need to see or not see and then pivot.

Om:

Just move fast

Brian:

move fast

Om:

Disagree and

Brian:

commit, but get outta my office.

Om:

Yep. it's your fault.

Brian:

That's right.

Om:

You didn't owe that hard enough.

Brian:

Ah, the fastest way to fail is to move fast in the wrong direction,

Om:

like it

Brian:

move fast and break things. Is there a better. Mantra, then move fast and break things. I don't know if there is . here is a define build measure. Mm-hmm. That was my little cycle. Define, build measure. I mean, honestly, now that I read the three things that I wrote here, it's not much better than the Deming pd SA plan, do study, act cycle. Right. Define, build, measure plan, do, study. Act is pretty good.

Om:

Yeah. But it gives you the option to do something else at the earliest opportunity once you've learned something that that's really what it's all about right. So you're not gonna keep going because that's expensive.

Brian:

So I don't, I don't know a better framework than plan, do, study, act, and I think that's it. I don't think a better one's been invented. Like the OODA loop is basically plan, do, study, act with different terminology. They sort of were invented around the same time. So who knows what came first. Doesn't really matter.'Cause they're basically the same. So like I'm, I'm gonna leave this one here especially since I wanna move on to the last juicy category. Ooh. Before we get outta here, but before we get outta here, let me know. Plan, do, study, act. What's your plan? How do you implement, plan, do study, act in your organization or do you even do that? So listen on the comments because I wanna move on to how do you actually push back when your boss or your executives or board or whatever are chanting move fast.

Om:

Yeah. How do you push back? We doubt sacrificing yourself.

Brian:

Sorry, sorry, I capitulate. No, I just needed some tip over

Om:

your king on the chess board.

Brian:

I just needed a minute, a minute to, I know, to slide up on the screen. I was like, how do you push back without getting fired? So I'll turn this over to you.'Cause I have no idea. I just get fired. That's what I do.

Om:

Well, I think we should say that Amy Edmondson wrote about this in her book, the Fearless Organization. Back in 2018. She found that teams who can challenge decisions without fear outperform Cultures by significant margins. So she's done the research. You can go read the book the steelman argument here. Leaders have context. You don't. So trust their vision. Just go with it 'cause they're there for a reason. They're leaders. So it is supposed to just follow. And any pushback that you have is deemed as slowing momentum. You are a problem person.

Brian:

All right. I'm gonna need you to work on Sunday as well. Trust division doesn't mean it's like it's turn your judgment off like a light switch. we hired you for your expertise and your skill and everything. Now shut up and get to work like you disagree and commit shut up and get outta my office. if you are a leader, if you wanna be a quote leader, but you will accept no form of dissent. You're a

Om:

dictator, you're not a leader at that point.

Brian:

Like I got, I got stronger words than that, but yeah. We'll leave it at that. For people in this position, Framed as risk management. That will be seen as due diligence. That will be my pushback on the leaders have context and you don't, but also like, as a product manager, why do the leaders have all the context and nobody else has the context? Yeah. why are you saying you're the bottleneck for context in the organization. You absolutely should not be,

Om:

you should strive to not be that bottleneck. You shouldn't be in the middle of anything. You should create the environment where you're not the bottleneck.

Brian:

Right, right. And the question here the question here should not be like, should we go fast? It should be what are the trade-offs at the speed we're moving? Go back to our earlier category where I said, who gets hurt? Like the little framework that I pointed out? Because your job is to make those trade-offs visible and then to let leadership weigh in. On those tradeoffs or to give leadership the first right of refusal to give leadership the ability to weigh in when you're say, Hey, I, as a product manager said we're gonna do X over Y and this is the reason. And then you present it to them and let them push back on you or not. Yeah. And then whatever happens, happens., At least you've done your diligence and of course, as always, keep your documentation And your resume updated.

Om:

Absolutely. Didn't think I was gonna get that one in on this podcast. I, I knew we would at some point. So your job really is to make the tradeoffs as it was you said, right? And if you say, if you just don't do anything silent kind of capitulation that's really not the answer here. This isn't a breed, that kind of culture, even more leaders feed off of that.

Brian:

Yeah. I recall being at a company one time that had deep deep technical debt. And of course, the company was in the early rounds of funding, so they just wanted more and more features. They did not wanna stop and refactor any database or anything like that. But I remember making the case to the C-level executives. I remember coming into a panel of C-level executives saying, if we don't do X, Y, and Z, it was really just like one big bang update. If we don't take like, three weeks, three weeks to that company was like an ice age. Basically. If we don't take three weeks and do this database update if we don't do this database refactor, then all these features that you wanna do down the road. I, I basically did, I did a, a analysis of features and, I put all the stuff that couldn't be done until the database upgrade had been accomplished on the other side of those features. So basically I took the whole roadmap.

Speaker 3:

Yeah.

Brian:

And I said, here's the things you can accomplish. And I put 'em on the left side and I said, here's the things you can accomplish that need this database upgrade. Put 'em on the right side. And I said, outta the things you can accomplish, none of them are as important as anything on the right side here. So now is the time. We didn't do it immediately, like that day. We did it like a week or two after. But we did it very soon. A couple quick wins. And there were some other tricks I had up my sleeve. I was like, we can do a couple quick wins while the database refactor is going on. Luckily, we had test environments and we had prod environments, And we could cannibalize one of the environments to have it be like the middle environment. The point of the story was we did this major refactor without downtime, without sacrificing strong speed in the forward direction. But we only did that because like I made a strong case to the executives of like, your future is on the other side of all this stuff that you don't consider valuable. We don't have to do it. First of all, we can keep chugging along, but it's gonna become so difficult to do any coding and feature enhancements and stuff. And the system performance is gonna get terrible. The more users we onboard that I would rather stop now at the current revenue we're at. Do this big refactor and then kick this can down the road two years or whatever. Yeah. You know?

Om:

Yeah. I think the important thing in that story is you made them realize the cost of not doing it right. Which is you can't use all these features, put 'em into production. So don't just dissent just make sure that you have evidence of some kind, or at least some rationale. and if you don't have clear evidence, some rationale of what, what you're giving up,

Brian:

and the point of my story was I took a big risk supporting, like I was on contract at that company. I took a big risk digging my heels in and saying, we gotta do this big technical, basically we gotta stall all of our new features. Because they already didn't trust, I was the first product manager at that company. They already didn't trust the development team because the development team had been telling them for months Yeah, we gotta stop everything, stop for six months, refactor all this stuff. And that's just like, maybe that's what they would need to completely turn over the system. But because I'm deeply technical and I just happened to know the stack that they were programming in, I could come in and really slice and dice like, what are the core things that need to be refactored and what can we do over time while the system is up and running otherwise, if I was a permanent employee, I might not have been willing to accept the level of risk of going in front of the C level team. It was like 50 or under employees. But going in front of the C-level team, sticking my neck out as a product manager for the development team and saying I understand when you wanna move fast. Completely agree. This is what we need to make sales and all that kind of stuff. So we're gonna do the minimum we can to do it like a deep technical system upgrade while we can to enable all this stuff in the future. And now is the time to do it. Yeah. Now is the time to do it. And to convince We did go forward with it, by the way. We they did, we did do it. It was successful. We didn't incur significant downtime or risk, any sales or anything like that. Yeah, we did it in the time. And it, this was a success story, but the, the reason I bring this up was it would've been easy to not push back against the move fast culture.

Om:

Some of the biggest risks I've taken have been as a contractor.

Brian:

Right.

Om:

'cause you're not gonna lose really right. You earn a contract anyway.

Speaker 3:

Right.

Om:

So in situations like that, you don't really lose a lot of sales. I mean, the sales cycle's quite long anyway. a couple of weeks here and there, you're not gonna lose sales. So be bold.

Brian:

My takeaway in this category, like if you can't say that this is risky without getting fired, then I don't think you're in a fast culture. I think you're in a fragile one, and I think it's just a matter of time anyway.

Om:

And in that case, keep that rec resume updated.

Brian:

keep all the things updated, all everything updated. So I, I might I might just be done at this point. I don't even know if this is a good takeaway here. Let me highlight on the screen so the, the the trade off framing. When you're pushing back, acknowledge you, you acknowledge that you wanna move fast. You surface the, the dilemma. If we wanna do X, we are trading off y each surface a trade off. And you ask is that a trade off that we're comfortable making? And you make it explicit. Now, this, this is a, a, a fair way to broach the conversation. That's right. I said broach conversation. I don't know if this is a great framework here. Because this one starts fights. You definitely should acknowledge the elephant in the room to say like, listen, I know that we wanna make sales, we need to make the investors happy. We need to expand footprint in x, y, Z market but if we continue to do X, Y, Z, we're gonna trade off our future ability to do Y? Whatever. And then your executives are gonna be like. I don't care. Get it back in there, kid. Do what I say like, that's why I don't think it's very strong. I think the actual financial value that's being left out of this conversation is gonna hurt you. You know, cost of delay is being left out of this conversation gonna hurt you.

Om:

I agree. I think those things have to be in there to supplant, your argument

Brian:

and also the human cost that we outlined in an earlier category is left outta this one. I think that will hurt you too. So if you have a better framework for this conversation, let us know in the comments. That's what I'm saying. That would be a really good value add for everyone. Yes. So all right. let's bring this home. So what's the bottom line for move Fast and break the law? I mean, break things. What, what is it? let's recap. Today we argued move fast and break things. It's not a badge of honor in, no, it's maybe in Silicon Valley it is, but

Om:

but it can also cause real harm to real people.

Brian:

Yeah. Is there a better mantra? I mean like I know Mo move fast and learn like I the, the Eric Reese mantra of minimal vocal, I guess nobody understood Eric Reese's better mantras that were in the Lean Startup, and that's why we got. Mark Zuckerberg maybe, I don't know.

Om:

Read the book,

Brian:

Oh, he definitely doesn't read. I think he does the audio version while he's cashing out. Start, start starting up. Cashing out. Broing down.

Om:

gotta put that meme in.

Brian:

missed that one.

Om:

Like move fast and learn things. you really should start there at least.

Brian:

Yeah. Mini minimum. Minimum viable learning I, look,

Om:

and so he stresses learning velocity, right? As opposed to shipping velocity. Yeah. Yeah. You need to, you need to both, right? But learning velocity. Think about cases where you could potentially cause harm. Yeah. Whether it's internal or external, whether it's intentional or unintentional. Like of course people are gonna say, well, how can you stop unintentional harm? You can't all the time. Yeah. But you can at least think through some of that stuff.

Brian:

What do we learn about our assumptions is another good one. Yeah. There's a bunch of good ones that have nuance. I mean, they're not as sexy as move fast and break the law, but they're still, they're good.

Om:

Urgency is fine. But with ethics,

Brian:

I mean you had me at ethics. I'm out.

Om:

That's not very ethical.

Brian:

All right. Speaking ethics.

Om:

All righty. So hopefully you know, you've learned how to push back against some of these things that you're asked to march toward and how to do it. Also you've learned that there are real consequences for you know, if you're just gonna close your eyes and run somewhere.. Let us know what you think about this topic and other topics you'd like us to delve into. That's right and subscribe and give us your thoughts in the comments below

Facebook, tech ethics, Eric Ries, lean startup,psychological safety,sustainable pace,product management,technical debt, Amy Edmondson,agile coaching, team burnout,move fast and break things, startup culture, Mark Zuckerberg, silicon valley culture,