14 ms·
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
by 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 agojust 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 agoYes! 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.
- onion2k 2y agoEngineering 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.
- IshKebab 2y agoMaybe 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 2y agoIf a system requires saints and/or geniuses to work, it’s a bad system.
- lolinder 2y agoThey 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 2y agoThe 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.
- polynomial 2y ago(Machiavelli might have something he would like to say here.)
- Tao3300 2y ago"In corrupt republics, especially in untroubled times, men of first-class ability are ousted by the envy and ambitious scheming of others."
- lolinder 2y agoYour 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 2y ago1. 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 2y ago
- cortesoft 2y ago> 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?
- Aurornis 2y ago> 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 2y agoI 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 2y agosounds 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.
- hibikir 2y agoDisclaimer: 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.
- xwolfi 2y agoAnd 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.
- atomicnumber3 2y ago"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.
- barrenko 2y agoit'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