[HN Gopher] Unexpected anti-patterns for engineering leaders
___________________________________________________________________
Unexpected anti-patterns for engineering leaders
Author : jbredeche
Score : 133 points
Date : 2024-05-30 16:46 UTC (6 hours ago)
(HTM) web link (review.firstround.com)
(TXT) w3m dump (review.firstround.com)
| mensetmanusman wrote:
| Deliver faster? Find 9 women for a baby in one month.
|
| Sales is trivially parallelized, engineering is not.
| ghaff wrote:
| 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 wrote:
| Expected Anti-Pattern #1 - Engineers will trivialize other's
| contributions to the process and consider it "trivially
| something."
| datadrivenangel wrote:
| "If I buy you another copy of the mythical man-month, will you
| be able to read it twice as fast?"
| deciplex wrote:
| 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 wrote:
| If you have two copies, following that logic, you can then
| actually read it twice as fast!
| deciplex wrote:
| 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 wrote:
| 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 wrote:
| If only there was an audiobook - listen to it at 2x speed.
| :^)
| hn_throwaway_99 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| engineers_unite wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| icedchai wrote:
| 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.
| AnimalMuppet wrote:
| "Anytime you apply a rule too universally, it turns into an anti-
| pattern."
|
| That's probably true in more than just engineering.
| jmcphers wrote:
| Are you saying that it applies ... universally?
| AnimalMuppet wrote:
| 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.)
| ozzmotik wrote:
| 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
| _se wrote:
| I think this is a good article, but it could be about 25% the
| length and then it would be great instead.
| Galanwe wrote:
| That extra 25% being unbearable self promotion makes it 100%
| more annoying.
| sokoloff wrote:
| It's an extra 300% though...
| throwaway115 wrote:
| 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 wrote:
| You're right, but look at my other comment here you don't want
| what you say you want.
| zer00eyz wrote:
| 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.
| engineers_unite wrote:
| "Holly fuck balls this is all bullshit." TOTALLY. Never seen
| someone so wrong be so celebrated. This guy makes horrid
| engineering orgs.
| itsanaccount wrote:
| 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.
| Scubabear68 wrote:
| 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 wrote:
| 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.
| engineers_unite wrote:
| 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.
| wcarss wrote:
| 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 wrote:
| Yes! I suggest starting with
| 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.
| IshKebab wrote:
| 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 wrote:
| If a system requires saints and/or geniuses to work, it's a
| bad system.
| lolinder wrote:
| 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 wrote:
| 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.
| lolinder wrote:
| Your summary of this article is dismissive and misleading. It
| might be a 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:
|
| 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,"
| softwaredoug wrote:
| 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 wrote:
| > "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 wrote:
| Make meaningful, comprehensible documentation that adds context
| and specifics. Unstructured, braindump walls of detail spew don't
| count.
| metadat wrote:
| A surprisingly browser-hostile site.
|
| https://web.archive.org/web/20240530221938/https://review.fi...
| flockonus wrote:
| 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?
___________________________________________________________________
(page generated 2024-05-30 23:00 UTC)