12 ms·

Unexpected anti-patterns for engineering leaders

378 points by jbredeche 2y ago

ozim 2y ago
Seems like doing actual work and thinking for yourself is too often substituted by using shortcuts. Wondering what’s worse being micromanager who doesn’t know the term or being hands off manager because of being afraid to micromanage or using it as excuse for not getting hands dirty.
hinkley 2y ago
> Only after spending time in several leadership roles did Larson realize that getting caught up on finding the right measurement was the anti-pattern. “Often when people start measuring, there's always a concern that their measurement is flawed. And that's true for all functions,” he says. “But I’m a believer in measuring something imperfect, but useful, versus holding out for the perfect metric while measuring nothing in the interim.” He doesn’t understand the problem. The problem is not the measurement, it’s the judgement that comes with the measurement. If we are to be judged by a metric that makes wins look like losses/neutral, or losses look neutral, of course we are going to push back. It’s unfair at best, and toxic at worst to make decisions based on bullshit metrics that punish and celebrate the wrong things. On the average it’s more entropy added to the project. It accelerates decay. The problem is not metrics. It’s the boss making conclusions from them. Particularly if they have to be talked out of the same wrong conclusion every fucking week for months at a time. Graphs are for asking questions, not answering them. Only if you understand this does the rest sort itself out.
mensetmanusman 2y ago
Deliver faster? Find 9 women for a baby in one month. Sales is trivially parallelized, engineering is not.
- ghaff 2y ago
  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 2y ago
    Expected Anti-Pattern #1 - Engineers will trivialize other's contributions to the process and consider it "trivially something."
- datadrivenangel 2y ago
  "If I buy you another copy of the mythical man-month, will you be able to read it twice as fast?"
  - deciplex 2y ago
    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 2y ago
      If you have two copies, following that logic, you can then actually read it twice as fast!
      - deciplex 2y ago
        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 2y ago
      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 2y ago
- OJFord 2y ago
  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 2y ago
    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.
    - OJFord 2y ago
      I said 'an established' pipeline. I don't believe the analogy is ever used in the 'you want the first one in a month' way, because there's myriad other ways to say it's idiotic to just go out hiring if you need something done stat. (Primarily: short-term, hires will reduce productivity, because established colleagues see an increase in the amount of support & knowledge-sharing they need to do, reducing their output by more than the new hire can yet offer.)
    - HelloNurse 2y ago
      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.
deleted 2y ago
[deleted]
hn_throwaway_99 2y ago
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.
- mbivert 2y ago
  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.
- datadrivenangel 2y ago
  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 2y ago
    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.
    - sokoloff 2y ago
      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.)
AnimalMuppet 2y ago
"Anytime you apply a rule too universally, it turns into an anti-pattern." That's probably true in more than just engineering.
- tired_and_awake 2y ago
  [dead]
- jmcphers 2y ago
  Are you saying that it applies ... universally?
  - AnimalMuppet 2y ago
    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 2y ago
      They were joking along the not quite paradoxical lines that it would then apply to itself and be an anti-pattern.
- ozzmotik 2y ago
  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
  - deleted 2y ago
    [deleted]
  - antod 2y ago
    Metaversally is the approach at Facebook
_se 2y ago
I think this is a good article, but it could be about 25% the length and then it would be great instead.
- Galanwe 2y ago
  That extra 25% being unbearable self promotion makes it 100% more annoying.
  - sokoloff 2y ago
    It’s an extra 300% though…
- coffeebeqn 2y ago
  I stopped reading the fifth time “Uber, Stripe and Carta” was mentioned without anything meaningful said yet
- itsdrewmiller 2y ago
  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.
throwaway115 2y ago
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.
- itsanaccount 2y ago
  You're right, but look at my other comment here you don't want what you say you want.
- p5a0u9l 2y ago
  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.
- Vegenoid 2y ago
  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.
zer00eyz 2y ago
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.
- deleted 2y ago
  [deleted]
- engineers_unite 2y ago
  "Holly fuck balls this is all bullshit." TOTALLY. Never seen someone so wrong be so celebrated. This guy makes horrid engineering orgs.
  - zer00eyz 2y ago
    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 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.
Scubabear68 2y ago
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 2y ago
  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.
  - Scubabear68 2y ago
    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.
  - darylteo 2y ago
    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.
deleted 2y ago
[deleted]
engineers_unite 2y ago
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-development/ 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.
- wcarss 2y ago
  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!
  - engineers_unite 2y ago
    Yes! I suggest starting with https://pragprog.com/titles/rjnsd/the-nature-of-software-development/ https://pragprog.com/titles/rjnsd/the-nature-of-software-dev... "The Nature of Software Development", by Ron Jeffries. Focus on incremental value, engage everyone, deliver and adjust.
softwaredoug 2y ago
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?
0xbadcafebee 2y ago
> “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.
hi-v-rocknroll 2y ago
Make meaningful, comprehensible documentation that adds context and specifics. Unstructured, braindump walls of detail spew don't count.
flockonus 2y ago
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 2y ago
  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 2y ago
    Yes, as most orgs using ORKs that tends to be the case; so yes, same in my observation.
metadat 2y ago
https://web.archive.org/web/20240530221938/https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/ https://web.archive.org/web/20240530221938/https://review.fi... (Reason: A surprisingly browser-hostile site that requires Javascript to show anything - it's ultimately only a text website.)
deleted 2y ago
[deleted]
makk 2y ago
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 2y ago
  Thanks ChatGPT?
  - darylteo 2y ago
    I think top-comment was trying to save people a click?
    - makk 2y ago
      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.
Animats 2y ago
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.
galaxyLogic 2y ago
> ‘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 2y ago
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
up2isomorphism 2y ago
I think anti-pattern is a strange word to begin with? Why is against whatever pattern are in general bad?
- HelloNurse 2y ago
  "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.
rendall 2y ago
> 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?
thenoblesunfish 2y ago
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 2y ago
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.
ubertaco 2y ago
[flagged]
- CaptainOfCoit 2y ago
  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 2y ago
    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.
- demosthanos 2y ago
  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.
  - watwut 2y ago
    I think that engineers would had better opinion of management techniques if those actually worked and if tech actually had more then a few good managers.The problem is that all too many management techniques are effectively cargo cult and all too many managers have low social skills. A very good example of a ad social skill is to use provocative sentences and then wonder why people react to your provocation.
Oarch 2y ago
"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 2y ago
  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.
_heimdall 2y ago
> “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.
xyzzy_plugh 2y ago
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.
- dasil003 2y ago
  Yeah, having been an engineer, tech lead and manager in various forms over the last 25 years, I have to saw I appreciate the thoughtfulness and nuance that Will Larson is trying to bring. The problem is nuance on its own doesn't really grab anyone's attention and it doesn't challenge assumptions, so things need to be spiced up a bit. But as soon as you do that people have knee-jerk reactions, usually based on specific lived experience and context that is far from universal. Ultimately the problem with management advice is that everything is contextual. A bad manager can abuse any advice, and a great manager can find a counter example to any advice. The right answer is pretty much always "it depends". On the internet though, there's generally not enough time or depth of connection to wade through the details that matter, and even when it's attempted, the vast majority don't have the experience and expertise to draw the right lessons from deep case studies anyway. Instead, what is successful are blanket statements and platitudes that reflexively resonate with some large group of people. The problem with that kind of content is that it gives a dopamine hit but is absolutely worthless in terms of actually developing expertise. Building large scale software systems is hard, managing teams of talented engineers to build those systems in a constantly changing business environment is even harder. Anyone who says different is naive or selling something.
lulznews 2y ago
What’s the purpose of these VC puff pieces? Subtly pump the values of their portcos by raising their exec profiles?

378 points by jbredeche 2y ago

ozim 2y ago

Seems like doing actual work and thinking for yourself is too often substituted by using shortcuts. Wondering what’s worse being micromanager who doesn’t know the term or being hands off manager because of being afraid to micromanage or using it as excuse for not getting hands dirty.

hinkley 2y ago

> Only after spending time in several leadership roles did Larson realize that getting caught up on finding the right measurement was the anti-pattern. “Often when people start measuring, there's always a concern that their measurement is flawed. And that's true for all functions,” he says. “But I’m a believer in measuring something imperfect, but useful, versus holding out for the perfect metric while measuring nothing in the interim.” He doesn’t understand the problem. The problem is not the measurement, it’s the judgement that comes with the measurement. If we are to be judged by a metric that makes wins look like losses/neutral, or losses look neutral, of course we are going to push back. It’s unfair at best, and toxic at worst to make decisions based on bullshit metrics that punish and celebrate the wrong things. On the average it’s more entropy added to the project. It accelerates decay. The problem is not metrics. It’s the boss making conclusions from them. Particularly if they have to be talked out of the same wrong conclusion every fucking week for months at a time. Graphs are for asking questions, not answering them. Only if you understand this does the rest sort itself out.

mensetmanusman 2y ago

Deliver faster? Find 9 women for a baby in one month. Sales is trivially parallelized, engineering is not.

ghaff 2y ago
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 2y ago
  Expected Anti-Pattern #1 - Engineers will trivialize other's contributions to the process and consider it "trivially something."
datadrivenangel 2y ago
"If I buy you another copy of the mythical man-month, will you be able to read it twice as fast?"
- deciplex 2y ago
  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 2y ago
    If you have two copies, following that logic, you can then actually read it twice as fast!
    - deciplex 2y ago
      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 2y ago
    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 2y ago
OJFord 2y ago
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 2y ago
  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.
  - OJFord 2y ago
    I said 'an established' pipeline. I don't believe the analogy is ever used in the 'you want the first one in a month' way, because there's myriad other ways to say it's idiotic to just go out hiring if you need something done stat. (Primarily: short-term, hires will reduce productivity, because established colleagues see an increase in the amount of support & knowledge-sharing they need to do, reducing their output by more than the new hire can yet offer.)
  - HelloNurse 2y ago
    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.

deleted 2y ago

[deleted]

hn_throwaway_99 2y ago

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.

mbivert 2y ago
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.
datadrivenangel 2y ago
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 2y ago
  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.
  - sokoloff 2y ago
    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.)

AnimalMuppet 2y ago

"Anytime you apply a rule too universally, it turns into an anti-pattern." That's probably true in more than just engineering.

tired_and_awake 2y ago
[dead]
jmcphers 2y ago
Are you saying that it applies ... universally?
- AnimalMuppet 2y ago
  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 2y ago
    They were joking along the not quite paradoxical lines that it would then apply to itself and be an anti-pattern.
ozzmotik 2y ago
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
- deleted 2y ago
  [deleted]
- antod 2y ago
  Metaversally is the approach at Facebook

_se 2y ago

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

Galanwe 2y ago
That extra 25% being unbearable self promotion makes it 100% more annoying.
- sokoloff 2y ago
  It’s an extra 300% though…
coffeebeqn 2y ago
I stopped reading the fifth time “Uber, Stripe and Carta” was mentioned without anything meaningful said yet
itsdrewmiller 2y ago
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.

throwaway115 2y ago

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.

itsanaccount 2y ago
You're right, but look at my other comment here you don't want what you say you want.
p5a0u9l 2y ago
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.
Vegenoid 2y ago
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.

zer00eyz 2y ago

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.

deleted 2y ago
[deleted]
engineers_unite 2y ago
"Holly fuck balls this is all bullshit." TOTALLY. Never seen someone so wrong be so celebrated. This guy makes horrid engineering orgs.
- zer00eyz 2y ago
  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 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.

Scubabear68 2y ago

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 2y ago
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.
- Scubabear68 2y ago
  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.
- darylteo 2y ago
  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.

deleted 2y ago

[deleted]

engineers_unite 2y ago

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-development/ 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.

wcarss 2y ago
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!
- engineers_unite 2y ago
  Yes! I suggest starting with https://pragprog.com/titles/rjnsd/the-nature-of-software-development/ https://pragprog.com/titles/rjnsd/the-nature-of-software-dev... "The Nature of Software Development", by Ron Jeffries. Focus on incremental value, engage everyone, deliver and adjust.

softwaredoug 2y ago

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?

0xbadcafebee 2y ago

> “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.

hi-v-rocknroll 2y ago

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

flockonus 2y ago

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 2y ago
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 2y ago
  Yes, as most orgs using ORKs that tends to be the case; so yes, same in my observation.

metadat 2y ago

https://web.archive.org/web/20240530221938/https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/ https://web.archive.org/web/20240530221938/https://review.fi... (Reason: A surprisingly browser-hostile site that requires Javascript to show anything - it's ultimately only a text website.)

deleted 2y ago

[deleted]

makk 2y ago

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 2y ago
Thanks ChatGPT?
- darylteo 2y ago
  I think top-comment was trying to save people a click?
  - makk 2y ago
    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.

Animats 2y ago

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.

galaxyLogic 2y ago

> ‘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 2y ago

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

up2isomorphism 2y ago

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

HelloNurse 2y ago
"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.

rendall 2y ago

> 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?

thenoblesunfish 2y ago

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 2y ago

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.

ubertaco 2y ago

[flagged]

CaptainOfCoit 2y ago
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 2y ago
  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.
demosthanos 2y ago
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.
- watwut 2y ago
  I think that engineers would had better opinion of management techniques if those actually worked and if tech actually had more then a few good managers.The problem is that all too many management techniques are effectively cargo cult and all too many managers have low social skills. A very good example of a ad social skill is to use provocative sentences and then wonder why people react to your provocation.

Oarch 2y ago

"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 2y ago
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.

_heimdall 2y ago

> “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.

xyzzy_plugh 2y ago

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.

dasil003 2y ago
Yeah, having been an engineer, tech lead and manager in various forms over the last 25 years, I have to saw I appreciate the thoughtfulness and nuance that Will Larson is trying to bring. The problem is nuance on its own doesn't really grab anyone's attention and it doesn't challenge assumptions, so things need to be spiced up a bit. But as soon as you do that people have knee-jerk reactions, usually based on specific lived experience and context that is far from universal. Ultimately the problem with management advice is that everything is contextual. A bad manager can abuse any advice, and a great manager can find a counter example to any advice. The right answer is pretty much always "it depends". On the internet though, there's generally not enough time or depth of connection to wade through the details that matter, and even when it's attempted, the vast majority don't have the experience and expertise to draw the right lessons from deep case studies anyway. Instead, what is successful are blanket statements and platitudes that reflexively resonate with some large group of people. The problem with that kind of content is that it gives a dopamine hit but is absolutely worthless in terms of actually developing expertise. Building large scale software systems is hard, managing teams of talented engineers to build those systems in a constantly changing business environment is even harder. Anyone who says different is naive or selling something.

lulznews 2y ago

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