Why “Move Fast and Break Things” Doesn’t Work Anymore
hbr.org
hbr.org
It's only non-critical, consumer/casual software/applications that can afford to move fast, and break things. Your bank, or medical records, or even traffic light controls simply cannot move fast and break
https://www.forbes.com/sites/zakdoffman/2019/10/19/us-milita...
I guess I just don't understand what the point of this type of tribalism is? Feeling better about your team while lamenting how everyone else is stupid seems pretty unhealthy.
Well this, if nothing else, certainly proved my original point?
If engineers are doing unsatisfactory work, it's management's responsibility to recognise the problem and fix it - whether that means finding better engineers, or developing better systems and processes for motivation, direction, quality control and oversight, or simply communicating strategy and culture more clearly.
Of course here the subtext is that "tribal" engineers were just as responsible for Boeing's many recent failures as the C-suite were.
And that's a particularly toxic and dishonest view, because we know from records that engineers were desperately trying to fix the 737 Max issues, while senior management were desperately putting short-term profits ahead of long-term consequences - with fatal results.
There is no "also" here. The suggestion that there might be is a naked attempt to displace blame and rewrite history.
We've been through a boom for strong-man tech ceos with elon and amaz launching all kinds of projects. There's going to be a natural pendulum swing the other way for a bit.
If it were Engineers at the top, we'd probably be lambasting them for abdication of their responsibility too if they made that decision.
Make no mistake. If you would be a leader of men, tread carefully. For where you lead they will follow, and if you ignore their warnings and protestations, and lead them to calamity, upon your shoulders will rest responsibility. If you try and admit you can't make it work; no one can blame you. If you rush in as the fool convinced everything will work itself out, you were either incompetent, or worse, deranged, and thus deserving if ostracization and example-making-of.
It's just how it works.
The answer? Not many. The industry is highly consolidated at this point. So the competition that normally ensures workers can vote with their feet isn't there.
So... Yeah. When you're already hired by the biggest actor in town, the ethical calculus changes whether you want to admit it or not.
Engineers are well-paid, highly sought after individuals. As long as they manage their finances responsibly, walking away from a job should not be as dire as you make it sound.
The Aerospace folks don't enjoy the luxury of the exaggerated salary, last I checked.
So maybe there's some bias there. However, the circles I wander tend to face the same financial struggles as well. Just speaking from experience.
I don't know if you work in SV, but that may skew your perception on salary.
[1] https://www.onetonline.org/link/summary/17-2011.00
[2] https://www.onetonline.org/link/summary/15-1133.00
Nitpick: that's how it should work, and how HN trys to make it work (hence the so-called tribalism), but in many cases those rushing fools get a golden parachute and a cushy retirement while leaving a straw-stuffed limited-liability corporation to be "held accountable" for liabilities it no longer has the assets to meet. And that's if they can't use superior legal funds, PR, and lobbying to shift those liabilities onto engineers or dismiss them entirely.
Finally someone on the internet comes through!
So, it's easy for engineers to ridicule them, while still keeping well within their own comfort zone. It doesn't add credibility though, I agree.
What does that mean? "A lot"?
I as an engineer like neither of those things. Research the market, create a product per spec, then write documents in markdown. The idea of business are not foreign to us, there are plenty of engineers who start business. And I think the balance is tipping over to the engineers.
In my opinion we don't need a dedicated decision making class. decision making is a skill that engineer can acquire - no need to involve people with no technical understanding into the equation.
This statement seems to trivialize the skills necessary for good decision making. I would argue good risk based decisions and awareness of cognitive biases (not to mention more “science” based decisions from fields like operations research) probably should be based in formal mentoring/instruction.
Do you think you'd understand my point if you had self awareness?
If you are compensated better than 90% of your workforce, then you should receive better than 90% of the blame every single time something goes wrong. You're that important, no?
Compensation tends to be tied to perceived impact. The perceived impact of a manager with 10 reports who are all focused and delivering individually is much higher than the impact of a manager with the same number of reports where half the team meets few of their goals.
The first manager is ultimately going to be seen as more effective and will get larger bonuses and will be more frequently promoted and ultimately grow the scope of what they own. That they happen to get paid more than individuals reporting to them is entirely appropriate based on their overall impact.
That managers sometimes blame the people on their team for the failure of the team is bad management (and worse if the people above them blindly accept that) but I don’t think you can assign all blame to a manager just because they happen to be the manager and certainly not because of their relative pay.
Maybe because when those goals involve cutting corners on safety and hundreds of people die as a result, that's one heck of a lot of "impact"?
So if you have someone telling you they're more talented than you are, and they take bigger risks, and that's why they're paid a lot more than you, why would you not expect them to take more responsibility than everyone else when things go wrong?
Separate out management for a moment. So an engineer who gets paid 50% more than another deserves 50% more blame for a failure?
I thought HN was a place where people attempted to form good arguments based on fact, not one where people let emotion rule the day.
To entertain the naive pedantry for a second: first, I think a heck of a lot of people would tolerate that 50% scenario more than the status quo, and second, it's not exactly outrageous to suggest the impact you have on a design goes hand-in-hand with how much blame you deserve for it when it breaks (or how much praise you deserve for it when it works). Now, you yourself say compensation should also be tied to impact. Apply the transitive property. You might be surprised what you get.
But surely you realize you're making a strawman out of the points people are trying to make? It's not literally the "same thing", it's an approximation meant to get a point across, and it's based on the assumption that you apply some common sense instead of treating it like a mathematical proposition. Like the understanding that you literally can't fire 98.3% of one guy and 1.7% of another, so clearly everyone understands "blame" will get out of sync with compensation; that in itself is obviously not the literal point. And the understanding what people are clearly upset about is the fact that those who are given more responsibility and power over a product (which just so happens to go hand-in-hand with their pay) frequently appear to bear far less blame than those whom they manage and give directions to. Nitpicking on why it should be proportional to the guy's salary is literally missing the gigantic problem the other person is trying to point out.
Then you disagree with practically every military on the planet.
So, you're going to to have to provide at least a little bit of counterexample to support your position.
> Even when it’s specifically an engineering problem it’s the managers’ fault for not preventing the engineers from making a mistake.
There are VERY few times when engineering results in the failure of the project--Citicorp center, Tacoma Narrows, Therac-25, maybe I'll even give you Three Mile Island (the teletypewriter was producing bad data because it didn't have the capacity and got further behind as time went) ... I'm having to work hard after that but I'm sure I could come up with a few more. This is normally true because engineers almost always add a safety margin just in case something they can't account for goes wrong.
By contrast, most of our worst disasters have all been management failures. Chernobyl was a management-driven disaster. Fukushima was a management-driven disaster (spraying water on a core to prevent it melting down was a ferociously stupid management decision). The Navy Pacific fleet collisions are management-driven disasters. The first Johnstown Flood was a management-driven disaster. I can go on and on.
I think one reason the original claim is weird is that leadership should own the blame irrespective of their compensation. (E.g., if a manager has $1 salary they aren’t magically off the hook). It’s one of the core tenets of good leadership.
I think engineers sometimes are quick to jump on management because of 1) a hindsight bias and 2) because engineers often have a myopic view of risk. For example, a software engineer tends to only focus on software risks, while management must balance software risks, hardware risks, customer risks, labor risks, etc.
You will note that I specifically chose the spraying of water at Fukushima as a management failure (we can argue about the lack of failsafe for the cooling ponds)--because some idiot counting dollars decided to try to "save the core" they caused a hydrogen explosion which made things orders of magnitude worse.
In both Fukushima and Three Mile Island, for example, if everybody had simply SAT ON THEIR HANDS AND DONE NOTHING, the situation would have turned out far better than it eventually did. Yes, the Fukushima core would have still melted down, but it wouldn't have sprayed radioactive material all over the place.
In my experience, the result of bad decisions is usually due to incomplete information and risk assessments, whether by an engineer or management. Management usually has more risks to balance than the engineer. Engineers are typically only concerned with technical risk while management has both technical and programmatic risks to balance. When the balance tips towards programmatic risks, it may be due to a poor understanding of the technical risks as well as a bad incentive structure. When the technical risks aren't well understood, it's generally not because management is too dumb to grasp it. It's more likely the culture and organizational structure don't foster good communication or accurate assessments of those risks. For example, if you look at the Challenger disaster, neither the engineering staff or management has great estimates about the risk. (However, the engineers were much closer to the true risk probabilities). It came down to a concrete schedule risk vs. a somewhat nebulous technical risk and the absolute risk won out in the management decision process. In your Fukushima example, I'd bet the "idiot" probably didn't have an assessment (in terms of a failure-modes-effects-analysis or hazards analysis) to properly gauge the risk of their action. (Or there were likely communication failures of that risk, or both.)
I think the important point is that to really fix these issues, they have to be addressed as part of a process failure rather than pointing fingers distilling it down to a simplified notion that it's somehow the fault of an "MBA mindset"
https://qz.com/1776080/how-the-mcdonnell-douglas-boeing-merg...
(Sorry about the 'amp' link)
Chip design is not one of those cases.
Are you saying it works well in safety critical software development?
Cheaply in the case of adverse outcomes (whether cost, environmental impact, or impact on life) seems at odds with the very definition of software that has a high severity if it fails. I.e., to say safety critical software can be developed “cheaply” seems to ignore the costly consequences of that software failing
Don't tell the banks and financial industry that (looking at you, Equifax).
So the completely opposite argumentation would've worked. For the last 10+ years we spent iterating over several startups to find how to use this new technology of mobile and internet, and now that we have found most reasonable usecases we can slow down and optimize them.
On the other hand there are always areas we don't know much about, like in the areas of shared knowledge, in the niches. There of course quick iteration continues to be the way to go.
What do you think placebos in clinical trials are??
I will quibble though on the "now we can slow down and optimize them" part.
What's happening in practice is that those startups who "lucked" into successes playing the risky-but-many game of mobile & internet technology... those startups now focus on defending their "moats" and optimising their revenue streams.
Moat: from Medieval Latin mota: “a mound, hill, a hill on which a castle is built, castle, embankment, turf”
In the spirit of mixed metaphors: </checkmate>
business catchphrase for the 20s: stock your hill with crocodiles
But rapid iteration is the most efficient means of exploration for many areas. Exploration is the reason many people use the "move fast and break things" rapid iteration strategy.
Move slow, keep things working works well when breaking things has a huge downside and safe experimentation on live customers near impossible. Such as medicine, legal compliance, building airplanes, utilities.
I think that SpaceX is living proof that you can move very fast indeed, without breaking things.
As we well know, they do, very rarely, break things (with great video), but when that happens; it only happens once.
Makes business sense, but I've always been one of these knuckleheads that wants to write great code; simply because I like to do it.
I got into the habit of practicing zero-tolerance on quality. I've never found any level of breakage acceptable in my own work. I literally get physically uncomfortable when I know there's a bug in my code, and I have been known to get out of bed at 2AM, and go downstairs to fix it.
I know that I'm fortunate to be in a place where I am free to do that. I don't need to run in the rat race.
Remember when the ability to land a spent booster was being poo-poohed by the "old guard"? Remember those really awesome booms?
Nowadays, landing the boosters has become so routine that it isn't even mentioned anymore.
That's cool.
I am kind of in awe of the way they work. I'm not sure that I'd be up for working in that environment, myself, but I have mad respect for them.
Initially, I was really disappointed in this article. Facebook, on the client-side, was 'possible' on a Pentium 4. Perhaps a III.
Internet speeds where sufficient in the early 2000's, and MySpace was created a year before Facebook. We all know who won.
I really had a hard time seeing what "chip generations" or "being first" had to do with any of it.
Sure, powerful enough hardware is a pre-requisite. But... I couldn't see any correlation between generations of products / services and CPU power.
In my mind, if there was a correlation to be had, it'd rather have been between said generations of products / services and, first internet speed, and then internet adoption.
And Moore's law didn't have much to do with it.
Then, it hit me. I was on the wrong time scale. He's talking decades. We're not looking at the 20 or even 30 years, but at the last 60 or 70 years.
So, yes, he still misses the entire "internet tipping point", with the associated paradigm shift, that is probably just as important as his precious Moore's law.
But he's also right on how it enabled the Mainframe -> PC -> Smartphone transitions.
Although I still don't believe in the theory that being first matters that much.
Who here remembers Microsoft's UMPCs? Or Intel's MIDs? Or the first third-party iPhone app?
... he does make a point. But I don't know what to make of the whole thing, really.
And the more costly an iteration is the more important it is with multiple perspectives to get as much data into the different experiments from the beginning as opposed to randomly selecting things to try out and seeing what happens.
> This new era, on the other hand, will be one of mass collaboration in which government partners with academia and industry to explore new technologies in the pre-competitive phase
. ...
> That’s why we can expect the basis of competition to shift away from design sprints, iterating, and pivoting to building meaningful relationships in order to solve grand challenges. Power in this new era will not sit at the top of industrial hierarchies, but will emanate from the center of networks and ecosystems
Not sure if the FAANG-likes will see it like that.
I also tends to think that the move fast and break things builds technical debt. As such as there is a need for a cross between agile and a more planned approach.
Once they grow big, they can’t afford to move quick. And breaking things seems dangerous.
So it does works. But depending on the stage the company at
Consider this:
> Over the coming decades, however, agility will take on a new meaning: the ability to explore multiple domains at once and combine them into something that produces value. We’ll need computer scientists working with cancer scientists, for example, to identify specific genetic markers that could lead to a cure. To do this, we’ll need to learn how to go slower to have a greater impact.
This "working with, across domains" mantra underlies the entire article. It's called transdisciplinarity — if not of individuals, of teams.
Guess what. That's how we've done any sector for the longest of times. You start with self-made specialists, they grow the field, which then touches other fields, and before you know it, a "normal" business has several functions: accounting, sales, legal, marketing, production, etc.
Tech is new, and tech is geeky — the greatest among us estimate that no more than 1~5% of the population has enough interest to enter and remain in the field.
Transdisciplinarity is usually a major key to unlock hard problems, indeed. As more and more engineers enter the tech field coming from previous careers, armed with domain knowledge, the quality and "relevance" of tech features improves, no doubt about it — I think music and the arts in general, observed over the last 50 years or so, is a strong illustration of that.
> These new technologies are far too complex for anyone to develop on their own. That’s why we can expect the basis of competition to shift away from design sprints, iterating, and pivoting to building meaningful relationships in order to solve grand challenges.
This literally confuses goals with methods. Agile never told you what to do or why you do it, it's just a "small method for small teams to work better/faster, to manage complexity". Grand challenges don't get automagically solved because they're big and involve many people from many fields.
The "far too complex for anyone to develop on their own" part is more telling of a philosophical bias: we tend to either see the world as "too complicated to be explained" (as the HR author) or "too simple to be worth wasting time to intellectualize it" (this is the general entrepreunarial mindset, to go at things from action even if it's not entirely clear mentally; the opposite mindset, which is mine, is more of a research ethos, an observer / thinker.)
Transdisciplinarity is also not a new thing. It's just the latest trend to kick in on the road to progress, it's a pendulum from hyper-specialization (high verticals) to holistic solutions (big horizontals).
Consider philosophy, human beings sprouting ideas, software engineering for the mind. An idea appears somewhere, in a group, in some space-time. It starts localized, vertical. The taller is gets (i.e. the highest its worth and the strongest its implementation, its relevant rooting at many levels of the stack), the wider it may eventually resonate, spread, horizontally towards other fields, other domains, other spacetimes and cultures. "Don't kill thy neighbor" is kind of such a piece of software that most of us have installed. But look how philosophy generates ideas: usually not in isolation, rather from looking at the world. The best philosophers, imho, are those who speak from experience (typically not career-philosophers, rather doers, goers, people who act and only then speak).
Case in point: after a few thousand years of thinking and transmission, philosophy is part of everything we do, are.
Technology (in the current modern sense, computing, electronics, etc) is like that, it's a big vertical with tremendous horizontal reach. It will become, like philosophy, like any valuable improvement to human condition, a massively transdisciplinary activity.
Has nothing to do with moving fast and breaking things though.
Of course, if you step outside yourself and also consider the downsides of failure for your employees, your investors, your customers, and the harm that a fast-and-loose approach could do for the public at large, or the environment, (or other externalities, depending on your business) it starts to get less attractive.
Being a sociopath who is "only looking out for #1" is a big advantage in business!