Unexpected anti-patterns for engineering leaders(review.firstround.com)
review.firstround.com
Unexpected anti-patterns for engineering leaders
https://review.firstround.com/unexpected-anti-patterns-for-engineering-leaders-lessons-from-stripe-uber-carta/
163 comments
Disclaimer: I was Will's direct report, and then Will became my skip level in a past life. I'd rate him as better than average manager, who was surrounded by a lot of well under average managers.
I'd love to hear longer stories on your opinion here, because I have theories on the issues with Will's advice, but nobody sees quite enough organizations to quite be certain. The more stories we hear, the more likely we are to get things right.
My hypothesis is that Will's advice is a lot of recipes to create change in organizations, but lacks focus on when to apply them, and how to be sure you aren't bungling it all up by fixing the wrong problem. This makes the ideas more attractive to the dashing, aggressive, confident executive, whether he has a good pulse on the problems, or he is the kind to trust on the wrong people, and fail to see that they are building enemies (as all agents of change do), without getting sufficient number of fans in the right places. So people that like his advice will tend to fail by overstepping. I know some executive who have an entire career like this, company after company: Seeing themselves as the protagonist of every story, and acting like bulls in a china shop, therefore failing politically even if their diagnosis was somehow right, and their changes made sense.
Ultimately the best advice is 'make sure your manager likes you'. Which works just as well if you are a CTO reporting to a CEO, or an engineer reporting to a line manager. It's trivially easy for executives to think this isn't the case, and then be surprised when the reorg comes.
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.
> but lacks focus on when to apply them
The gap between theory and practice - tacit knowledge - is probably a factor here. It seems quite likely that a lot of really good managers in software have theories about why they are good managers. Those theories could all easily be wrong and they are actually experts at communication or weird technical details that happen to make great managers. A manager's theoretical base is always built on a large tacit "I know how to X, Y, Z in a social setting".
If we look at this article through a very abstract lens, software managing advice fits the pattern of "at the appropriate moment, do the appropriate thing". Obviously the advice he gives is heavily tinged by the managers ability to identify the appropriate moment to do something unusual. He's pointing out some times where the appropriate action seemed to be the counter-intuitive one, which is fair and interesting. But I wouldn't ever trust a random manager to be able to pick the moment to do a counter-intuitive action; unless they were mentored with extreme care.
The gap between theory and practice - tacit knowledge - is probably a factor here. It seems quite likely that a lot of really good managers in software have theories about why they are good managers. Those theories could all easily be wrong and they are actually experts at communication or weird technical details that happen to make great managers. A manager's theoretical base is always built on a large tacit "I know how to X, Y, Z in a social setting".
If we look at this article through a very abstract lens, software managing advice fits the pattern of "at the appropriate moment, do the appropriate thing". Obviously the advice he gives is heavily tinged by the managers ability to identify the appropriate moment to do something unusual. He's pointing out some times where the appropriate action seemed to be the counter-intuitive one, which is fair and interesting. But I wouldn't ever trust a random manager to be able to pick the moment to do a counter-intuitive action; unless they were mentored with extreme care.
"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.
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.
it's pretty goddamn stupid and seems to need constant reiteration for some people (like me!!!) but if you don't feel a cultural fit (from you as an employee point of view) - DON'T TAKE THE JOB
With the current market, I wish I had the power to refuse a job in lieu of a better culture fit But alas.
Karellen(1)
And what if your manager seems to just not like you for whatever reason and won’t tell you why?
Try to change roles or companies?
I don't mean this flippantly here, it's a crap situation to find yourself in but sometimes people just don't get along, or people are just not great, and you do need to know when to cut your losses and make a move.
I don't mean this flippantly here, it's a crap situation to find yourself in but sometimes people just don't get along, or people are just not great, and you do need to know when to cut your losses and make a move.
Running away shouldn’t be the first option IMO.
Never said it should be the first option but if your direct manager doesn't like you and won't talk about it, you don't have that many options.
There is a power imbalance at play, and you are not on the good end of it.
Framing it as "running away" is weird.. One of the most important life skills is to know when to pick your battles.
If you go over their head, and they get forced into a discussion with you, then what? You think that will improve the relationship? And do you want to have that person responsible for your ongoing career opportunities and advancements?
Unless they are actually breaking some rules, there isn't much HR or a leader high up can or will do. In fact I bet their recommendation would be to change teams as well.
I'd love to hear your suggestions though.
There is a power imbalance at play, and you are not on the good end of it.
Framing it as "running away" is weird.. One of the most important life skills is to know when to pick your battles.
If you go over their head, and they get forced into a discussion with you, then what? You think that will improve the relationship? And do you want to have that person responsible for your ongoing career opportunities and advancements?
Unless they are actually breaking some rules, there isn't much HR or a leader high up can or will do. In fact I bet their recommendation would be to change teams as well.
I'd love to hear your suggestions though.
Thanks for adding more context and nuance. In the scenario you seem to be describing, I‘d consider leaving too - my situation isn’t that bad. I think a last resort could be to request a 1on1 and speak Tacheles, and maybe find a better basis on which to communicate. If that doesn’t work out, I think leaving is an option to definitely look at, life‘s too short for bad relationships (if they can be avoided).
Let me start by saying I didn't realize you were speaking about your own experience! I thought we were having a theoretical discussion here. That changes the stakes on your end of course..
Just a question, when you say "request a 1 on 1" do you mean request to specifically speak about this? Or do you not have regular 1-on-1s with your manager already?
I think it's a concern that your manager doesn't already have or want weekly 1-on-1 meetings. Do you know if this is with all their reports, or just you?
If it's with all their reports, that's.. honestly? not a great manager.
It's just with you, then I think that's further evidence that this person does not, and will not, have your best interests in mind.
I'm sorry you're in this situation, I hope you find a good outcome!
Just a question, when you say "request a 1 on 1" do you mean request to specifically speak about this? Or do you not have regular 1-on-1s with your manager already?
I think it's a concern that your manager doesn't already have or want weekly 1-on-1 meetings. Do you know if this is with all their reports, or just you?
If it's with all their reports, that's.. honestly? not a great manager.
It's just with you, then I think that's further evidence that this person does not, and will not, have your best interests in mind.
I'm sorry you're in this situation, I hope you find a good outcome!
People will never tell you if they like you or not and why
The emotional intelligence to pick up on that sub context is critical. Observe how they treat others, look for subtleties, think about them as people rather than your boss.
It really comes down to 2 things: if you had a beer with them would they enjoy your company; are you a good employee who’s not making them look bad by their managers.
The emotional intelligence to pick up on that sub context is critical. Observe how they treat others, look for subtleties, think about them as people rather than your boss.
It really comes down to 2 things: if you had a beer with them would they enjoy your company; are you a good employee who’s not making them look bad by their managers.
The ability to enjoy a beer with them is irrelevant.
The only question is, “Are you making them look good to their manager/customer/spouse/peers?”
Ultimately, that’s what you’ve been hired to do.
In a healthy context, you’re doing that by hitting your KPI’s, adding velocity, etc., but not necessarily.
The only question is, “Are you making them look good to their manager/customer/spouse/peers?”
Ultimately, that’s what you’ve been hired to do.
In a healthy context, you’re doing that by hitting your KPI’s, adding velocity, etc., but not necessarily.
But that's missing the point. You can be doing all of those things but your manager still may not like you. Admittedly they're probably more likely to like you if you're a good employee, but if they like you and you're a subpar employee you're going to be much better off than if they don't like you. And, if you're a stellar employee, you'll likely be presented with more opportunities/more favourable tasks/etc than a stellar employee your manager doesn't like.
You can take the view of "I'm doing my job" but don't be surprised if those around you who are more liked by management get picked up for promotions/etc more than you. Most people (management included) are not 100% objective in their decision making, and someone liking you (or not) is going to influence their decisions involving you.
You can take the view of "I'm doing my job" but don't be surprised if those around you who are more liked by management get picked up for promotions/etc more than you. Most people (management included) are not 100% objective in their decision making, and someone liking you (or not) is going to influence their decisions involving you.
Thanks, that gives me something to think about. I guess being fully remote makes it a bit hard to pick up on these clues, but maybe I can make better use of the HQ visits.
And you ignore the fact that maybe you are more to credit for his success than he was. Engineers aren't fungible, aren't all the same, arent all compatible with each other and the manager. Your conclusion is the right one but can we always make it happen ? No.
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.
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.
If a system requires saints and/or geniuses to work, it’s a bad system.
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.
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.
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.
A system designed to be idiot-proof is eventually designed by the idiots.
It will also create a system of idiots. As in limit peoples development, retain the less capable and chase away the capable.
(Machiavelli might have something he would like to say here.)
"In corrupt republics, especially in untroubled times, men of first-class ability are ousted by the envy and ambitious scheming of others."
> If it works don't fix it: we don't need to do any maintenance
My counter argument is “Why don’t you have automated test coverage so you’re free to make maintenance or engineering improvements without fear of breaking things?”
My counter argument is “Why don’t you have automated test coverage so you’re free to make maintenance or engineering improvements without fear of breaking things?”
One thing I have noticed with over zealous testers is to get 100% coverage they mock everything and test implementations. Then you end up writing 2x the code to get anything done. I think it's a net negative. I have more often had to rewrite tests in these environments then have them actually save me from shipping a bug.
This is why I very heavily favour functional tests or broad use-case based integration tests that are implementation agnostic. Save your highly coupled unit/property based tests for algorithmic code or weird edge cases when things are settled. More generally, even many TDD people advocate “spike then stabilise” as an approach.
That is such a sweet feeling - doing what you feel is good test suite (maybe not TDD perfectionistic 100%but good) then few months later you add a new feature and the tests find some subtle bug that would have affected production.
Because the same engineers that write buggy code write buggy tests?
Why don’t you have automated test coverage so you’re free to make maintenance or engineering improvements without fear of breaking things?
Because that's equivalent to solving the Halting Problem. Even if you could test your way to quality in a non-interactive context, it would never be possible in a system that includes asynchronous human input.
Because that's equivalent to solving the Halting Problem. Even if you could test your way to quality in a non-interactive context, it would never be possible in a system that includes asynchronous human input.
Just don't make asynchronous human input turing complete, there's plenty of machines for which the halting problem is solvable.
Good question, ask my entire industry. Games defintiely has logic that isn't easily covered by automated systems, but there's plenty of deterministic code that could be put under test. We rarely get such luxury of time to implement that, though.
> 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.
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.
I think micro management is often misunderstood. The usual run off the mill micromanagement, that almost every terrible manager follows is what I call micro verification. Double guessing every step you take and adding a verification layer on top of it. In the long run, it erodes the confidence and risk taking abilities of employees and overall completely detrimental to a company.
Real micromanagement is the ability to dive in and solve unsolvable bugs or issues, rally the team until the minutest detail of an issue has been hashed out or remove any micro obstacle. Once a manager shows skin in the game and proves themselves, they often win the minds and hearts of all engineers, who then feel inspired to get into micro details themselves.
Now like a sleight of hand, you have scaled accountability and integrity in your team.
So micromanagement done in the right situation and in the spirit of moving things forward is highly beneficial. In most cases, however micromanagement devolves into this micro verification tool that every mediocre manager uses to justify their existence.
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.
Why is verification bad? I think it’s actually the thing that prevents the worst forms of micro management. Micro management to me means telling people what to do in detail. That removes autonomy.
The way to build trust and create autonomy while also keeping surprises to a minimum, is to tell your team what you expect of them and why. And crucially, you ask your team about their plan on how to get there. This still lets them decide on the “how”, while you can step in if you feel the plan is wrong. That is verification and it helps.
The way to build trust and create autonomy while also keeping surprises to a minimum, is to tell your team what you expect of them and why. And crucially, you ask your team about their plan on how to get there. This still lets them decide on the “how”, while you can step in if you feel the plan is wrong. That is verification and it helps.
Managers systematically micromanage when employees are showing incompetence. Because yes, every spelling mistake must be corrected before sending to the customer (“You are reviewing ALL my emails!”). The employee can’t be trusted for a task he’s not competent at (and it’s neither’s fault, maybe lack of courage to fire, or too much compassion for the employee - better that than unemployment).
I don’t see micromanagement as a red flag. I can’t imagine a manager who wouldn’t enjoy independent autonomous reports who only require broad directions and resources to perform their work.
I don’t see micromanagement as a red flag. I can’t imagine a manager who wouldn’t enjoy independent autonomous reports who only require broad directions and resources to perform their work.
sounds more like "micro-leading" than micromanagement. Every company varies, but management's time tables tend to be 80-100% meetings while a lead is more 40-60% depending on the week. A manager may not even be technical enough to understand the problems being solved by who they manage in smaller orgs.
I really don't get managers whose timetables have 100% meetings. Weekly 1:1s is at the max 10-20 hours assuming a 10:1 engineer to manager ratio.
If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ? They may choose not to do so, but if a problem is not getting solved and they can't act in such a time of need, their existence is totally questionable.
If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ? They may choose not to do so, but if a problem is not getting solved and they can't act in such a time of need, their existence is totally questionable.
A manager with 100% meetings is often one of a few cases:
1. They use useless meetings as shields for their time. That is, I can put myself on a meeting that I never attend so that I am less likely to be booked for that time. I will often have time blocks on my calendar because I work in functional workplaces for me, but this can be useful in toxic environments.
2. They have additional project/product management responsibilities. This is common for platform teams that they don't have PM support and have to wrangle people themselves.
3. They're really working 50+ hours a week and do their real work afterwards or before. This is common in places that oversubscribe managers. (I've hat 15 and even 25 reports before. I've even seen 50.)
4. They don't know how to say no and guard their time. This is common with younger managers.
1. They use useless meetings as shields for their time. That is, I can put myself on a meeting that I never attend so that I am less likely to be booked for that time. I will often have time blocks on my calendar because I work in functional workplaces for me, but this can be useful in toxic environments.
2. They have additional project/product management responsibilities. This is common for platform teams that they don't have PM support and have to wrangle people themselves.
3. They're really working 50+ hours a week and do their real work afterwards or before. This is common in places that oversubscribe managers. (I've hat 15 and even 25 reports before. I've even seen 50.)
4. They don't know how to say no and guard their time. This is common with younger managers.
>If a manager is not technical enough to delve into an issue within their team, should they even be leading that team ?
From my experience, this type of manager is more like that of a producer, merely called manager. Their job leans more on the lead to understand the technical planning, while they themselves coordinate between leads. In addition, they are also the direct contact for (often non-technical) stakeholders, so their strengths may lay more on securing deals/clients as opposed to developing/maintaining the product.
Lots of hats being worn in such a role between "kinda tech", PR, sales, and producing, so these happen semi-often in smaller companies, and almost never in a sufficiently large company.
From my experience, this type of manager is more like that of a producer, merely called manager. Their job leans more on the lead to understand the technical planning, while they themselves coordinate between leads. In addition, they are also the direct contact for (often non-technical) stakeholders, so their strengths may lay more on securing deals/clients as opposed to developing/maintaining the product.
Lots of hats being worn in such a role between "kinda tech", PR, sales, and producing, so these happen semi-often in smaller companies, and almost never in a sufficiently large company.
Oh yeah, you are describing a leader here. They are hustling for the next best project to take on for their team and/or for the company. They have moved beyond solving today's problems and spend most of their time on tomorrow's or the next year's problems.
Wouldn't maintaining that standard make it effectively impossible to ever find any manager able to lead a team whose members have deep specialized expertise, especially if the team has expertise in more than one area?
I'm sorry, but 100% meetings is incredibly unproductive. There is plenty of work to do as a manager in a business. Most involves a spreadsheet for doing time-tracking, resource management, cost analysis, ie, managerial accounting. A healthy administration is aware of how the money flows through a business and this depends on having eyes and ears on the ground.
You'll see this approach to running a business everywhere other than the tech industry.
You'll see this approach to running a business everywhere other than the tech industry.
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!
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!
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.
"The Nature of Software Development", by Ron Jeffries. Focus on incremental value, engage everyone, deliver and adjust.
Engineering Management is largely about the 'engage everyone' part, and that is incredibly hard in an org where the devs aren't engaged. Getting them back on side with the business is rarely straightforward. Being an Engineering Manager now after 25 years as a dev that's the sort of problem I find interesting, but it definitely isn't easy. I've only been in my first EM role for a short while and I definitely haven't found a working solution yet.
> 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?
So his advice would be to listen to your advice?
Your summary of this article is unnecessarily dismissive and misleading. It might be an accurate summary of what you saw in organizations that purported to be following this guy's advice, but I think we should let the article write its own tldr. Here are some of the key extracts that capture the actual ideas, which are in each case very different from your summary:
Yours: > 1. Micromanage early and often
Theirs: > New engineering managers are often advised to “step away from the code.” But an extremely high-functioning exec understands the domain they are operating in at some level of detail. As you get too far out of the details, you just become a bureaucrat. Too many well-meaning engineering managers end up as bureaucrats.
Yours: > 2. Measure, and whatever you're measuring, act like it's truth and that you know best.
Theirs: > "I think where I’ve gone wrong in the past, and where engineering leaders get into trouble, is by pushing back. They focus on saying ‘This is a terrible way to measure,’ instead of saying, ‘Let’s start here and drill in until we can understand the limitations of measuring this way."
Yours: > 3. Listen to the curmudgeons and the naysayers because they are the true sources of knowledge.
Theirs: > “I’m a big believer in bringing folks into the room so that they can represent themselves rather than having small decision groups. I like working out problems in larger groups where you can hold people accountable for showing up in thoughtful and effective ways,”
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,”
1. Managers ARE bureaucrats, though. That's what the job is, integrating employees into processes. If you want to be a principal engineer doing architecture, that's a different career track than management.
2. You should not "get into trouble" for pushing back on flawed metrics, as long as the pushback is actionable and constructive. No metric may indeed be better than a bad metric in a lot of cases.
3. If you're "bringing everyone into the room" to make engineering decisions then either you have a very small company, or you just treat all engineers as juniors (meshes well with constant micromanagement, of course). Google doesn't "bring everyone into the room" to make tech decisions about networking, they bring the networking experts into the room (the "small decision groups" the author hates).
In summary, it all sounds very Dilbert.
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.
1 - I don't think he's trying to use bureaucrat precisely here - he's saying that the role of engineering manager is more valuable if they understand their domain vs. if they do not. This seems uncontroversial; staffing decisions for projects are more likely to be made correctly when those projects are understood.
2 - "should not" and "will not" are not the same thing. A huge part of bridging the divide between general management and engineering management is finessing the issue of performance/productivity measurement.
3 - Yeah I agree, I like a lot of Larson's stuff but not this. I kind of wonder how much of it is even real vs. just posturing; as you say it doesn't scale well at all, and he's worked at very large companies.
2 - "should not" and "will not" are not the same thing. A huge part of bridging the divide between general management and engineering management is finessing the issue of performance/productivity measurement.
3 - Yeah I agree, I like a lot of Larson's stuff but not this. I kind of wonder how much of it is even real vs. just posturing; as you say it doesn't scale well at all, and he's worked at very large companies.
Part of a manager's job is to suggest better measurements if the ones that are in use are flawed.
I used to work for someone who believed in 'bringing everyone into the room'. It was fine when that meant a team of 7 people, but he got promoted and kept doing it with 25 or 40 people, mostly irrelevant and mostly unheard. He once scheduled a meeting "in case anyone had something to say". It's probably clear that I didn't find him effective.
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.
- 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.
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.
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.
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.
* 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.
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.
To me this is completely orthogonal to "micromanagement", which is a real problem whether or not you understand the system your team is building.
You absolutely will be a better engineering leader if you a) understand deeply the system your team is working on (though perhaps not all the corners) and b) maintain enough technical knowledge to keep up with changes.
To my mind though micromanagement, on the other hand, is the art of making decisions for people when they don't need it, and leaving your team unable to progress without you hovering over the work.
In this view micromanagement is always a poor choice, even worse if you don't know enough to make good choices for those team members.
I suppose the steel man version is that in an effort to avoid making that mistake, inexperienced managers back off too far and don't understand enough about the work anymore. This is in my experience a real problem, but needs a different name.
It's often the case where a good senior technical leader/manager could do the work most or all of the team members, and in the case of more junior ones, probably do it much more efficiently also. But they can't do that and be effective at their own role. Group velocity of the team is highest when they mostly coach from the sidelines.
You absolutely will be a better engineering leader if you a) understand deeply the system your team is working on (though perhaps not all the corners) and b) maintain enough technical knowledge to keep up with changes.
To my mind though micromanagement, on the other hand, is the art of making decisions for people when they don't need it, and leaving your team unable to progress without you hovering over the work.
In this view micromanagement is always a poor choice, even worse if you don't know enough to make good choices for those team members.
I suppose the steel man version is that in an effort to avoid making that mistake, inexperienced managers back off too far and don't understand enough about the work anymore. This is in my experience a real problem, but needs a different name.
It's often the case where a good senior technical leader/manager could do the work most or all of the team members, and in the case of more junior ones, probably do it much more efficiently also. But they can't do that and be effective at their own role. Group velocity of the team is highest when they mostly coach from the sidelines.
I think you're correct here that "micromanagement" in the article is a poor word choice.
It's unfortunate that so much writing (especially prescriptive writing) uses inaccurate terminology for the sake of effect. It's usually to the detriment of readers/listeners being able to soak in the wisdom that's there, as they get tripped up by the poor wording.
For example, I can 100% get behind the "Engineer" level advice for the "Micromanagement" section. (Namely, have a high bar of excellence, for example when reviewing others' code.)
But as you point out, this isn't really micromanagement.
It's unfortunate that so much writing (especially prescriptive writing) uses inaccurate terminology for the sake of effect. It's usually to the detriment of readers/listeners being able to soak in the wisdom that's there, as they get tripped up by the poor wording.
For example, I can 100% get behind the "Engineer" level advice for the "Micromanagement" section. (Namely, have a high bar of excellence, for example when reviewing others' code.)
But as you point out, this isn't really micromanagement.
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.
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.
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.
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.)
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.)
I'd love some examples. Making that transition is challenging, especially when you are a true SME. I would value any data points to learn from.
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.
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.
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.
> My best managers have been engineers.
Right. The other comment said that people don't move into management because they are a great engineer. That doesn't mean managers haven't been engineers.
Right. The other comment said that people don't move into management because they are a great engineer. That doesn't mean managers haven't been engineers.
I'm happy to say that one of my managers was also the best engineer I've ever worked with. He told me he didn't really like managing but basically did it because he didn't felt like he had a choice.
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?
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?
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.
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.
> If you truly do have the best knowledge, build support for your ideas through dialogue. […] Good managers build consensus.
This sounds like good ideas. And also sounds a lot like what I just read in the article…
I don’t think there was any presumption that eng leaders are the “best” source of ideas. But there is a presumption he tried to communicate that they should participate, because they have experience, rather than recuse themselves from technical decisions.
This sounds like good ideas. And also sounds a lot like what I just read in the article…
I don’t think there was any presumption that eng leaders are the “best” source of ideas. But there is a presumption he tried to communicate that they should participate, because they have experience, rather than recuse themselves from technical decisions.
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.
> 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.
My dark perspective here is that what Will is saying is that, as the number of people under you grows, the ability of some people to completely bungle everything up without consequences goes up. And this isn't really about really bad engineers, but really bad first and second level managers, as upper levels are often quite bad at identifying performance at those roles.
So what I think will is saying is not really to not trust your engineers, but to mistrust your managers.
So what I think will is saying is not really to not trust your engineers, but to mistrust your managers.
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.
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.
"A deep understanding of low-level details" and "attention to detail" is not Micromanagement. They're very different things.
An author who deliberately abuses terminology is someone whose work I do not trust.
An author who deliberately abuses terminology is someone whose work I do not trust.
Doesn't the article scream loose grasp on technical side though? Maybe that's the author rather than Larson if they're different, but bits like how it turned out the senior engineer was right to be against automation, because they were using Ruby, come on. (I'm not saying the guy was wrong, it just seems poorly explained/understood.)
I'm not even sure how much I think it matters though, I think more important is that you know where you stand in terms of reporting, and that you're able to 'code-switch' as it were appropriately for a less technically inclined person. Are engineering leaders that 'understand things at a much lower level of detail' really 'the best', or are they just the ones that make it easiest for us?
(Maybe you could argue there's not a difference, but I don't think it goes without saying that the ability to communicate to technical & non-technical alike is not a valuable skill, or that it shouldn't be required.)
I'm not even sure how much I think it matters though, I think more important is that you know where you stand in terms of reporting, and that you're able to 'code-switch' as it were appropriately for a less technically inclined person. Are engineering leaders that 'understand things at a much lower level of detail' really 'the best', or are they just the ones that make it easiest for us?
(Maybe you could argue there's not a difference, but I don't think it goes without saying that the ability to communicate to technical & non-technical alike is not a valuable skill, or that it shouldn't be required.)
Re: your point about code switching - I think that's basically his point here:
> “The core challenge for engineering execs is they have to wear three different, kind of opposing hats. The best ones can toggle back and forth between them deftly.”
> “The core challenge for engineering execs is they have to wear three different, kind of opposing hats. The best ones can toggle back and forth between them deftly.”
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.
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.
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.
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.
You're right, but look at my other comment here you don't want what you say you want.
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?
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?
> 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?
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?
I think this is a good article, but it could be about 25% the length and then it would be great instead.
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.
I stopped reading the fifth time “Uber, Stripe and Carta” was mentioned without anything meaningful said yet
"Anytime you apply a rule too universally, it turns into an anti-pattern."
That's probably true in more than just engineering.
That's probably true in more than just engineering.
Are you saying that it applies ... universally?
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.)
(Unless you think it applies absolutely universally, in which case... yeah.)
They were joking along the not quite paradoxical lines that it would then apply to itself and be an anti-pattern.
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.
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.
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.)
(Reason: A surprisingly browser-hostile site that requires Javascript to show anything - it's ultimately only a text website.)
> ‘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.
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.
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?
Are the quality of those decisions evaluated, as measured by their costs and outcomes?
> 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.
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.
> “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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
The fact is that computers automate most tedious parts of business and personal workflows. But not everyone can "computer-speak". Here come the programmers and for a time, it was sane. Then people wanted more automation and tech companies started selling software. Productivity ramped up, but the foundation is mostly porcelain, fragile to any changes in business workflow. Whenever we got a more resilient piece of software, that because it went back to "computer-speak".
So the choice is either a horde of programmers maintaining the fragile machinery or getting everyone to know "computer-speak". We were getting to the the second option when everyone knew that you have to take a training course to use a computer properly, but now they're presented as "intuitive" (aka magic, so no need to learn anything) and we're back to the first option. Now they're emphasizing the "magic" aspect with AI, meaning bullshit can happen.
I'll be worried when people chose the bullshit instead of getting results.
So the choice is either a horde of programmers maintaining the fragile machinery or getting everyone to know "computer-speak". We were getting to the the second option when everyone knew that you have to take a training course to use a computer properly, but now they're presented as "intuitive" (aka magic, so no need to learn anything) and we're back to the first option. Now they're emphasizing the "magic" aspect with AI, meaning bullshit can happen.
I'll be worried when people chose the bullshit instead of getting results.
I recently listened to a CEO go on and on about Generation Z and Millennials this and that. He read a bunch of articles and is trying to shift the org to welcome in Gen Z who want: "a million dollars for nothing", "the company to adapt to them" etc. And thats why we have bring your dog to work and unlimited PTO. I would say he needs to hire a consultant instead but that sounds worse.
It's abject panic in CEO world these days. After that rant and a lecture on being engaged, he banned gym shoes and T-shirts.
I looked around and noticed that all the people wearing T-shirts and gym shoes were 50+.
It's abject panic in CEO world these days. After that rant and a lecture on being engaged, he banned gym shoes and T-shirts.
I looked around and noticed that all the people wearing T-shirts and gym shoes were 50+.
"Holly fuck balls this is all bullshit." TOTALLY.
Never seen someone so wrong be so celebrated. This guy makes horrid engineering orgs.
Engineering?
By what metric do we even call ourselves engineers any longer? What are we measuring against? what standard are we holding ourselves to?
The advice the poster is giving leads to stories like this: "I Accidentally Saved Half A Million Dollars" https://news.ycombinator.com/item?id=38069710
If your goal is to have better engineering then then just tie all their work to the only metric that matters, the bottom line.
By what metric do we even call ourselves engineers any longer? What are we measuring against? what standard are we holding ourselves to?
The advice the poster is giving leads to stories like this: "I Accidentally Saved Half A Million Dollars" https://news.ycombinator.com/item?id=38069710
If your goal is to have better engineering then then just tie all their work to the only metric that matters, the bottom line.
[deleted]
"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.
100m between 200 is 500K average salary. Seems exceptionally high.
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.
Make meaningful, comprehensible documentation that adds context and specifics. Unstructured, braindump walls of detail spew don't count.
What’s the purpose of these VC puff pieces? Subtly pump the values of their portcos by raising their exec profiles?
I think anti-pattern is a strange word to begin with? Why is against whatever pattern are in general bad?
"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.
[deleted]
[deleted]
> “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
> 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.”
> too many well-meaning engineering leaders go by the book of conventional leadership advice.
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.
> A decade worth of DevOps reports show this to be true: the high performers do certain things, and the low performers don't.
> It has barely been written down, and it is never really taught, but everything you need to know is out there. There's no mystery to producing software products. Ask any veteran. The same stupid bullshit keeps happening, until you do certain things, and then the bullshit stops, and things start working better.
Can you elaborate on what these things are? This comes from place of seeking knowledge, not second-guessing.
> It has barely been written down, and it is never really taught, but everything you need to know is out there. There's no mystery to producing software products. Ask any veteran. The same stupid bullshit keeps happening, until you do certain things, and then the bullshit stops, and things start working better.
Can you elaborate on what these things are? This comes from place of seeking knowledge, not second-guessing.
From yourself and sibling comment I get three metrics that matter
- speed - stability - cost
And honestly I think those really work
- speed - stability - cost
And honestly I think those really work
[deleted]
ubertaco(4)
Deliver faster? Find 9 women for a baby in one month.
Sales is trivially parallelized, engineering is not.
Sales is trivially parallelized, engineering is not.
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.
Expected Anti-Pattern #1 - Engineers will trivialize other's contributions to the process and consider it "trivially something."
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.)
(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.)
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.
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.
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.)
(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.)
"If I buy you another copy of the mythical man-month, will you be able to read it twice as fast?"
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.
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!
If you have two copies, following that logic, you can then actually read it twice as fast!
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.
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.
If only there was an audiobook - listen to it at 2x speed. :^)
Here is a ten minute summary: https://open.spotify.com/episode/6EwppFDqNNyXIFZqbbITvt
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.
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.
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.
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.
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.
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.
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.
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.
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.