Unexpected anti-patterns for engineering leaders
review.firstround.com
review.firstround.com
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.
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!
"The Nature of Software Development", by Ron Jeffries. Focus on incremental value, engage everyone, deliver and adjust.
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.
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.
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?”
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.
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,”
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 - "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.
So his advice would be to listen to your advice?
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.
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.
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.
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.
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.
You'll see this approach to running a business everywhere other than the tech industry.
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.
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'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.
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.
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.
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.
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!
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 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.
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.
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.
- 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.
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.
* 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.
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.
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.)
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?
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.
> 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.
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 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.
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.
So what I think will is saying is not really to not trust your engineers, but to mistrust your managers.
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.
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.
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.)
> “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.”
An author who deliberately abuses terminology is someone whose work I do not trust.
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.
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?
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?
That's probably true in more than just engineering.
(Unless you think it applies absolutely universally, in which case... yeah.)
asking for a friend
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.
(Reason: A surprisingly browser-hostile site that requires Javascript to show anything - it's ultimately only a text website.)
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.
Are the quality of those decisions evaluated, as measured by their costs and outcomes?
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.
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.
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
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.
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.
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.
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.
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.
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+.
100m between 200 is 500K average salary. Seems exceptionally high.
> “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.
- speed - stability - cost
And honestly I think those really 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.
Can you elaborate on what these things are? This comes from place of seeking knowledge, not second-guessing.
Sales is trivially parallelized, engineering is not.
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.
(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.)
(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.)
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 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.
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.