I have seen Will Larson's techniques applied/ forced in multiple organizations and have found that his view of the engineering world just does not work. I sense that there is a cult of personality around him that leads to engineering ivory towers.
Most orgs that I've seen follow his writing or ideas have ended up in conflict with the business and one another, isolated on a corporate island, and then gutted by layoffs.
I don't like to throw an author/engineer under the bus but I do not know why this guy has a following. I have never seen his methods result in happy engineers and delivered value.
My summary of this article (for managers): 1. Micromanage early and often 2. Measure, and whatever you're measuring, act like it's truth and that you know best. 3. Listen to the curmudgeons and the naysayers because they are the true sources of knowledge.
Edit- as I mention in a reply, try https://pragprog.com/titles/rjnsd/the-nature-of-software-dev... Ron Jeffries' "The Nature of Software Development". Incremental value, engineers leading delivery, constant feedback cycles, flexibility. I've followed the tenets of this book in many orgs, and they lead to measurable value, happy engineers, and successful orgs.
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.
If a system requires saints and/or geniuses to work, it’s a bad system.
(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."
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.
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 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.
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.
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.
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.
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.
"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.
And what if your manager seems to just not like you for whatever reason and won’t tell you why?
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 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.
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.
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.
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.
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.
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 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.
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.
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?
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.
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.
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.
What you are saying here is, for the lack of a better word, macro verification and that's completely valid.
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,”
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.
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.
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.
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!
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.
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.
So his advice would be to listen to your advice?