Depends on how you define "Uber". If you mean the construct and it's continued existence, then the jury is still out on that. For all the early investors and employees (the ones that facilitated the "move fast" attitude), it looks like it worked pretty well.
If you have a 5% chance of becoming a billionaire and a 95% chance of walking away from a failed startup with minor debts and lost time, the math says that your expected value for moving fast and breaking things is still quite high.
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!
There's no 5% chance of becoming billionaire, but of building a business that survives beyond 2 years, probably with lots of hard work, investment and learnings from past failures.
4. Regulators and the public have both grown increasingly alert for 'fake it til you make it' gambits. Regulators are more likely to intervene when companies create a public hazard (eg. Theranos, Uber's self driving program) or skirt legality with their business models (Uber, again, hmm.) The public is more likely to cynically exploit loss-leader behaviour and then jump ship once the company tries to turn a profit.
Sadly the author doesn't understand what iterating quickly means. It's not a means of achieving greater performance in a known area, but a means of finding something that works in an unknown space.
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.
not on patients, but they probably do a lot of iterations and a/b tests on mice. Fail fast is great for medicine research, the sooner you know that something doesn't work, the sooner you can try a new recipie.
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.
From the article: "Shift 2: From Rapid Iteration to Exploration"
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.
Sadly the commenter doesn't know what the rule of law means. You can't just move into an unsuspecting city, dump a few hundred e-scooters on the ground, and expect money.
These e-scooter trash-mongers belong in prison for abandoning large quantities of junk on city streets. I would charge the founders with multiple environmental crimes if I were the local DA or a Federal prosecutor.
My answer would be: as the things are so broken, that I sometimes wonder how anything still works. Flawed cpus, memory, motherboards, operating systems, hardware, not to even go into userspace/web software full of lasigna frameworks that are buggy as hell even on then own and once you put all that into gulash called modern software... Its a small miracle on its own.
I think the big issue with companies like Facebook is not that their development model moves too quickly for them to be able to react to their issues but that they simply don’t care. Facebook has known about the issues with privacy, hyper targeted advertising etc for years. You don’t need to move very fast to react to a fundamental issue in that timeframe.
Areas where big companies don't care are often ripe for new disruptive products. Google's success can largely be attributed to building a feature that the 400 pound gorilla of the time (yahoo) didn't give a fuck about.
consumers need to care as well, and that is/was the issue for privacy or ethical behavior.
I hope we got passed that point, but it sure takes a damn long time.
Or perhaps they do know exactly how much consumers care about these issues (spoiler: not much), and are simply building for their consumers. The few hundred / thousand people flooding Twitter and opinion columns don't speak for the 2 billion people who use Facebook.
Please, someone tell the geniuses at Harvard business that no one ever used "Move Fast, break things" for chips. Having been in the industry long enough, I've seen plenty a launch date moved, and chip-respins executed in favor of risking a recall of hardware from the field.
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
They had no need to upgrade. If anything they had a massive need to downsize the inventory of weapons. Plus the security protection was shockingly irresponsible. The code was all zeros
Downsizing is orthogonal to needing to upgrade. You still need to maintain whatever amount remains and that could call for software upgrades in light of a new issue.
I've heard that the unspoken truth of those launch sites is they are just being maintained for lack of orders to dismantle and that even in event of a nuclear war, they couldn't/wouldn't be used safely. The majority of the US's strategic nuclear arsenal would be fired from one of our nuclear equipped submarines.
The geniuses at HBR never claimed in the article that it applies to chips. The article says that increase in chip performance lead to a prevalent strategy in business (mainly tech) to be the first.
Its crazy how tribalistic HN has become. The whole Boeing fiasco has produced SO MANY "gosh, all those MBAs are at fault. I assign 0 fault to the engineers!" and every. single. time. There is a problem relating to a management/engineering decision, blame from HN ALWAYS goes to "the MBA types" and very literally never to engineering.
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.
I'm under the impression that MBA culture has issues with taking responsibility for failure, and will always try to assign blame somewhere - anywhere - else.
"how could you say we're really tribalistic and blame mbas for everything? Are you implying they werent 100% responsible and that engineers MIGHT have shared in the blame slightly? hahaha."
Well this, if nothing else, certainly proved my original point?
The point is not that it's completely the other way around. It's that it's not black nor white, but rather gray. In other words, engineers also have responsibility, as well as management.
It's management's job to manage. That's the definition of management - motivating, steering, and directing teams and organisations.
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.
The tech community has always had that element. It's nicer here than on Slashdot but it's here too.
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.
It comes from the fact that all the people at the top refused to back down or slow down despite all the warning flags being raised in engineering, and persisted in maintaining a system of incentives that left engineers in a position to choose between having to do something unethical, and keeping food on their family's table; all in the name of stock price.
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.
While I agree with your point, I don't agree with the idea, that the engineers there are some Dickensian exploited workers struggling to feed their starving family. Those are white collar middle class employees mostly.
How many other Aerospace companies are out hiring right now?
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.
How many would you consider a reasonable amount for competition? There's 15 showing up on a cursory Indeed search, not to mention civil service entities that hire AEs
Ethical decisions have consequences that include blame.
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.
Well I can only speak from the point of being the bread winner for my household which the last few years has been getting hit hard by medical crisis after medical crisis, and despite every effort at cost cutting and saving, what cushion I've built up slowly gets consumed. And I'm in software.
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.
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.
Having been through business school, the MBAs are much more likely to be complete numbnuts, an observation which is very strongly correlated with most of the CEOs and managers I have spent time with close-up
Never said I wasn't one of those b-school idiots... it was a ghetto, full of big (shitty) ideas, five-dollar words, and a cohort that couldn't think for themselves if you stuck a gun to their head. I like to think I rose above but... sometimes I have my doubts
The problems that MBAs are trying to solve are not those at which your average engineer is particularly good. Also, these problems are usually ill defined and not easily testable. On top of that, to "deploy" your solution you need to show a schizophrenic amount of confidence for the amount of ambiguity and risk you plan to take, and you have to do it all in the form of a PowerPoint slide deck for people who are most likely have no clue what you are talking about and have an attention span of a 5 year old child. All this leads to a relatively high error rate.
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.
So you're basically saying, MBA's are making decisions based on guesses and feelings, which would then be formalized in PowerPoint slides.
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.
>we don't need a dedicated decision making class. decision making is a skill that engineer can acquire
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.
How so? If a certain group of people always CHOSE profit over doing the right thing other people or groups or teams or whatever you want to call them have every right to criticize them.
"How could you possibly imply that us engineers blame MBAs for everything? Here is me following this question by saying that MBAs ALWAYS choose profit over doing the right thing and that all other teams do not so therefore we should criticize MBAs and engineers are above criticism.
Do you think you'd understand my point if you had self awareness?
It’s funny. If an article mentions how much someone in management gets paid, it’s all about how they don’t deserve it, they’re profiting off someone else’s sweat, they’re useless, it’s unfair, etc. Then you see something like a data breach or the Boeing fiasco and management belongs in jail because they didn’t put good processes in place for the engineers.
The problem is that the managers don't have accountability at the same level they are compensated.
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.
> Why should blame be tied to compensation? 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.
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"?
Apparently "risk" is tied to compensation. And so is talent.
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?
> Again, how is that the same as saying that blame should be tied to compensation? 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.
That is so mistaken I’m not sure where to start. I agree there should be accountability, but to say it should be commensurate with compensation is absurd. What happens around here is the engineers are never to blame and it’s always management. Even when it’s specifically an engineering problem it’s the managers’ fault for not preventing the engineers from making a mistake.
> That is so mistaken I’m not sure where to start.
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 agree that management is generally to blame but also think many (most?) mishaps have engineering related proximate (and potentially root) causes. For example, I think I remember hearing part of the Fukushima disaster is attributed to the engineering decision to place the diesel pump batteries in an area that could flood. The fact that these engineering risks weren’t adequately managed is why people blame management.
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.
Well, one thing that research into engineering disasters shows is that these things are almost always chains of things going wrong. Generally because managers do something with no engineering justification--either cutting safety margins, continuing in the face of evidence that is indicating operating outside normalcy, or doing something to "save money" with zero thought to the implications.
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.
Yes, James Reason's "swiss cheese" model that is often used to portray mishaps that occur as a string of subsequent latent failures. My point is that engineering failures are often part of this chain. To the parent comments broader point, many on HN are quick to dismiss the engineer's culpability. Engineers are one of the few professions that have an ethical obligation to society and their role in the process shouldn't be minimized.
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"
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
TFA has lots of 'ideal world' assumptions that are a real hostage to fortune, e.g.
> 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.
That's about as nice an example of survivorship bias as you could find. SpaceX came within a whisker of ceasing to exist. If that one launch had failed it would have been game over for them. But they got lucky that time and they have done a fantastic job at keeping their eye on the ball ever since. Every business has one or more of those critical moments in time when things just have to go your way. If you are in a business where breaking things is your only option to succeed at all then you should. SpaceX gambled and won, and breaking things is still the way of the world in rocketry and likely will be for some time.
Point taken, but they also don't keep breaking the same things, over and over; simply because it is not cost-effective to avoid the breakage.
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.
When SpaceX breaks stuff it is simply because not all the variables are known, not because they cut corners and harm their customers in favor of their bottom line or speed of execution.
Exactly. It may be "survivorship bias," but sometimes, we survive because we did it right, and it's not a bad idea to see what the survivors did. They didn't screw up the launch, because they screwed up the tests; where it was expected.
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.
It only has ever worked if you have a monopoly or plenty of cash to burn. If you can test in production and your user base can absorb errors/inconsistent behavior, it's the path to finding new verticals.
I move that the article definitely touches upon a critical topic but fails to nail it due to a too-narrow yet too-peripheral account.
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.
"Move fast, break things" never worked in any meaningful way, especially in AWS. It's a garbage philosophy repeated by idiots who don't support business applications driven by software on a global (enterprise, mission critical, always-on) scale. Literally no one at Amazon practices this idea, except the idiots who think that launching pre-alpha garbage into production because of poorly conceived re:invent promises is an acceptable business model that builds customer trust (spoilers, it doesn't). Source: worked there, did that.
Whenever I see articles like this or about frameworks like the Cynefin framework I cannot help but to see it like any mathematical optimization problem. If the solution is simple to see you just jump to the solution. If it is more complicated but you have good practices / know the gradient (“know in what direction you are going”) and the problem is well behaved, you can iterate quickly and reach and expect to find an optimum. But if it is more complex and you don’t know I what direction to go / don’t have a gradient you need to do try lots of different experiments in parallel also.
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.
Move fast/break things works great when the risks associated with the “breaking” are minuscule, experiments can be measured and isolated, and the upside for experimentation high (UI tweaks, recsys or search algo improvements, social media, etc).
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.
> With every new generation of chips came new possibilities and new applications. The firms that developed those applications the fastest won.
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.
Hopefully this ends open Office spaces trend. I hope that there be a resurgence of private offices again. Cross discipline cross company cooperation sounds interesting.
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.
123 comments
[ 3.5 ms ] story [ 182 ms ] threadHas 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!
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.
These e-scooter trash-mongers belong in prison for abandoning large quantities of junk on city streets. I would charge the founders with multiple environmental crimes if I were the local DA or a Federal prosecutor.
Move fast and break the law?
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
[3] https://www.onetonline.org/link/summary/15-1132.00
[4] https://www.onetonline.org/link/summary/15-1131.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).
> 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 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.
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.
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.
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.
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.
The company led by a complete sociopath?
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.