return to table of content

Unexpected anti-patterns for engineering leaders

engineers_unite
45 replies
20h42m

I have seen Will Larson's techniques applied/ forced in multiple organizations and have found that his view of the engineering world just does not work. I sense that there is a cult of personality around him that leads to engineering ivory towers.

Most orgs that I've seen follow his writing or ideas have ended up in conflict with the business and one another, isolated on a corporate island, and then gutted by layoffs.

I don't like to throw an author/engineer under the bus but I do not know why this guy has a following. I have never seen his methods result in happy engineers and delivered value.

My summary of this article (for managers): 1. Micromanage early and often 2. Measure, and whatever you're measuring, act like it's truth and that you know best. 3. Listen to the curmudgeons and the naysayers because they are the true sources of knowledge.

Edit- as I mention in a reply, try https://pragprog.com/titles/rjnsd/the-nature-of-software-dev... Ron Jeffries' "The Nature of Software Development". Incremental value, engineers leading delivery, constant feedback cycles, flexibility. I've followed the tenets of this book in many orgs, and they lead to measurable value, happy engineers, and successful orgs.

IshKebab
14 replies
20h22m

Maybe his advice suffers from what many other pieces of apparently good advice suffer from: they get used as an excuse to do whatever the person saying them wants, hiding their real motivation.

Premature optimisation: oh that means we don't need to think about performance at all

XY problem: I don't need to tell you the answer because you shouldn't be asking the question

If it works don't fix it: we don't need to do any maintenance

Chesterton's fence: we don't need to change anything ever

Your summary is clearly not what he's saying, but I can totally believe that people would use it as justification for doing those things.

liquidpele
6 replies
20h7m

If a system requires saints and/or geniuses to work, it’s a bad system.

polynomial
1 replies
18h34m

(Machiavelli might have something he would like to say here.)

Tao3300
0 replies
15h51m

"In corrupt republics, especially in untroubled times, men of first-class ability are ousted by the envy and ambitious scheming of others."

datadrivenangel
1 replies
15h11m

A system designed to be idiot-proof is eventually designed by the idiots.

jononor
0 replies
10h31m

It will also create a system of idiots. As in limit peoples development, retain the less capable and chase away the capable.

lolinder
0 replies
19h49m

They didn't say it requires saints and/or geniuses to follow the advice in TFA, they said that people will often twist good advice in bad directions because they have ulterior motives. This is true regardless of how difficult actually implementing the advice would be.

The advice in TFA basically boils down to "don't pendulum, try to find a good middle ground between extremes", which shouldn't require either a saint or a genius.

ShroudedNight
0 replies
19h47m

The system works for him. Moreover, I expect it likely works well enough for some people. Humans are a rather heterogeneous lot. Any system of universal applicability is going to be extremely limited in its ability to provide tactical insight.

DaiPlusPlus
6 replies
19h7m

If it works don't fix it: we don't need to do any maintenance

My counter argument is “Why don’t you have automated test coverage so you’re free to make maintenance or engineering improvements without fear of breaking things?”

datatrashfire
2 replies
15h47m

One thing I have noticed with over zealous testers is to get 100% coverage they mock everything and test implementations. Then you end up writing 2x the code to get anything done. I think it's a net negative. I have more often had to rewrite tests in these environments then have them actually save me from shipping a bug.

thom
0 replies
10h29m

This is why I very heavily favour functional tests or broad use-case based integration tests that are implementation agnostic. Save your highly coupled unit/property based tests for algorithmic code or weird edge cases when things are settled. More generally, even many TDD people advocate “spike then stabilise” as an approach.

lanstin
0 replies
14h0m

That is such a sweet feeling - doing what you feel is good test suite (maybe not TDD perfectionistic 100%but good) then few months later you add a new feature and the tests find some subtle bug that would have affected production.

johnnyanmac
0 replies
11h22m

Good question, ask my entire industry. Games defintiely has logic that isn't easily covered by automated systems, but there's plenty of deterministic code that could be put under test. We rarely get such luxury of time to implement that, though.

dgfitz
0 replies
17h43m

Because the same engineers that write buggy code write buggy tests?

CamperBob2
0 replies
1h30m

Why don’t you have automated test coverage so you’re free to make maintenance or engineering improvements without fear of breaking things?

Because that's equivalent to solving the Halting Problem. Even if you could test your way to quality in a non-interactive context, it would never be possible in a system that includes asynchronous human input.

hibikir
10 replies
14h59m

Disclaimer: I was Will's direct report, and then Will became my skip level in a past life. I'd rate him as better than average manager, who was surrounded by a lot of well under average managers.

I'd love to hear longer stories on your opinion here, because I have theories on the issues with Will's advice, but nobody sees quite enough organizations to quite be certain. The more stories we hear, the more likely we are to get things right.

My hypothesis is that Will's advice is a lot of recipes to create change in organizations, but lacks focus on when to apply them, and how to be sure you aren't bungling it all up by fixing the wrong problem. This makes the ideas more attractive to the dashing, aggressive, confident executive, whether he has a good pulse on the problems, or he is the kind to trust on the wrong people, and fail to see that they are building enemies (as all agents of change do), without getting sufficient number of fans in the right places. So people that like his advice will tend to fail by overstepping. I know some executive who have an entire career like this, company after company: Seeing themselves as the protagonist of every story, and acting like bulls in a china shop, therefore failing politically even if their diagnosis was somehow right, and their changes made sense.

Ultimately the best advice is 'make sure your manager likes you'. Which works just as well if you are a CTO reporting to a CEO, or an engineer reporting to a line manager. It's trivially easy for executives to think this isn't the case, and then be surprised when the reorg comes.

atomicnumber3
7 replies
13h3m

"make sure your manager likes you"

This is always the best advice I've found. And I've also found that if your manager likes you, lots of other things just work out.

manmal
4 replies
7h18m

And what if your manager seems to just not like you for whatever reason and won’t tell you why?

timacles
2 replies
3h53m

People will never tell you if they like you or not and why

The emotional intelligence to pick up on that sub context is critical. Observe how they treat others, look for subtleties, think about them as people rather than your boss.

It really comes down to 2 things: if you had a beer with them would they enjoy your company; are you a good employee who’s not making them look bad by their managers.

james_marks
1 replies
3h23m

The ability to enjoy a beer with them is irrelevant.

The only question is, “Are you making them look good to their manager/customer/spouse/peers?”

Ultimately, that’s what you’ve been hired to do.

In a healthy context, you’re doing that by hitting your KPI’s, adding velocity, etc., but not necessarily.

jmb99
0 replies
22m

But that's missing the point. You can be doing all of those things but your manager still may not like you. Admittedly they're probably more likely to like you if you're a good employee, but if they like you and you're a subpar employee you're going to be much better off than if they don't like you. And, if you're a stellar employee, you'll likely be presented with more opportunities/more favourable tasks/etc than a stellar employee your manager doesn't like.

You can take the view of "I'm doing my job" but don't be surprised if those around you who are more liked by management get picked up for promotions/etc more than you. Most people (management included) are not 100% objective in their decision making, and someone liking you (or not) is going to influence their decisions involving you.

sbarre
0 replies
6h35m

Try to change roles or companies?

I don't mean this flippantly here, it's a crap situation to find yourself in but sometimes people just don't get along, or people are just not great, and you do need to know when to cut your losses and make a move.

barrenko
1 replies
12h41m

it's pretty goddamn stupid and seems to need constant reiteration for some people (like me!!!) but if you don't feel a cultural fit (from you as an employee point of view) - DON'T TAKE THE JOB

johnnyanmac
0 replies
11h28m

With the current market, I wish I had the power to refuse a job in lieu of a better culture fit But alas.

xwolfi
0 replies
13h15m

And you ignore the fact that maybe you are more to credit for his success than he was. Engineers aren't fungible, aren't all the same, arent all compatible with each other and the manager. Your conclusion is the right one but can we always make it happen ? No.

roenxi
0 replies
9h54m

but lacks focus on when to apply them

The gap between theory and practice - tacit knowledge - is probably a factor here. It seems quite likely that a lot of really good managers in software have theories about why they are good managers. Those theories could all easily be wrong and they are actually experts at communication or weird technical details that happen to make great managers. A manager's theoretical base is always built on a large tacit "I know how to X, Y, Z in a social setting".

If we look at this article through a very abstract lens, software managing advice fits the pattern of "at the appropriate moment, do the appropriate thing". Obviously the advice he gives is heavily tinged by the managers ability to identify the appropriate moment to do something unusual. He's pointing out some times where the appropriate action seemed to be the counter-intuitive one, which is fair and interesting. But I wouldn't ever trust a random manager to be able to pick the moment to do a counter-intuitive action; unless they were mentored with extreme care.

Aurornis
10 replies
15h16m

Most orgs that I've seen follow his writing or ideas have ended up in conflict with the business and one another, isolated on a corporate island, and then gutted by layoffs.

This isn't unique to any single author. This is a feature of cargo cult management.

Healthy organizations and good managers don't need to wholesale adopt management practices of a specific author. Their managers will read a multitude of authors, but their techniques and ideas are treated as different perspectives and suggestions to be considered, not prescriptions to follow in fine detail.

On the other hand, poor managers who don't know what they're doing love to pick specific authors and implement their entire frameworks. It makes them feel like they're doing something right, but it also makes them feel like they can blame someone else when it doesn't work out.

deepGem
9 replies
14h9m

I think micro management is often misunderstood. The usual run off the mill micromanagement, that almost every terrible manager follows is what I call micro verification. Double guessing every step you take and adding a verification layer on top of it. In the long run, it erodes the confidence and risk taking abilities of employees and overall completely detrimental to a company.

Real micromanagement is the ability to dive in and solve unsolvable bugs or issues, rally the team until the minutest detail of an issue has been hashed out or remove any micro obstacle. Once a manager shows skin in the game and proves themselves, they often win the minds and hearts of all engineers, who then feel inspired to get into micro details themselves.

Now like a sleight of hand, you have scaled accountability and integrity in your team.

So micromanagement done in the right situation and in the spirit of moving things forward is highly beneficial. In most cases, however micromanagement devolves into this micro verification tool that every mediocre manager uses to justify their existence.

johnnyanmac
6 replies
11h25m

sounds more like "micro-leading" than micromanagement. Every company varies, but management's time tables tend to be 80-100% meetings while a lead is more 40-60% depending on the week. A manager may not even be technical enough to understand the problems being solved by who they manage in smaller orgs.

deepGem
4 replies
10h57m

I really don't get managers whose timetables have 100% meetings. Weekly 1:1s is at the max 10-20 hours assuming a 10:1 engineer to manager ratio.

If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ? They may choose not to do so, but if a problem is not getting solved and they can't act in such a time of need, their existence is totally questionable.

johnnyanmac
1 replies
10h40m

If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ?

From my experience, this type of manager is more like that of a producer, merely called manager. Their job leans more on the lead to understand the technical planning, while they themselves coordinate between leads. In addition, they are also the direct contact for (often non-technical) stakeholders, so their strengths may lay more on securing deals/clients as opposed to developing/maintaining the product.

Lots of hats being worn in such a role between "kinda tech", PR, sales, and producing, so these happen semi-often in smaller companies, and almost never in a sufficiently large company.

deepGem
0 replies
9h24m

Oh yeah, you are describing a leader here. They are hustling for the next best project to take on for their team and/or for the company. They have moved beyond solving today's problems and spend most of their time on tomorrow's or the next year's problems.

koreth1
0 replies
9h26m

Wouldn't maintaining that standard make it effectively impossible to ever find any manager able to lead a team whose members have deep specialized expertise, especially if the team has expertise in more than one area?

ebiester
0 replies
18m

A manager with 100% meetings is often one of a few cases:

1. They use useless meetings as shields for their time. That is, I can put myself on a meeting that I never attend so that I am less likely to be booked for that time. I will often have time blocks on my calendar because I work in functional workplaces for me, but this can be useful in toxic environments.

2. They have additional project/product management responsibilities. This is common for platform teams that they don't have PM support and have to wrangle people themselves.

3. They're really working 50+ hours a week and do their real work afterwards or before. This is common in places that oversubscribe managers. (I've hat 15 and even 25 reports before. I've even seen 50.)

4. They don't know how to say no and guard their time. This is common with younger managers.

williamcotton
0 replies
4h55m

I'm sorry, but 100% meetings is incredibly unproductive. There is plenty of work to do as a manager in a business. Most involves a spreadsheet for doing time-tracking, resource management, cost analysis, ie, managerial accounting. A healthy administration is aware of how the money flows through a business and this depends on having eyes and ears on the ground.

You'll see this approach to running a business everywhere other than the tech industry.

DandyDev
1 replies
10h52m

Why is verification bad? I think it’s actually the thing that prevents the worst forms of micro management. Micro management to me means telling people what to do in detail. That removes autonomy.

The way to build trust and create autonomy while also keeping surprises to a minimum, is to tell your team what you expect of them and why. And crucially, you ask your team about their plan on how to get there. This still lets them decide on the “how”, while you can step in if you feel the plan is wrong. That is verification and it helps.

deepGem
0 replies
9h28m

What you are saying here is, for the lack of a better word, macro verification and that's completely valid.

lolinder
3 replies
19h56m

Your summary of this article is unnecessarily dismissive and misleading. It might be an accurate summary of what you saw in organizations that purported to be following this guy's advice, but I think we should let the article write its own tldr. Here are some of the key extracts that capture the actual ideas, which are in each case very different from your summary:

Yours: > 1. Micromanage early and often

Theirs: > New engineering managers are often advised to “step away from the code.” But an extremely high-functioning exec understands the domain they are operating in at some level of detail. As you get too far out of the details, you just become a bureaucrat. Too many well-meaning engineering managers end up as bureaucrats.

Yours: > 2. Measure, and whatever you're measuring, act like it's truth and that you know best.

Theirs: > "I think where I’ve gone wrong in the past, and where engineering leaders get into trouble, is by pushing back. They focus on saying ‘This is a terrible way to measure,’ instead of saying, ‘Let’s start here and drill in until we can understand the limitations of measuring this way."

Yours: > 3. Listen to the curmudgeons and the naysayers because they are the true sources of knowledge.

Theirs: > “I’m a big believer in bringing folks into the room so that they can represent themselves rather than having small decision groups. I like working out problems in larger groups where you can hold people accountable for showing up in thoughtful and effective ways,”

jujube3
1 replies
19h2m

1. Managers ARE bureaucrats, though. That's what the job is, integrating employees into processes. If you want to be a principal engineer doing architecture, that's a different career track than management.

2. You should not "get into trouble" for pushing back on flawed metrics, as long as the pushback is actionable and constructive. No metric may indeed be better than a bad metric in a lot of cases.

3. If you're "bringing everyone into the room" to make engineering decisions then either you have a very small company, or you just treat all engineers as juniors (meshes well with constant micromanagement, of course). Google doesn't "bring everyone into the room" to make tech decisions about networking, they bring the networking experts into the room (the "small decision groups" the author hates).

In summary, it all sounds very Dilbert.

itsdrewmiller
0 replies
14h36m

1 - I don't think he's trying to use bureaucrat precisely here - he's saying that the role of engineering manager is more valuable if they understand their domain vs. if they do not. This seems uncontroversial; staffing decisions for projects are more likely to be made correctly when those projects are understood.

2 - "should not" and "will not" are not the same thing. A huge part of bridging the divide between general management and engineering management is finessing the issue of performance/productivity measurement.

3 - Yeah I agree, I like a lot of Larson's stuff but not this. I kind of wonder how much of it is even real vs. just posturing; as you say it doesn't scale well at all, and he's worked at very large companies.

lazyasciiart
0 replies
17h33m

I used to work for someone who believed in 'bringing everyone into the room'. It was fine when that meant a team of 7 people, but he got promoted and kept doing it with 25 or 40 people, mostly irrelevant and mostly unheard. He once scheduled a meeting "in case anyone had something to say". It's probably clear that I didn't find him effective.

wcarss
2 replies
20h35m

just out of curiosity, do you have any countering authors or schools of thought to suggest?

I'm somewhat familiar with Larson from having read some posts of his over time, but I can't recall much of his specific ideas, and had never come to think of his approach as a broad block of thought in this way -- I don't know how I would summarize his oeuvre, but that's likely my own failing.

So... how would you summarize it? Do you see it as being in opposition to some specific other thing?

edit: I think your summary arrived in an edit after I began my response above. It answers one of my questions well, thanks!

onion2k
0 replies
11h56m

Engineering Management is largely about the 'engage everyone' part, and that is incredibly hard in an org where the devs aren't engaged. Getting them back on side with the business is rarely straightforward. Being an Engineering Manager now after 25 years as a dev that's the sort of problem I find interesting, but it definitely isn't easy. I've only been in my first EM role for a short while and I definitely haven't found a working solution yet.

cortesoft
0 replies
17h49m

Listen to the curmudgeons and the naysayers because they are the true sources of knowledge.

So his advice would be to listen to your advice?

hn_throwaway_99
19 replies
22h55m

I thought the first part about "micromanagement" was a great one. In my experience, the best engineering leaders understand things at a much lower level of detail than their title would suggest. This isn't exactly "micromanagement" (and the article says as much) but great eng leaders not only understand things at a lower level of detail, but they're able to communicate with their team in a way that doesn't feel like micromanagement at all.

engineers_unite
7 replies
20h35m

Micromanagement is what managers do who don't trust their teams or feel threatened by their engineers. If you are a former engineer in management, remember what it feels like to be micromanaged. You are not a manager because you were/are still a great engineer. If you are- your org is broken and the wrong people are in management.

lolinder
3 replies
20h6m

You just repeated the common understanding of micromanagement, which both OP and TFA are responding to. Just repeating back the same ideas which your interlocutor thought that they already addressed doesn't make for very effective discourse.

Here's what OP said:

This isn't exactly "micromanagement" (and the article says as much) but great eng leaders not only understand things at a lower level of detail, but they're able to communicate with their team in a way that doesn't feel like micromanagement at all.

Do you disagree with this? If so, why?

engineers_unite
2 replies
19h52m

The presumption here is that engineering leadership is the best source of intelligence and ideas. That now you are in a leadership role, you have a megaphone, so use it. This is a terrible, terrible practice.

If you truly do have the best knowledge, build support for your ideas through dialogue. Make engineers and other leaders feel like they own the idea.

Good managers build consensus. Good ideas build their own momentum. Bad managers use the megaphone, and push their ideas by avoiding dialogue. Even if their ideas are implemented through micromanagement/force of will, they do not stick, because no one else feels ownership.

Larson seems to think that engineering excellence from ICs is synonymous with doing what your manager tells you without question.

lolinder
0 replies
19h41m

I'm not convinced you actually read the article at all. Here's just one extract of several that to me says exactly what you're saying, except it's Larson speaking:

It's key to not confine your conflict mining strategy to your peer group on the leadership team. “You can usually get buy-in from other executives pretty easily, but it’s much more difficult to get buy-in from people with the most context around a given problem,” he says, “Their opinion is most valuable because they are the ones who live in the details. You can’t lie to them. They know the truth of how things run.”

This immediately follows an anecdote where he talks about listening to an engineer and realizing that his approach was wrong and the engineer was right. The whole section on "micromanagement" is really about this—get down into the weeds with your engineers and listen to what they have to say.

I get from your other comment that you have had bad experiences with people "applying" Larson's ideas in the past, but I'm really not seeing that at all in this text.

dahart
0 replies
3h26m

If you truly do have the best knowledge, build support for your ideas through dialogue. […] Good managers build consensus.

This sounds like good ideas. And also sounds a lot like what I just read in the article…

I don’t think there was any presumption that eng leaders are the “best” source of ideas. But there is a presumption he tried to communicate that they should participate, because they have experience, rather than recuse themselves from technical decisions.

icedchai
1 replies
19h35m

It depends. My best managers have been engineers. You generally don't need a full time engineering manager for a small 4 person team. If you do, your org is probably dysfunctional.

I will say though, if you're going to do both, do a good job, meaning one you'd expect of your reports. Don't be a manager that hands off his half-working project "to take it over the line." Finish your work.

otteromkram
0 replies
17h26m

My best managers have been engineers.

Right. The other comment said that people don't move into management because they are a great engineer. That doesn't mean managers haven't been engineers.

hibikir
0 replies
15h21m

My dark perspective here is that what Will is saying is that, as the number of people under you grows, the ability of some people to completely bungle everything up without consequences goes up. And this isn't really about really bad engineers, but really bad first and second level managers, as upper levels are often quite bad at identifying performance at those roles.

So what I think will is saying is not really to not trust your engineers, but to mistrust your managers.

datadrivenangel
4 replies
21h59m

An engineer turned to the executive dark side is still an engineer, and if they use their seat at the table to keep an approximately optimal amount of engineering quality up they'll need to pay attention and micromanage the details sometimes.

tired_and_awake
2 replies
21h20m

It's really a balancing act. It's also surprisingly difficult as an eng-exec with a deep eng background to correct some things without accidentally undermining those around you. Happy to provide examples of this comment is too vague.

solidasparagus
0 replies
18h0m

I'd love some examples. Making that transition is challenging, especially when you are a true SME. I would value any data points to learn from.

sokoloff
0 replies
20h30m

There’s definitely a balance and even within the challenging something that smells wrong, there are grades of undermining, ranging from public pronouncement of “y’all are lazy or incompetent and I know better” to private “I think I misled you about a core constraint and that may have led you to assume the scope needed to be 4x as large in order to address that perceived constraint.”

I find it extremely rare that a source of issue is the former and relatively common that I’ve been confusing or incomplete in my own guidance. If it’s in my head only, it doesn’t exist for my team and I need to fix the issue at the source (me) and, in so doing, that might change the engineering course and/or estimate.

(I have also accidentally undermined my team unrelated to the above; IMO, the best response there is to acknowledge it and try not to repeat it, because if you do, people in the company are prone to try to exploit that to drive outcomes that they think is best for the company. That’s fine, but it may undermine your ability to lead change in the company and cede it to others.)

aa-b
0 replies
20h3m

Bill Gates was famous for this, about thirty years ago; Joel Spolsky wrote about it in https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev.... Maybe it was over the top, and I'm sure it didn't work all the time, but I feel like it would have contributed to Microsoft's success.

ska
1 replies
18h51m

To me this is completely orthogonal to "micromanagement", which is a real problem whether or not you understand the system your team is building.

You absolutely will be a better engineering leader if you a) understand deeply the system your team is working on (though perhaps not all the corners) and b) maintain enough technical knowledge to keep up with changes.

To my mind though micromanagement, on the other hand, is the art of making decisions for people when they don't need it, and leaving your team unable to progress without you hovering over the work.

In this view micromanagement is always a poor choice, even worse if you don't know enough to make good choices for those team members.

I suppose the steel man version is that in an effort to avoid making that mistake, inexperienced managers back off too far and don't understand enough about the work anymore. This is in my experience a real problem, but needs a different name.

It's often the case where a good senior technical leader/manager could do the work most or all of the team members, and in the case of more junior ones, probably do it much more efficiently also. But they can't do that and be effective at their own role. Group velocity of the team is highest when they mostly coach from the sidelines.

PaulStatezny
0 replies
13h9m

I think you're correct here that "micromanagement" in the article is a poor word choice.

It's unfortunate that so much writing (especially prescriptive writing) uses inaccurate terminology for the sake of effect. It's usually to the detriment of readers/listeners being able to soak in the wisdom that's there, as they get tripped up by the poor wording.

For example, I can 100% get behind the "Engineer" level advice for the "Micromanagement" section. (Namely, have a high bar of excellence, for example when reviewing others' code.)

But as you point out, this isn't really micromanagement.

OJFord
1 replies
17h37m

Doesn't the article scream loose grasp on technical side though? Maybe that's the author rather than Larson if they're different, but bits like how it turned out the senior engineer was right to be against automation, because they were using Ruby, come on. (I'm not saying the guy was wrong, it just seems poorly explained/understood.)

I'm not even sure how much I think it matters though, I think more important is that you know where you stand in terms of reporting, and that you're able to 'code-switch' as it were appropriately for a less technically inclined person. Are engineering leaders that 'understand things at a much lower level of detail' really 'the best', or are they just the ones that make it easiest for us?

(Maybe you could argue there's not a difference, but I don't think it goes without saying that the ability to communicate to technical & non-technical alike is not a valuable skill, or that it shouldn't be required.)

itsdrewmiller
0 replies
14h28m

Re: your point about code switching - I think that's basically his point here:

“The core challenge for engineering execs is they have to wear three different, kind of opposing hats. The best ones can toggle back and forth between them deftly.”
mbivert
0 replies
22h0m

Yeah the problem when higher-ups have little care for details is that they may act on an imprecise-to-incorrect understanding of the factual reality ("the map isn't the territory", yada-yada).

There's a middle-ground between micromanaging and making sure high-level decisions are deeply sound. The second point of the article is pretty much this again: make sure the decisions are based on tangible facts, and not on chimeras.

mangamadaiyan
0 replies
16h40m

"A deep understanding of low-level details" and "attention to detail" is not Micromanagement. They're very different things.

An author who deliberately abuses terminology is someone whose work I do not trust.

mensetmanusman
12 replies
1d

Deliver faster? Find 9 women for a baby in one month.

Sales is trivially parallelized, engineering is not.

datadrivenangel
6 replies
21h39m

"If I buy you another copy of the mythical man-month, will you be able to read it twice as fast?"

deciplex
3 replies
21h27m

That's a waste of money: simply rip all the pages out of the book and lay them out separately on a flat surface somewhere. Then I can read half the book at once, flip all the pages over, and read the other half. Easy.

cjblomqvist
1 replies
21h8m

If you have two copies, following that logic, you can then actually read it twice as fast!

deciplex
0 replies
20h50m

Yes I thought of that but my method allows us to drive down latencies significantly, while keeping costs about the same overall. If we want to get them as low as possible though, as you say we could still benefit from having two copies. Not only do we get greater concurrency, we also can skip the step where we flip all the pages - so it's even better than twice as fast, actually.

We could even get the best of both worlds by laying the pages out on a clear surface, putting a camera on the other side, and hooking one of my eyes up to a feed of that camera. That would require some custom hardware and a little more up-front cost, though. We can look into whether that's cheaper than just buying another book.

Either method is a huge improvement on this "read two pages at a time" business, in any case.

itishappy
0 replies
20h39m

Pfft, read? Just take a picture of all the pages laid out and feed it to AI. Boom, that's productivity baby! You don't even need to ask follow-up questions as accuracy and usefulness are irrelevant. How could you judge anyway, you didn't read that damn book!

scrlk
1 replies
21h5m

If only there was an audiobook - listen to it at 2x speed. :^)

OJFord
2 replies
17h25m

That analogy always bothers me, because you absolutely can increase throughput in your ..'business' with more women; an established ..'pipeline' of 9 women will produce one baby every month.

(There might be an off by one error there if you want to take it too literally; even aside from the variation in gestation period. Point is it is a parallelisable task, whereas the whole point of MMM is to argue that it's not parallelisable, that you can't increase throughput with more resources.)

jboy55
1 replies
16h21m

Great if you can wait 9 months for the pipeline to start producing babies, but the analogy is if you want the first one in a month.

HelloNurse
0 replies
8h37m

And it isn't just the first "baby". What if you decide to pivot your animal production pipeline from horses to cows? In software development, unfinished work set aside to start from scratch is worthless and it doesn't even allow you to recover some capital by selling replaced animals.

ghaff
1 replies
1d

Even the post acknowledges that it's not really true of sales either. Maybe if your sales is about cold calling prospects, just amping up the rate of contacting people has some correlation to closed deals. Of maybe expanding geography does with B2B sales. But things like building channels, digital marketing, field enablement/training, doing planning for major accounts, managing the whole process etc. are often a lot more important than just adding warm bodies.

hobs
0 replies
21h49m

Expected Anti-Pattern #1 - Engineers will trivialize other's contributions to the process and consider it "trivially something."

ubertaco
6 replies
5h40m

The advice here, summarized:

- Don't listen to people who tell you not to micromanage. You know better than your engineers do about how to do their jobs!

- Try to start fights. If it's not happening organically, manufacture some by heavy-handed prescriptiveness of cargo-cult approaches. What even _is_ a "power dynamic" anyways? Sounds made-up to me.

- Never question bad metrics. The company knows best! Except when you know best, at which point you need to involve the CEO in your team's day-to-day. They don't have anything else to do _anyways_, and your team will _love_ having the CEO hovering over their shoulders all the time!

- Never try to shield your team from bad corporate decisions. I mean, it's not _your_ problem, it's _theirs_ anyways!

This blog post was definitely written by someone who's lived in the cushy bubble of a particular flavor of consequence-free upper-level management for so long that they can no longer remember what the ground even looks like, let alone empathize with the folks digging the trenches.

If someone in management recommended this article, I'd take that as a red flag about their reporting chain.

demosthanos
1 replies
4h47m

I get that engineers have general beef with management "techniques" of any kind—the whole concept feels manipulative and/or hand-wavy—but the comments in this article are disappointing and not really up to what I expect from HN. Multiple people read the section headings (which are absolutely provocative, unnecessarily so) and decided correctly they'd get lots of internet points for writing "summaries" that are actually just caricatures of the worst management practices they could imagine someone recommending under that section heading.

The article honestly isn't that bad and has a number of interesting points to make. I recommend reading it rather than just dismissing it out of hand because of caricatures in the HN comments.

celrod
0 replies
3h24m

Yeah, I don't think it's useful (except to score [office] political points) to read the least generous interpretation you can. Trying to understand a position lets you better decide whether or not it actually makes sense, e.g. Chesterton's fence. Although, if we tried to fairly assess every argument we see, we'd spend all our time doing that instead of being productive, so I get why it's often wise to dismiss things out of hand, at least initially.

You can disagree with the article, but I think your parent comment is not a fair summary, e.g. w/ respect to bullets 1 and 2:

At first, I thought, ‘This is a really unreasonable person.’ But later as I dug into it, I discovered he was right...This process of conflict mining served Larson a key lesson. “I could have just ignored him, But then I would have missed the key learning, which is that I was the one who was missing context, and needed to refine my approach.”

Maybe the parent comment was "conflict mining" itself. Often the quickest way to learn about something is to make a statement about it and then let others correct you if you're wrong.

On the other hand, "what is a power dynamic" is a fair counterpoint to that. Jeff Bezos, in contrast, said he generally withheld his opinion until the end so others wouldn't be afraid to contradict him; a powerful person sharing their idea can prevent others from sharing better ones.

CaptainOfCoit
1 replies
5h4m

They're anti-patterns, meaning you shouldn't follow them. Think of it as sarcasm, and the "advice" becomes what you should avoid.

At least that's how your summary reads to me.

demosthanos
0 replies
4h46m

The summary bears almost no relation to the actual article content.

The article is essentially arguing that the common management advice that circulates in our industry has caused too many engineers-turned-managers to pivot too far in the opposite direction from the caricature that OP created above, to the point where they've reached another ineffective part of the manifold of possible management styles. It argues that there's a space between OP's caricature and the traditional, ineffective engineering manager/executive and that in that space they can have real impact.

walrushunter
0 replies
3h28m

Some amount of micro-management is key to being a good manager. If you're not directly involved in what your reports are doing, it's difficult to know whether they're doing a good job or not.

Most IC engineers are cowards that refuse to give negative feedback about a peer even when it's anonymous. In order to really know how your reports are doing, you need to get down into the details with them. I've seen way too many low performer engineers survive for years just because their manager doesn't know enough about their work to know they suck.

rjmill
0 replies
3h11m

While I can totally see toxic managers reading this, and thinking, "Ha! I told them my management style isn't toxic," my takeaways were a bit different. I read it as being about the dangers of overcorrecting when trying to avoid bad management practice.

To play a charitable devil's advocate, here's my summary:

- You should have some understanding of what your people are working on.

- Suggesting a (potentially) bad idea is an efficient way to get people to teach you all the information you're missing.

- Rather than pinning down the perfect metrics, try to make do with the imperfect measurements that you already have. What do you want to achieve with those measurements? Focus on the end result (e.g., CEO understanding) rather than the metrics themselves.

- Don't sacrifice transparency on the altar of your shit umbrella. Protecting your team is good. Hiding things from them is bad.

I think these ideas could have been expressed better, to make them less easy to misconstrue. (I might be misconstruing the article in my summary! I'm honestly not 100% sure myself.)

If a toxic manager recommends this article and doesn't change their behavior, then that's definitely a red flag. They'll read anything and take it as vindication that they're doing the right thing.

zer00eyz
5 replies
21h7m

Holly fuck balls this is all bullshit.

You're a cost center. Servers, staff, throw product and design in there. Do you know why the metrics are all bullshit.

Because the metrics are the ones that marketing and sales use to show off. They dont fucking matter one bit to tech.

How much does each user of your system cost on a monthly basis? Is that an average? Do you have clients that are higher or lower cost (because they pay the same rate and consume more services?) ... If your sales team brings you growth in that group is it doing any one any good?

Can you tell me per user how much of that cost is going to cloud or infra? How much of it is going to staff? Is what your staff working on going to move the needle on one of those numbers? No? Is your engineering effort going to lower the cloud bill? Is it going to shorten your testing and release cycle?

"Value" is not some abstract concept, Its very concrete and very real. Put those numbers up, make them fucking real time numbers. Tell your engineering team that their bonus is tied to making those numbers better. Empower your team to tell sales and marketing NO, Or tell them that they need to raise the dam prices.

You want to super charge your engineering team. Get them out socializing with the other nerds in the building, that's everyone who works for the CFO. Embed an accountant in every tech team to figure out how to account (literally) for the changes they are making.

itsanaccount
2 replies
20h17m

Its absolutely hilarious to me that in software we have all these computers and yet "management"/"leadership" tracks things by some combination of gut feelings and bullshit spreadsheets/wiki pages.

Its deer in the headlights when I suggest we use the computers to audit and track the computers.

But we know why that is. Tech is the last bastion of the middle class in this rape and pillage extractionist economy we have. Tech is backwards enough, built in the artistic ruins of techno-libertarian dreams of silicon valley and we don't dare change it. Just like medieval farms with their strange rules on who got to use what land and harvest what trees, rules so complex that you need a collection of managing lower lords who knew the local customs for the king to extract value from the land (software). This industry is kept in its insane state a means of protecting all of our jobs that don't have to exist.

When running computers ceases being bullshit, most of us are going to join the ranks of everyone else in the overly optimized manufacturing and service jobs all scraping to get by.

skydhash
0 replies
15h41m

The fact is that computers automate most tedious parts of business and personal workflows. But not everyone can "computer-speak". Here come the programmers and for a time, it was sane. Then people wanted more automation and tech companies started selling software. Productivity ramped up, but the foundation is mostly porcelain, fragile to any changes in business workflow. Whenever we got a more resilient piece of software, that because it went back to "computer-speak".

So the choice is either a horde of programmers maintaining the fragile machinery or getting everyone to know "computer-speak". We were getting to the the second option when everyone knew that you have to take a training course to use a computer properly, but now they're presented as "intuitive" (aka magic, so no need to learn anything) and we're back to the first option. Now they're emphasizing the "magic" aspect with AI, meaning bullshit can happen.

I'll be worried when people chose the bullshit instead of getting results.

datavirtue
0 replies
14h45m

I recently listened to a CEO go on and on about Generation Z and Millennials this and that. He read a bunch of articles and is trying to shift the org to welcome in Gen Z who want: "a million dollars for nothing", "the company to adapt to them" etc. And thats why we have bring your dog to work and unlimited PTO. I would say he needs to hire a consultant instead but that sounds worse.

It's abject panic in CEO world these days. After that rant and a lecture on being engaged, he banned gym shoes and T-shirts.

I looked around and noticed that all the people wearing T-shirts and gym shoes were 50+.

engineers_unite
1 replies
20h36m

"Holly fuck balls this is all bullshit." TOTALLY. Never seen someone so wrong be so celebrated. This guy makes horrid engineering orgs.

zer00eyz
0 replies
19h29m

Engineering?

By what metric do we even call ourselves engineers any longer? What are we measuring against? what standard are we holding ourselves to?

The advice the poster is giving leads to stories like this: "I Accidentally Saved Half A Million Dollars" https://news.ycombinator.com/item?id=38069710

If your goal is to have better engineering then then just tie all their work to the only metric that matters, the bottom line.

AnimalMuppet
5 replies
21h48m

"Anytime you apply a rule too universally, it turns into an anti-pattern."

That's probably true in more than just engineering.

jmcphers
2 replies
21h27m

Are you saying that it applies ... universally?

AnimalMuppet
1 replies
21h21m

No, I'm not. I am saying that it probably applies more universally than we think it does.

(Unless you think it applies absolutely universally, in which case... yeah.)

OJFord
0 replies
17h32m

They were joking along the not quite paradoxical lines that it would then apply to itself and be an anti-pattern.

ozzmotik
1 replies
21h0m

How can one apply a rule more than universally? Wouldn’t too universally be the same thing as just universally? put differently, how can you do something MORE universally than universally?

asking for a friend

antod
0 replies
18h46m

Metaversally is the approach at Facebook

_se
4 replies
21h45m

I think this is a good article, but it could be about 25% the length and then it would be great instead.

Galanwe
1 replies
21h40m

That extra 25% being unbearable self promotion makes it 100% more annoying.

sokoloff
0 replies
20h29m

It’s an extra 300% though…

itsdrewmiller
0 replies
14h26m

That's funny because maybe my favorite thing about An Elegant Puzzle (the interviewee's book on engineering management) is its economy - it lays out a position and briefly explains then moves on to the next topic.

coffeebeqn
0 replies
18h29m

I stopped reading the fifth time “Uber, Stripe and Carta” was mentioned without anything meaningful said yet

throwaway115
3 replies
21h31m

There's just too many people in tech, because tech needs too many people. Once we have better tools to reduce complexity and allow teams to be much much smaller, many of these problems will vanish, because a engineering team will consist of 1-3 wizard engineers who control all aspects of the tech. We simply do not need to have teams as big as they are, for what we're ultimately doing.

p5a0u9l
0 replies
15h3m

Maybe true for pure software projects. There are other things in tech - robots, from drones and cars to rockets, for example. There are complicated systems that will never, even with banger LLMs, be designed and executed by a small team. Some teams are lightweight and agile and manage to work magic. Maybe tools will help a little there… not so sure. Systems of systems has boggled planners since the first Apollo program, at least. It’s roughly the same approach today.

itsanaccount
0 replies
19h48m

You're right, but look at my other comment here you don't want what you say you want.

Vegenoid
0 replies
30m

I do not believe that this will come to pass, based on the trajectory of software engineering over the past decades. There just aren't enough wizard engineers to satisfy demand, and I don't see that changing. People have been trying to come up with tools and techniques to be more effective with smaller teams since the dawn of software engineering, and it just isn't happening on a wide scale.

Taking care of complexity via good tooling and pre-packaged abstractions can only go so far, and few operational realities are static and well-oiled enough to avoid regularly running into new problems.

makk
3 replies
18h28m

The article discusses three unexpected anti-patterns in engineering leadership:

1. Micromanagement Avoidance: Sometimes, engaging in details can prevent leaders from becoming bureaucrats and help in making informed decisions.

2. Flawed Metrics: Measuring something imperfect but useful is better than not measuring at all, helping to build intuition and understanding.

3. Umbrella Leadership: Shielding teams from external pressures can hinder their growth. Involving them in challenges builds resilience and better prepares them for the future.

These lessons are drawn from experiences at Stripe, Uber, and Carta.

derwiki
2 replies
15h49m

Thanks ChatGPT?

darylteo
1 replies
13h41m

I think top-comment was trying to save people a click?

makk
0 replies
3h56m

That article seriously needed a TL;DR. So many words to make so little point. I thought I’d save people some trouble by providing it. Seems the crowd prefers doing it the hard way. Live and learn.

Scubabear68
3 replies
21h0m

This is a great article.

In particular, so many technical leaders work in a vacuum with no context. People joining a company as a technical leader needs to absolutely dig in and understand the existing landscape and processes, and not try to just blindly reuse what they did at the last gig.

engineers_unite
2 replies
20h33m

You are hired to bring in your context and personality and experience. Do not fall in the same traps the org has been in. If they didn't need help and change, you would not have been hired.

darylteo
0 replies
13h42m

If only this were true always in reality.

In some cases, you were only hired because the previous person "was doing a bad job" and they need someone "to do a good job" but in reality, the previous person wasn't even able to make any decisions, and was in fact just being strung along with the top-down direction, leading to bad results, and that person got fed up and left.

Scubabear68
0 replies
16h51m

All true. If you go in blindly without understanding where they actually are (and how they got there), then you are sure to muck things up pretty badly.

flockonus
2 replies
19h34m

I've been thinking since "business" usually drives direction of engineering efforts, what metrics could be applied to those in such positions?

Are the quality of those decisions evaluated, as measured by their costs and outcomes?

Macha
1 replies
18h56m

I've been in orgs where it's up to engineering to measure that, and it's treated as a failure of engineering if they're not positive.

flockonus
0 replies
17h56m

Yes, as most orgs using ORKs that tends to be the case; so yes, same in my observation.

0xbadcafebee
2 replies
19h47m

  > “People look at recruiting the same way. ‘If we do five hires per quarter per recruiter, we just need to add two more recruiters and we’ll be hitting our targets.’” However, engineering leaders will be hard-pressed to find a similar lever to pull. “For engineering, there are just no measures that I find super helpful here
The lever isn't people, we've known that one since the 70's. But what we've learned over the past 15 years is that more quality, speed, and reliability through automation and shifting left, is a lever that works. A decade worth of DevOps reports show this to be true: the high performers do certain things, and the low performers don't. If you do the things, you also start performing at a high level. But you have to actually do them, not just intone tech jargon and hope for the best, like so many ineffectual leaders have.

  > when you hear from your eng leaders that ‘Engineering is an art, and you can’t predict how it’s going to work,’ it’s frustrating. They’re sitting there thinking, ‘They’re telling me this is art, but I’m spending $100 million on this art each year.’ That’s not reassuring.”
But you can predict how it's going to work. It has barely been written down, and it is never really taught, but everything you need to know is out there. There's no mystery to producing software products. Ask any veteran. The same stupid bullshit keeps happening, until you do certain things, and then the bullshit stops, and things start working better.

  > too many well-meaning engineering leaders go by the book of conventional leadership advice.
Too many engineering leaders don't understand that not all "engineering" is Engineering.

If you want to engineer a building or a brake caliper or something, that's not art. You use math and science and engineering skills to design the thing to work, based on what is known to work and quantifiable and specific criteria.

But to actually manufacture the thing you engineered - quickly, effectively, without defects - that is a craft and an art.

There's designing a thing, there's building a thing, and there's operating a thing. These are very different things, and require very different ways of working. Software people have this bizarre misconception that somehow they're all the same thing, like some blob of random actions that they should intuitively know, and will execute flawlessly without any kind of enforced process or continuous improvment, and it should be easy, predictable, cheap, fast...... That's not how the world works.

But I get it. Not everyone is a veteran who has seen and done all the things and knows the right way to do all the different things. The thing is, you don't even need to know the right way to do things. What you do need to do is rely on data. Look at DORA metrics and the qualities of high-performing teams. Change how your org is working until those metrics improve. Continuously iterate on improvement, through process, experimentation, study, refinement. If you walk that walk (not just talk the talk), you will get improvement, predictability, value.

But you know how many engineering leaders I've seen actually walk the walk? One. And he got canned by political pressure because he was making other leaders look bad.

lifeisstillgood
0 replies
19h17m

From yourself and sibling comment I get three metrics that matter

- speed - stability - cost

And honestly I think those really work

Vegenoid
0 replies
53m

A decade worth of DevOps reports show this to be true: the high performers do certain things, and the low performers don't.

It has barely been written down, and it is never really taught, but everything you need to know is out there. There's no mystery to producing software products. Ask any veteran. The same stupid bullshit keeps happening, until you do certain things, and then the bullshit stops, and things start working better.

Can you elaborate on what these things are? This comes from place of seeking knowledge, not second-guessing.

up2isomorphism
1 replies
12h9m

I think anti-pattern is a strange word to begin with? Why is against whatever pattern are in general bad?

HelloNurse
0 replies
8h47m

"Anti-pattern" doesn't mean having an aversion for patterns in general, nor considering some pattern the opposite of another specific pattern: it means (with significant linguistic abuse) one of the undesirable bad patterns as opposed to the desirable good patterns.

Oarch
1 replies
4h53m

"a team of a couple hundred people. That team might cost $50 to 100 million in salary a year"

100m between 200 is 500K average salary. Seems exceptionally high.

zakary
0 replies
4h39m

I’m guessing the author is counting himself as CTO as part of that. $60 million for the CTO and his posse of senior managers and VPs, and the other $40m split between 180 non management engineers for $220k ish each. Still stupidly high costing now matter how you slice it.

xyzzy_plugh
0 replies
4h1m

There's a lot of vicious commentary here. I think there's a few points we can all agree on:

- this is a podcast summary/transcript

- the framing applied is a bit heavy

- Will Larson, without commenting on any other attributes, is at least able to be introspective, self-critical and reflect on his leadership abilities. Which is more than I can say about the vast majority of engineering leaders I've encountered.

I've read a fair bit of Larson's writings and on the whole I don't think they are necessarily right or wrong, it's clear he cares deeply about this problem space and invested in figuring it out. We should all hope to have such leaders in our org.

It's fairly obvious that any of the advice here could be wielded maliciously, ignorantly by self-centered egotistical management, which should surprise no one. Does that make all of this harmful, generally? I don't know. I hope not. But probably.

thenoblesunfish
0 replies
10h0m

Seems like the intro is asking how to get people to work on hard amd ambiguous problems, without treating them like humans. Don't think that works.

talkingtab
0 replies
7h14m

Larger scale software development is best done as a collaborative effort. The essence of that is the "co". Literally working together. How is this best done?

We have the idea that leaders make this happen, but as the top comment says, this post is about "cult of personality". Not "cult of community". It has been a common theme that startups have much higher velocity, and great lament that this velocity is lost as startups grow in size. This has led to the great myth of the mythical person month - that adding people to a software project slows it down.

It is not the addition of people, it is the destruction of community that slows things down. Think of a bee hive. We want more honey, so we get another hive of bees and dump them into the first hive. Is this an effective solution?

The bumbling around on this simple and elegant truth is both tragic and comedic. If software development is most efficient and effective when it is a community effort, then one must look into what makes for effective communities, eh?

We seem to live in a cult of personality time - not just in software (ahem). The solution is simply to build effective communities. This article is an anti-pattern for that. In my opinion.

softwaredoug
0 replies
20h33m

Not having clear expectations around their role in the overall development pipeline.

It's such a headache to be surprised by someone's sudden veto power over a decision. Or when someone doesn't own up to their role unexpectedly.

Managers need to debug those situations. Not (just) at a personal level, but at a ritual / process so people know their specific job and expectations. Like who signs off on design docs? How does a feature get shipped? Who exactly are the stakeholders in a type of decision? Most importantly: who should NOT be a stakeholder and needs to bugger off?

rendall
0 replies
11h44m

Larson maps out what skills make the top 1% of engineering execs stand out from the top 50%.

Does anyone know what metrics were used here to sort engineering execs into tiers? I didn't see this discussed in the article at all. Is this Larson's phrase or the article writer's?

lulznews
0 replies
1h20m

What’s the purpose of these VC puff pieces? Subtly pump the values of their portcos by raising their exec profiles?

hi-v-rocknroll
0 replies
19h43m

Make meaningful, comprehensible documentation that adds context and specifics. Unstructured, braindump walls of detail spew don't count.

galaxyLogic
0 replies
13h53m

‘Why did we go into this business? Why are we shutting down this business line? Why are we doing this services migration that's going to take five years?’ literally aren't written down anywhere.”

I see this all the time with my own projects. I try to document my code but what I often fail to write down is WHY. I might write down a decision to change something or to implement a new thing, but I don't write down the why. Why not? Because it is so OBVIOUS at the time the decision is made. It seems like a waste of time to write it down.

Consider also the "5 Whys". When we answer the why we answer it's because we want something particular to happen. But why do we want that particular thing to happen now and always? I don't write those whys down because it seems wasteful and a distraction from being focused on making concrete progress.

It's human nature.

foobarkey
0 replies
12h47m

Dear CEO-s,

There is a very simple way to increase engineering output by 10x, just remove everything related to these words:

- domain driven design - messaging - kafka - microservices - react / angular / svelte - distributed

Then when seeing an engineer just remind them: it puts the JSON in the db, it takes the JSON out of the db and puts it into HTML or it gets the hose again.

Engineers are a weird flock if left on their own they start dreaming up creative ways to put the JSON in the db instead of just doing it

_heimdall
0 replies
4h48m

“One of the biggest lessons in management over the last decade is that micromanagement is bad. But I think this is an anti-pattern, because it creates disengaged and context-free leadership"

Alternative from my experience, it creates trust. If you want employees to trust leadership, leadership needs to trust its employees. Simple as that.

Leadership needs to be clear on what its asking from their employees, but that means clear goals and specifications with context for why it matters.

At the end of the day every employee is different. Its a mistake to assume one approach will work for everyone, but the idea of leaning into micromanaging as the way feels really misguided IMO, unless you want the kind of culture that promotes.

Animats
0 replies
15h0m

Unsaid in that article is the implicit assumption that the product is webcrap. Not industrial controls, or code within a device that ships to the customer, or the internals of a database, router, or operating system. Implications of this include:

* Errors are mostly harmless, unless they occur too frequently.

* Failures that can be handled by having the end user retry something are generally OK.

* Changes are very frequent and are made for marketing reasons.

Hence the emphasis on moving fast and breaking things. The cost of the breakage does not fall on the implementing organization.