"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.
I got a harsh lesson about this in one of my very first jobs.
A senior engineer on my team had built a rather complicated system. He was accordingly intimately familiar with all aspects of it. So when he estimated something on that system, it came with nearly all the discovery work already done.
The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me.
The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me.
This is a really good thing to learn from, although I doubt it felt like it at the time. The key thing that every junior dev needs to take from it is that it's fine if things don't take however long the estimate is so long as you're regularly communicating with the PM. PMs hate surprises. They need to know exactly what the state of the project is at any given moment. For them to think that a story is progressing on track when it's not is very, very bad (in their minds; it doesn't actually matter most of the time.)
If you work on a story that's estimated to take 3 days and come back after 3 days saying "It's not done yet. I'm only half way through. I had to learn a ton of stuff!" then that knocks out loads of other things, and people get pissed off.
If you work on a story that's estimated to take 3 days, and in the stand up on day 2 you say "I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days" then your PM will (...should?) respect that you're keeping them informed. The senior might even step up to help you get there faster.
Practically all the actual work a PM does is communication. If you're not communicating with them then you're blocking them. No one likes that.
> I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days
Their first question after you say this will be "well, how long will it take?" Whether or not you actually have any idea how much time you'll need, you'll have to give an answer, and on that blows the schedule up too much will be strongly frowned upon.
Now you've realized you're working for a crappy PM/EM who wants you to do their job for them, since they should have already known that the estimate from the first engineer will be nowhere close to the reality from the second.
The best managers I've had have been the ones that rarely need time estimates. They know enough about what's going on, and the comparative skill levels of the engineers, to give reasonable estimates themselves in most cases.
I disagree. I think skill of manager plays into it more than anything. I've seen managers come on board and within 3-6 months were able to operate like this. They focused on learning the technology and getting to know the people before they started actively managing. These were large, long running teams they were joining too.
I can double tap on that. Good manager is able to understand the product and estimate by himself.
Ive had quite a bit of experience working with different managers and overall those who were „invested” and got familiar with the product „really well” could estimate for the team.
This isn't true even with a organized, disciplined team. What happens is the responsibilities of get divided out to other people on the team. Usually not the entire team, so some people are stuck with unacknowledged overhead.
Unacknowledged overhead happens even with a PM present. Usually it's work that is absolutely critical to getting a project done but a PM would tell you it's a waste of time if you brought it up with them.
meh. The problem is authority. PM / manager as described above is a co-ordination issue. Often administrative as well.
Either the company is imposing administrative burden a that it can remove with a little effort and scripting, or again it is co-ordination - which software usually excels at.
We can endlessly debate specifics but yes, there are many corporate environments that are almost impossible to navigate without full-time skilled administration - it that is a choice by the company not an inherent law of nature.
I seem to recall a Microsoft anecdote where someone released an internal form for developers to fill out, and billg personally sent round collecting the form telling people that sort of thing was not the Microsoft way. Far be MSFT from an ideal but bureaucracy is a choice.
Edit: my take on hierarchy and decision making is that it is clearly "obvious" that in war and times of stress there is only enough time for one person, the "hero", to review the battlefield and make decisions, which everyone else then follows. The problem with that is throughout human history that idea has literally had no better than 50/50 chance of succeeding.
I am very much short on Project management, administrative management as authority and generally anything that points away from democracy.
Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this.
When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a programmer is productive from day zero and all programmers have exactly the same output. It's so wrong
I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.
>I think they underestimate the value of specific knowledge
This is the crux of the issue. When it comes to "Knowledge Work" almost every step sooner or later becomes a specialization. For example, I used to sneer at the role of a "Build Engineer" until i was forced to take up that role in one project. The combination of HW Platforms, OS versions, config switches, build flags, magic incantations etc. quickly gave me a new found respect for a job which i had considered "trivial".
It is that one tends to underestimate the complexity involved in a particular job which has evolved well beyond its initial "trivial" requirements. Hence the need to guard consciously against such tendencies particularly in domains where you may not be competent.
I find that doesn't really capture the difference. In programming, the building part is fully automated. You press play or type a compile command and wait. If someone wants a build estimate, you should give them the time it takes to compile an deploy. Code is blueprint. Writing the code is all engineering, R&D, design and architecture and it usually entails figuring out how the system will interface with countless protocols, legacy systems, details of user's lives etc. It's nothing like building something that is already fully planned. It's a lot more like researching and planning all the details.
If you wrote a novel and wanted your friend to write the final chapter, then would you need to train them in your novel beforehand? Not that much different from programming.
We're just the nerds who push the nerd-buttons. We don't need to understand how it works, or why it should be this way not that way, or what the margins are. Just push the nerd-buttons and the damn thing work like it does in my head! All the hard work has been done by the ideas people who had to do all the creative stuff and make all the hard decisions. Now it just needs to be put into the computer-thingies and work!
Any tech recruiter who tells you there should be no ramp-up for programmers is lying, and you should be accordingly wary if they use a lot of "hit the ground running" talk. Fact is, nobody does that. In some jobs it might take as long as six months for programmers to reach the desired level of productivity.
I think most of us have been in your situation in the early days of our career. I still remember these PMs after all those years as rather inexperienced or incompetent and try to make sure that it does not happen on the teams i oversee.
This is just extremely (almost comically) bad project management - nobody should take a senior engineer's estimate and apply it to a new hire or jr engineer.
I've never been a PM but from my planning discussions with mine all have adjusted for seniorness, familiarity with the codebase, and skillset. When I give an estimate I am only asked to give it for myself, it's the PMs job to adjust.
I guess I've been lucky because I've never had a PM that did that poor of a job. Maybe because it's because I've almost exclusively worked at companies that provide work to a paying customer, because that environment really depends on good project management.
That engineer is Senior in title only. Unfortunately this is a common pattern - a mid-level developer will play "hero", make a mess that only they understand, and - if given the title/responsibility by immature management - proceed to royally screw their team.
Actual Seniors have the experience and foresight to handle this properly. Either build code with enough documentation/tests that others can understand it, or make an onboarding/mentoring plan for team mates, or estimate based on a teammate doing the work.
In this position: the engineering manager should remove the fake Senior from the team, that will force them to get up to speed.
The management graciously allocated all the time that the senior needed for all this documentation and onboard plan, then everyone in the company clapped
Orgs: okay you are indistinguishable cogs and we will treat you as cattle
Devs: no wait not like that
Truth is everyone knows that who or which teams takes a task matters immensely. We know that if Bob leads it’s gonna suck and if Alice does it’s gonna rock and finish on time.
Managers know this also.
But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.
The corporate culture serves a very specific purpose of lowering the self-esteem of the 10x folks, keeping them at their place doing 10x work at 1x salary until they burn out. This is scalable, predictable, and serves management's interests well.
It's just if you happen to be a 10x guy, for the sake of your own sanity, learn how to run a business and get out of the corporate swamp. Nothing else will bring you happiness, believe me.
People often forget that the 10x guy is 10x only in the domain he’s been working on, and many chores has been taken away from him by his manager and given to someone else. It is fairly easy to make a 10x someone closer to a 1x just by changing his tasks and giving more chores like CR, bug fixes, more mundane features or GUI etc. Sure it will often be better quality but in areas where it matters less.
Jeff Dean was 10x when he wrote EPI INFO, he was 10x when he worked on profilers at DEC WRL, he was 10x when he and Sanjay Ghemawat wrote MapReduce, and he was 10x when they rewrote Google's search indexer. Maybe 1000x or 10000x, really. It's true that part of that was that he worked on things that mattered instead of things that didn't, and he could have found himself in a situation where he didn't have that opportunity. But it's clearly not just productivity in a single domain, and it's not because someone else was fixing all his bugs.
There are statistical outliers in every single thing that has a big enough amount of samples and that it is possible for there to be statistical outliers.
Maybe you attract those like flies are attracted to honey, but pointing out that an Einstein existed isn't really helpful for approximately all teams of physicists out there, minus one or two teams
I'm not even saying there isn't a huge quality variance in the regular pool of programmers, mind you. Just that pointing out the existence of bad motherfuckers in a population of a few million people shouldn't come as a surprise.
The average person is about 2 meters tall, weighs about 100 kg, can run about 10 kilometers per hour, lives about 70 years, and can shovel about 60 tons of coal in a day (without power tools). If you took a sample of a few million people, it should very definitely come as a surprise to find that it included "10x" people: people who were 20 meters tall, people who weighed 1000 kg, people who could run 100 kilometers per hour, people who lived 700 years, or people who could shovel 600 tons of coal a day.
It should come as even more of a surprise to find "Jeff Dean" people who were 2 kilometers tall, or who weighed 100 tonnes, or who could run 10,000 km per hour, or who lived 70,000 years, or who could shovel 60,000 tonnes of coal in a day.
Your comments about how physicists do physics are equally wrongheaded. Physics isn't any more a matter of shoveling coal than programming is, probably less so.
What made you think I think physics or programming is analogue to easily quantifiable manual labour?
>It should come as even more of a surprise to find "Jeff Dean"
To find them, yes. To point out that they exist and the likely that you'll work with them is statistically insignificant? No.
The thing with intellectual labour is that some insights have immeasurable value. Some statistical outliers have such humongous intellectual capabilities that it's ridiculous how often they'll have great insights.
Of course, that won't stop people from trying to attach some numbers to it, even if their numbers are epistemologically shit.
I'd wager that has something to do with jumping the shark.
People feel the need to chat about 10x developers when they don't even agree what a 1x developer is, and when they do present a definition, that definition is a function of (company, team, project, existing code base) which means there are more possible instances of 1x developers than the amount of developers who have ever lived.
Everyone is better off if they just ditch the "10x" which has connotations that programming nerds will latch on to and just use "highly performant dudes".
No, in the studies in Sackman, Erikson, and Grant's 01968 paper (10.1145/362851.362858), which is the origin of the 10x-developer idea, there were only 12 and 9 programmers, respectively. In both studies the standard deviations were comparable to the means. That means 10x developers were a substantial part of the population, and the rest of the population also has very high variance; it isn't just a question of a few outliers.
Jeff Dean is probably legitimately an outlier, though.
This is just a redressing of the same “everyone is just as good” bullshit. Some people get a fuckload more work done because they go down the right design paths to start with, know how to work effectively, know what pieces to skip, etc.
The same is true in nearly every field. Programming is not special.
I deliberately used “closer to 1x”, but let me respond with an anecdote.
I know several people, each working in a different org, who explicitly manage their managers by demanding to work on issues that have good visibility, are not too short >2 weeks but not too long <2-3 months so they are ready before the next review period. This way they are seen from the outside as very good performers while someone else is doing the less appreciated (but still essential) work.
Sure they are, I'm arguing that their force multiplier has to be taken with the context they are in, and that the change of the context can reduce the multiplier.
I think people also don't realize that high-performers weren't always high-performers. They had to hone their skills, usually by doing years of the right kind of challenging work with modest rewards, and sometimes they can be formed by exceptional mentoring.
But however they got there it took time, it's something that can be cultivated as long as folks aren't treated as fungible.
I disagree, the few really high-performers that I have worked with were high-performers already from the first week with a new technology, from the first month in their first job, and already as a student during practical work they were more productive than most people who had many years of challenging work behind them.
Experience is important and adds up, honing the skills makes everyone better, but it's orthogonal to this issue; there are people that will very quickly outperform someone who has honed their skills for years, and once they have honed their skills in that domain they might perhaps start outperforming them by the mythical 10x ratio.
I guess it depends on how one defines 10x or "high performer". Prodigies and maestro's will always be few and far in-between, is that what is meant by 10x? I don't know. But given the relative abundance of 10x'ers anecdotes in discussions in places like HN, I always just take that term to mean "really good" or perhaps just fuzzy romanticizing-- and not literally able to do the work of 10x "mortals".
Well, he became 10x in the domain, and the other did not become 10x, it's not like he was born with this knowledge, he just took it more seriously and went deeper
No, some people are a lot more productive across broad range of tasks. Often they are assigned tougher/critical stuff though because it doesn't make sense them do trivial tweaks.
Ensuring people work on what they are comparatively best at is a feature. 1x engineers would also get a lot less done if they had to clean the toilets and sweep the floor and many of the other low end tasks others do, instead they assign people who cost less to those tasks.
That’s argumentum ad absurdum though. There may well be people that are useless in a given profession, my point was not about that. My point was that 10x occurrence should be analysed within specific project, work division within the team, etc. For most 10x programmers in a project it does not guarantee repetition of 10x on a different type of project or problems. Matching problem with a team member and ensuring he has a chance to become 10x at it is something that good managers do.
Isn't it insane that there are many 10x engineers who have created enormous amount value (creating patents, leading and executing projects, innovating etc.); Yet, the world will only know about the company or the CEO and never the engineers behind it.
How do you expect the world to know about the others? The CEO is public facing by definition of their duties and the charter. Any other public presense from the organization technically falls under marketing of some sort, even teaching useful generic skills for free (say a publisher promoting literacy in third world nations) is in service of this.
It requires looking into arcane details to know about the engineers behind it. I mean software, especially media productions often include outright credits but few would remember any but leads usually. Precise attribution would get downright absurd in a pure data sense to give coverage that few care about. Say for just a simple who tightened the screw on this part of the cloth mill during its production run, who made the screw, who farmed the cotton, made the irrigation means....
Replicability and productivity atr what leads to technical obscurity ironically - because the automation and scale means fewer people are even in the position to know what to even ask about the details relative to the numbers served. Thus the knowledge remains arcane. Not many people would even know say, that DRAM tries to minimize capacitance and inductance but it needs some of both to function. Let alone who was involved with what subsection of the chip design and design testing process.
The trick is to be a 10x dev and work 0.2x of the time, remotely of course. Everyone thinks you're decent and you get a full salary working 3hrs per day.
Not only are there 10x engineers, I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it).
The measurement happened as a result of a joint venture between Siemens AG and Ericsson called Ellemtel. Each company sent 250 [edit: not 500] engineers. It was a six month project, the classic death march: if it did not deliver on time, the parent companies would not be paid.
At the end of the project, half the code delivered was his. Had he not been on the project, it would not have been completed on time, so no product would have been delivered. [Edit: Thus, it is not really the line count that makes him a 500x engineer.]
> I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it).
So your 500X engineer knows a 5000X engineer and he wrote as much code as 999 other engineers combined? (That would make him a 999X engineer, FWIW)
A 500X engineer (per your measurements) would have to write 500 lines of code every day without fail, while all 500 other engineers in the entire company could only average 1 line of code per day. And the 5000X engineer they know would have to write 5000 lines of code per day while everyone else was only limited to 1 line of code per day.
Not just one day, but every single day for six straight months. And all of their managers would have to somehow not notice this disastrous situation for the duration of the project. Come on.
What were you trying to say? You realize a Boeing 747 weighs over 400,000 lbs. And a tiny Cessna 172 weighs ~1500 lbs.
If the planes have the same wingspan, it's likely they're in the same class, and weight is a perfectly reasonable measurement of completion percentage.
A 450-gram partly completed airplane probably has a wingspan of about 1 to 3 meters. If you have a partly completed plane whose wingspan is of about 1 to 3 meters, and it weighs 450 kg, it will never fly. You need to redesign it. Otherwise you have a rocket, not a plane (and there's no guarantee that it's a working rocket).
Maybe, in exceptional cases like the Gossamer Condor, a 450-gram partly completed plane might have a larger wingspan, like 30 meters. With enough thrust and wingspan, you can definitely get a plane weighing 450 kg to fly (or even one weighing much more, like your Boeing 747 example). But if your Gossamer Condor competitor is partly completed and weighs 450 kg, again, you are going to have to redesign it, because a bicyclist will not provide enough thrust to keep it airborne.
If your Boeing 747 assembly is running behind schedule, you probably cannot catch up by adding more ballast to the wings, or prioritizing ballast over riveting, even though lead or DU weights are quick to install, and rivets do not weigh very much. X-ray inspection doesn't add any weight to the airplane at all, but it's the only way to find certain cracks. If your Boeing 747 weighs 500 tonnes, that does not mean that it's a super-complete plane. It won't be able to take off.
So, no, weight is not a perfectly reasonable measurement of aircraft completion percentage.
sure, because they are measuring progress towards completion, rather then the ability to fly
i.e. if a finished plane weights 10,000 lbs all put together, then a in-construction plane currently at 1000 lbs is clearly further along towards completion then one at 1 lbs
Note this applies to the manufacturing,not the design.
It is actually a wonderful analogy with software:
* to a first order, cost of the materials in an airplane are proportional to the weight
* at design time, the weight of the aircraft is minimized. thus, political and management forces cannot change it.
just like software, each subsection that is bolted on has different weights; but if you average it out it is a good measure of progress. and cost.
It's a nice aphorism, but it's a very bad analogy. Before the build of an aircraft is started, the target weight of the assembled product is (roughly) known. Therefore, in the process of building an aircraft, the assembled weight at least goes up from 0 to $target -- in an erratic fashion, but it's still a continuous measurement.
I have never seen a program design specification that even attempted to quantify the lines of code of the end product, let alone be accurate.
The initial comment was related to attribution for "who built" some piece of software based on lines of code. The analogous argument would then be assigning attribution for the built aircraft to whoever produced the heaviest components. Given that that would be illogical, I think the analogy is apt.
The person who told me about this was the person who counted up the code at the end of the project. And, yes, it was 250 from each, not 500 from each parent company. (Memory is funny that way.)
I do not doubt that the numbers were rounded for simplicity. It is meaningless to talk about a 499x engineer.
As was explained to me, this engineer assigned two-week work units. If the work was not ready at the end of two weeks, he wrote it himself over the weekend. So, a fair bit of code was written that did not make it into the final product.
That's a ridiculously wasteful way of managing work. I too can be a 10000000x engineer if I never let others actually merge their code and just write it myself instead.
If you hired engineers like they hired them before coding interviews combined with a decade of the dead sea effect I can easily see a team of 500 barely getting anything done at all. Big organizations are often grossly mismanaged like this which is why smaller organizations can beat them.
mismanaged, yes. But also risk-adverse and encumbered with process. At a big corp you may need 5 or more sign offs on a single merge. I probably spend a good 40% of my time herding cats and babysitting the merge pipeline. There is a lot of overhead you simply won't find in a startup.
It was a way that delivered product on deadline, for exactly that project. Every project has specific needs. If you code to some other project's needs, you do the wrong thing.
For any positive real number X and employed engineer A with positive productivity, I can find an employed engineer B where productivity of A is more than X times the productivity of B.
Proof: Pick B to be an engineer with productivity 0. 0 * X = 0 for all X. Productivity of A is defined to be positive, so is greater than 0. Hence productivity of A is greater than X times the productivity of B.
And, not all projects are death marches. It is generally hard to measure value, which is one of Dan Luu's points. Counting lines of code rarely produces a very good answer, but sometimes that is the best you have. Company revenue can be meaningful. When a contribution that makes the difference between $X million revenue and $0, against 250 years worth of engineers' salaries, it is hard to quibble. 500x is as good a number as you can get.
The multipliers are all relative and seldom in simple metrics such as lines of code.
If you wanted to inflate the numbers in a technically truthful way stick in a complete novice capable of preparing (so they are not negative) but not prepared for a complex field so their multiplier will be low. Use them as your 1X and even burnt out and demotivated employees who don't stand out could wind up performing 50x relative to them.
You don't measure code by the number of lines written, you measure it by amount of productive value. Early engineers at Google were easily 500x ( keep adding more zeros if you want ) more valuable to google than a random swe today
LoC is a terrible metric - did they count the lines other engineers removed?
I was half of a very productive duo on a greenfield project subsystem - a project I joined midway: my partner wrote a lot of code, I estimate ~70% of final lines in the code base were his. What the LoC count won't tell you is all the refactoring, deletion, tests and error handling code I had to add, because his code only worked for the happy path. Can you say he was being 2x more productive than I was? I say no, because he was breaking the nightly build at least once a week before I joined, blocking the rest of the team, this ended when I added pre-commit tests.
When the numbers are large enough, the details don't matter much. Maybe he is really only a 250x engineer? A 100x engineer? It doesn't change the fact that without him no product would have been delivered.
> It doesn't change the fact that without him no product would have been delivered.
I agree. I'm only arguing that there are times when engineers who enable "10x/100x" engineering don't get the visibility they deserve, sometimes until after they quit.
This hits close to home for me as I witnessed my partner being showered with praise for being "super productive" based on LoC alone, code which wasn't close to being production-ready. If you don't care about code quality, and want to be seen by management/people outside of your team as a 10x engineer with minimal effort: you can follow the same playbook.
Agreed. It is rare that you can get objectively meaningful numbers. So, while it is convenient that half the code delivered was his, that is not the meaningful measure.
When I was in school, the standard for engineer productivity was 10 lines of tested code per day, averaged. Maybe we do better today, with fewer footguns and faster compilers. But we expect more meaningful results from a line of code, too.
This really isn't my experience with super productive engineers. Usually they're solving high level technical problems for the company that most employees wouldn't touch with a ten foot pole. It isn't the raw LOC they produce but their ability to translate complex technical problems into elegant solutions for everyone else to take advantage of.
I'm not saying it doesn't exist. I did say 'maybe' after all.
I am also implying the likelihood of it being that, rather than from a particular perspective an organizational detriment looks like a personal positive (somewhat akin to the 'heroic' team constantly responding to pages in production for their services; not like that lazy team that only works 8 hours a day and never gets paged), seems low. As mentioned, when one person seems to be doing all the work, yeah, it might be they're just amazing, or it might be that the project is badly managed, and so the work can't actually be distributed well. Both can also be true.
I too have seen -10x engineers. Interestingly, others in the company also saw them as +10x. Someone who was the silo for a notoriously difficult part of the system was viewed by management as amazing (after all, he just went and got things done! They could focus their attention elsewhere!). When I then had to dig in, with actual production requirements, I found nothing really worked, nothing was designed well, nothing was documented, and the person was impossible to work with.
Assuming you can objectively measure someone like this, either by LoC or delivery times, this is the wrong way to approach any project.
Having a 10x engineer(or even worse, a 500x engineer in this alleged case) is a huge risk for the company, should the engineer want to leave or if they are incapacitated in a tragic event, the company is severely handicapped, ideally a so-called 500x engineer should spend less time writing the actual code and instead mentoring/managing others to scale up their knowledge, should the company do this right, they might not deliver on time, but they'll have a much wider array of experts when something breaks or for the next projects, reduces overall company risk and it's more profitable in the long run.
Yet, they in fact delivered and got paid, and (pay attention!) would not have delivered and not got paid, otherwise. Risk is speculation about the future. Here we have full benefit of hindsight, and the choice taken was manifestly correct, despite all counterfactual speculation.
It’s incredibly reductionist to think that productivity is inherent to an individual when the world is never that simple and there are always a lot of factors involved in any outcome. Even the people that you think are “10xers” will stumble under the right circumstances, and the converse is also true about the people you think are incompetent.
It’s not so much that we built a culture that disallows these things to be said—I’m sure you have the freedom to say that to people if you’re prepared for the consequences. It’s just that it’s such a hasty, unnuanced thing to say, and business decisions should not be made on the basis of rash remarks that aren’t very well thought-out.
I remember finding a site (a design patterns repository page of all things) that explained the nuance of different people having different expected outcomes on different domains well.
But despite searching for it for years I haven't been able to find it again - web searches tend to be bad at finding things that you found before, again.
Anyway, this was described as the "movie producer pattern" (maybe it was director)
I remember it going something like this:
As opposed to the factory worker pattern which describes people who perform simple tasks that are straightforward and are easy to learn and perform and are hence interchangeable, it is more accurate to use the movie producer pattern.
A producer will have shown his or her abilities in a specific set of movies, each with a certain style and genre, which will lend credence to their ability to perform similar work in a similar genres. It's clear however that the specific director will make a large impact to the final movie and will have a personal touch.
For engineers, Susan, who has spent the last decade honing her skills on language VM implementations is expected to be an all around star resource, but would probably be a more trustworthy choice for more VM work as opposed to implementing a graphics engine or database.
(In analogy to a director with a string of science fiction movies who might not be the best choice for a romantic comedy)
> It’s not so much that we built a culture that disallows these things to be said—I’m sure you have the freedom to say that to people if you’re prepared for the consequences.
When people say that "you aren't allowed to say" something, they don't mean the government uses magical mind control rays to prevent your mouth from physically producing the words. "Consequences" are the mechanism by which speech is prohibited in societies without access to magical mind control rays.
(Not to pick on you specifically; I've heard this line a lot lately.)
I mean, I get your point about the government but now you’re just complaining about how being insensitive to other people has the consequence of them fighting back.
Now you’re moving to assume that everything that has consequences is due to somebody being insensitive. It could also be, for example, that the person initiating consequences is entirely too sensitive.
So you’re gonna go around the office to point fingers and tell on people that they’re not 10xers, and then call them too sensitive if they react? You’re talking in abstracts but if you put what you said in context (ie this discussion) it doesn’t make sense.
This discussion is not about me, nor did anyone advocate that behavior. You are making up scenarios in your mind about what other people in this thread are thinking and saying, but these things are all imaginary on your part.
> Even the people that you think are “10xers” will stumble under the right circumstances, and the converse is also true about the people you think are incompetent.
Right, the 10x engineer isn't benching 10x more than you or running 10x faster than you, nobody thinks that 10x engineer means 10x at every possible task.
Nah, it's beyond that. I know a dev that is the most brilliant ux dev I've ever met. He can create beautiful, dynamic, understandable UIs literally 20x than I can.
However, he is just medeicore at must other tasks- constructing a common data model, scaling the backend or analyzing the data be is slower than I am, if he engages at all.
More recently I told my manager that I was intimated by how effective one of my coworkers was at his job (data science and BI.) He laughed and said my coworker basically thought the same of me (doing more standard software engineering.
Highly effective engineers are often only effective at limited aspects of the business of software engineering and it takes a good team structure of diverse talents to make everyone effective, even in the domain of software.
That was my point, arguments such as yours are just arguing with strawmen. 10x is compared to another professional in the same domain. Saying that the engineer isn't as effective at another domain as a professional of that other domain is arguing with a strawman.
It's not really a strawman considering it's EXACTLY what most companies are trying to do: make programmers fungible across domains. Critically; they're doing this because they typically have no visibility into these skillsets from the managerial level, and they typically only have one or two programmers "in a given domain" on a team - even in a very, very large company. The company would like to pretend these people are fungible, and can be interchangeably swapped out, but the reality is they have no immediately replacements on the team.
There's no sense in doing an apples-to-apples comparison when you've only got one apple, an orange, and a pear.
But then you have to ask what metrics are being used to define a 10x engineer. You’ll see that everyone has a different version of that and therefore whether a 10x engineer exists solely depends on the ontological argument for a 10x engineer. By the end of the day 10x is subjective because teams have different needs.
If you can replace an entire team of 10 engineers paid to work on something with a single engineer then that engineer is a 10x engineer, as long as the "10x engineer" didn't originally write the things they work with. That is my definition.
> By the end of the day 10x is subjective because teams have different needs.
Replacing 10 salaries with 1 salary isn't subjective at all.
Of course it is subjective. This is literally what you said:
> That is my definition.
You obviously care about optimizing for salary expenses. Most companies have room to hire more people who can do a few things well, so their definition of 10x would be different because they’ll have different expectations of their employees.
And really, if your definition of a 10xer is some poor fool who’s willing to take the job of 10 people for a single person’s salary, good luck finding someone who wants to spend their lives living that way.
> And really, if your definition of a 10xer is some poor fool who’s willing to take the job of 10 people for a single person’s salary, good luck finding someone who wants to spend their lives living that way.
Right, they are paid more. The going rate for good people is around 1.5x up to 10x for exceptional cases.
Edit: And I am not talking about minimizing cost of salaries, I am talking about how much a good software engineer should demand. If he can replace 10 salaries with one then he has a lot of leverage he should use to get a higher salary, if the company isn't paying him then he should leave for a company that appreciates his skills. Plenty of companies pays premium money for premium talent.
I mean, if all you’re saying is that “better programmers deserve better pay”, then you’re not exactly saying anything groundbreaking and the concept of “10xer” is not going to be necessary to make that point. It should also be noted that the salary that you get isn’t just a product of your talent but also of how well you sell yourself. Amongst many other factors, of course.
Salary isn't just a factor of skill, but willingness to pay high salaries is the same as belief that skill matters a lot. A manager who doesn't believe in high developer skill variation will not pay significantly above market rate, while a manager with strong beliefs in skill variation will pay huge amounts for the right people. Therefore I see any arguments against 10x developers as an attempt to supress wages, likely managers who wants to hire good developers without paying them more than average developers, or developers who are jealous of others salaries. Luckily a lot of companies acknowledges that talent matters a lot and pays a lot for it, and today the highest valued companies in the world belongs to that group.
There are some specific individual engineers who will get a specific individual task, faster than some other specific engineers.
If those same specific engineers get done many general tasks faster than another group of specific engineers on general tasks than they are just better in general. If some other specific task gets done by the other specific engineers better then it is just different domains.
Exactly. Not every task or goal fits every person equally well. A good leader understands this and does their best to find that fit.
But it is in my experience not considered okay to talk about this too openly because people get offended.
You wouldn’t ask your best engineer to lead a marketing campaign or your best marketer to design your servers. They’re smart and would figure something out eventually, but who gets the task matters.
The irony here is that the point of the article isn’t that “10x engineers” do/don’t exist, it’s that “things are more complicated than that”.
Assigning arbitrary labels (like 10x engineers…) so it’s “easy to understand” results in over simplified models that lead to faulty decision making based on invalid assumptions.
…treating everyone equal is perhaps also a faulty assumption, but it’s easy, and dealing with complex systems is hard.
Maybe instead of bitching about equality, which is just a symptom, we should promote using complex models instead of easy trivial ones.
…because just using different easy trivial modes is stupid; it won’t get you any better outcomes.
I like being treated like a cog instead of playing pretend-games of making me feel like a unique flower (but truth is still that I’m a cog). I prefer honesty. I prefer the brutal, unvarnished reality over executive bullshit.
A cog means I have specific responsibility and I will make sure I don't hog down the entire machine. I work well with other cogs - we mesh perfectly. Being treated like a daisy with beautiful narrative of lies would eventually lead to a delusional state of mind, dissent and ultimately negative spiraling burnout.
But one of you really is a daisy, people are not equal, and those daisies are actually what's responsible for most of this machine and it's origins in the first place. Without daisies there will be no place for cogs, the cogs come after the daisies
Even if there aren’t 10x engineers, there are still engineers with different levels of skill and knowledge in different areas.
One of the best engineers I ever worked with was terminated (he was a contractor) as he spent his career on the backend, was told he would work on the backend, and they assigned a complicated React feature to him over his objections that he had no knowledge of the framework or frontend dev in general.
HR didn't care that the person made the company more money than HR saves by doing location adjustments for all international employees combined because HR at the company had no notion of the value of an employee, only the cost, title, level, and location
This is common in large, dumb corporations: HR is the Blob. And if you are being recruited by a company that exemplifies that kind of culture, run away, far, far away.
A 10x'er is by definition an outlier. It would be absolutely silly for a business to build its planning on the existence of outliers in its staff, unless the company is small (< 20) and that individual is a co-founder or someone you can really rely on.
People leave companies for other opportunities even when they like their current job. I have to plan for that, whether it hurts someone's ego or not.
Isn't the "10x" label contingent on engineers being functionally indistinguishably, except some are allegedly 10x more productive? Specialization is what I figure has highest impact on turnaround times in a team setting. Just because an engineer is the most familiar with a component/subsystem - which allows them to make changes to that subsystem faster, doesn't make them an all round 10x engineer.
IMHO it's also an useful illustration that being able to replace people is asymmetric.
It may be that Bob can do Joe's specialization at half speed, but it's plausible that Joe can't do Bob's specialization properly at all, even after a year of training; so replaceability only works one way.
And I have worked with engineers that could do improvements to an unfamiliar component/subsystem faster than the current engineer who is the most familiar with it; i.e. their time of learning+adaptation+implementation was faster than the other persons' implementation alone. And it's not that the other engineer was incompetent, they were quite reasonable.
It refers to people with the same experience with the system. For example, lets say you have two persons working with a system and have worked with it for two years. One of them is 10x as productive in that system than the other. Neither of them had experience with such systems prior to this, so both were equally productive when they started, but one of them grew much faster and is now 10x the other.
Of course if you took those two and put them to work at a new system both would have 0 productivity initially as they learn the new system, but as they grow the differences starts to appear and soon you have a very stark contrast again.
I'm "10x" when working on one part of the system that I'm extremely familiar with but "1x" when it comes to other areas. Similarly, I have teammates who are "10x" in those other areas but wouldn't know where to start when it comes to my specialty.
> But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.
Do you really think that was the motivation? That someone is going to bat for Bob at Alice's expense?
Or do you think it more likely that "equality" is another way of saying both Bob and Alice will never threaten someone in management enough to cost them even a minute of sleep on any given night, and that's all management really cares about at the end of the day.
> But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas.
This is pretty much exactly true. Though I must say being a person who comes in and get plonked on the underperforming team. It'd be really progressive if the Alice character had to take on some fresh blood to share around the knowledge and let new people build rep. Nothing sucks more than being on an underperforming team.
It may be a culture thing, but across the three companies I've worked at every estimate has been explicitly assuming a specific person handles it. Sometimes we've even given several estimates for the same task depending on who it gets assigned to. No one has ever found this odd. It's just obvious that different people have different skills and familiarity with different technologies or parts of the project.
There's no need to be offended either. I will gladly estimate a task taking longer for me to do when I'm not the original author or would be using languages and frameworks I don't have much experience in. We just give the estimates and let the PO prioritize what they want.
This is how planning should be done. Gauge people's expertise, put them on the path they can be most effective and then ask for their estimates. Take that to upper management and negotiate.
One problem with that is sometimes the estimates are done long before the work starts so when that item eventually gets to the top of the priority stack the person estimated for is working on something else instead. At this point things need to be re-estimated which can cause friction if the new estimate is longer (“but last time, you said…” or “when we asked Bob, he said…”).
What I've done in the past is give an estimate based on what a “standard” dev can be expected to do (everyone understands a junior is expected to be slower as they are new, that is why they are currently a junior and when they get up to speed they'll be promoted) with a comment on the ticket that the expected time will reduce by × if a named resource, or one of a group, is available to work on it. That way, medium term planning can be done on the basis of a “reasonable case” scenario and if the right people are available things will go better (and if there are multiple items in that state, short term planning will include deciding which ones being sped up, by using that person's time, confers most extra value).
Right, things are always probabilistic when it comes to us Humans :-)
I like to think of it like Algorithm Analysis; Best-Case (estimate by the expert mentioned above), Worst-Case (estimate by Noob who just joined the project) and Avg-Case (estimate by person who is already part of the project but is not responsible for that module). Add a fudge factor based on your reading of the circumstances and then haggle with Management. You now have a band with a upper bound and lower bound which can be realistic.
PS: You may find Douglas Hubbard's How to Measure Anything: Finding the Value of Intangibles in Business useful in this regard.
> But, but ... isn't every estimate supposed to be provisional?
Heh, no. It is an estimate when you are making it, but ten minutes later it magically becomes a commitment.
"Tasks like this usually take two days, sometimes one or three, very rarely more... so, two days on average."
"Okay, I am writing down: two days."
...two weeks later...
"How it is possible that the task took three days when it was estimated at two? You made the estimate! And you all were there at the planning, and no one said anything! As senior developers, you should make better estimates, this is unprofessional."
In an ideal world, yes, especially if requirements/scope/environments change. But the world is often not ideal. Often unless there is what they see as good reason (the definition of good may vary widely), managers & business planners don't like estimates going up in the short/medium term and pressure to try stick to the original estimate may happen.
That's exactly what I was thinking of when I said we sometimes give estimates depending on who it gets assigned to. "It'll take a day if X does it, but probably three if another SE does it".
The best teams I've ever worked with, that were the most productive and also had the best team work and team spirit, was when we assigned tasks in planning. And gave the tasks to whoever was most suitable to work on it.
Unfortunately we were never allowed to do that, because of Scrum, and were only able to do it on the low down for a short time until management cracked down on it and enforced "anyone who happens to be free works on whatever is on top of the backlog".
> Unfortunately we were never allowed to do that, because of Scrum, and were only able to do it on the low down for a short time until management cracked down on it and enforced "anyone who happens to be free works on whatever is on top of the backlog".
Ironically, this (what the management did) is completely against the rules of Scrum... in theory.
But it is what management typically does when they are doing "Scrum".
I "enforced" this as a manager at my last position. But I quoted the word "enforced" because this wasn't something I had to argue with anyone.
I understood that it meant things might take a little longer, but it also meant that everyone on the team (which was small) would get exposed to all of the code we worked on. Specialization means speed, but it also means a lower bus factor.
I got around this, specially around 'planning poker' when I got to be lead in these scenarios that forced you to do it. Whenever there is a discussing on how long something should take, whoever says the least amount, is tasked with the job. After 1-2 of these meetings, amazingly, all estimates started to come back quite higher than before.
I still believe that whoever takes the task, should be the one deciding how long it will take, and only after understanding the scope of the work. Planning poker is the most useless piece of shit I ever seen, and still, it is used all around by idiots. If I am asked to estimate something, I will always give the highest possible value and justify with "I don't know enough about it to estimate". If I am managing and I have a top down force pushing for this, I will always make sure that the stupid process is obvious how fucking broken it is.
The original idea was that "planning poker" should estimate the tasks in "story points", which are absolutely NOT supposed to correspond to days. It is just a way of saying "it seems like the task X will require twice as much work as task Y". Some teams do not use numbers at all, and estimate stories in "t-shirt sizes": S, M, L, XL, XXL.
But of course, most companies want to have their Scrum and micromanage it too. So they estimate in days, and call them "story points". Or sometimes they don't even bother to pretend, and estimate directly in days.
(So, how can you estimate how much gets done during the sprint, when all you have is the "story points"? You keep the records from previous sprints, and see how many "story points" got done back then. Adjust the number if someone takes a vacation, etc. This is self-correcting in long term: if someone starts pushing developers to estimate low story points, you will see that fewer story points get done per sprint, so your estimates of how much work gets done will remain correct.)
In my experience it still makes sense to estimate together using the same story points (or T-shirts) when there are people ranging from almost no experience to very senior ones working on a project.
1 SP for a senior may take 1h of his time and for a junior that would be 2-3 days but it's still 1 SP - a relatively simple task. This is in contrast to a fallacy of recalculating SPs to time-based units cause if we do that we might as well just estimate in hours/days.
It's about agreeing on some baseline first (what does 1, 2, 5 SP task look like?) and going on from that. We just need to remember that velocity will be different for different people so team capacity calculation is going to be all over the place but I think this approach can be useful.
Whenever I ask an expert how long it'll take someone new to the their code base to add feature Y, I mentally double whatever estimate they give and share _that_ instead.
I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?”
Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done.
One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan. Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve.
So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.
> So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.
TFA doesn't suggest hiring 500x engineers, it suggests taking steps to retain highly effective engineers (and highly effective teams) by not ignoring the evidence that they are not fungible.
A point the article also alludes to: often people are only “unicorns” due to the specific context they’re working on. Move them to a different project, and your high value person may be a net negative. And it’s not possible for people who aren’t familiar with a person’s work to anticipate how making that person switch projects will affect the quality or quantity of their output.
"Tell me what date task X will occur on." -- where task 'X' takes 5 minutes, but has a long list of pre-requisites that take 1-4 weeks each, sequentially, of which 100% our out of our control.
...
That's not planning, that's fortune-telling. You may as well ask an Ouija board.
Planning is making sure the the pre-requisites happen before you attempt to start the things that depend on them. It is making sure that everyone is unblocked. It is making sure that nobody is wasting time going down a dead end. It is making sure that everyone is rowing in the same direction.
What I see from PMs is that they just want facts from the future, instead of solving problems in the here and now.
Until today, weeks into the project, I could not access the system that I needed. This was the key pre-requisite for 4x FTEs progressing on their own tasks.
The only thing the PM did is repeatedly ask me if he needed to move the date for the completion ETA.
I solved the problem. He did nothing to expedite progress.
Does it really matter which specific date this occurred on? No. It just had to happen as soon as possible. The trick is to make it possible, not to try to pin down exactly when "soon" will occur by repeatedly asking the same question in every daily stand up.
Like the parent poster said, people are on a bell curve. It sounds like you may only have been exposed to mediocre, passable, or plain bad PM's so far in your career.
So I'll remind you: the reason we pay PM's is because good PM's can, and do, exist. I've only worked with a few great PM's, but they outshone their competition with just as much brilliance as the 10x among us engineers outshine the 1x. It's ironic that you would reduce PM's to a single heterogeneous caricature in reply to an article that is essentially saying that it's harmful to do so.
That was the glory of the good ole Gannt Chart in what I might call Microsoft Project Based Project Management.
If you set your dependencies right, the dates would just slip by themselves, and it was easy to tell the bosses what slipped. Required a lot of printing and taping every week, and caused a ton of headache whenever people lied about their progress, and didn’t really work without a FTE project manager, but I have yet to see a supposedly better system actually work better on big projects.
>One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan
"Plans" can never be set in stone. They evolve based on the people involved and circumstances. A Manager's job is to understand his people and then Plan accordingly; not the other way around.
>If all you can do is complain
This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unaddressed, will most probably result in failure of what is attempted.
Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.
* In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organised according to the specialisation of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.
* Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.
* In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A[citation needed], their standards for working with software development contractors, which stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing.
The "Waterfall" is what is imagined as a "Ideal and Rational" process (see D.L.Parnas' paper A Rational Design Process: How and Why to Fake it for motivation - https://ieeexplore.ieee.org/document/6312940). The stages in the model and the issues to be considered in each stage are what is important NOT their order. In practice it was always a iterative spiral model described by Barry Boehm - https://en.wikipedia.org/wiki/Spiral_model
TIL: "Winston W. Royce's final model, his intended improvement upon his initial "waterfall model", illustrated that feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable / undesignable requirements)"
Interesting because that's definitely not what's taught in the handful of Software Engineering books I've read, and steps backward are not canon (rather, they're called something besides Waterfall i.e Spiral or Iterative).
Looking at that page again, it looks like what I describe is called "pure waterfall".
Instead of getting lost in the comments, You should post it to HN and invite discussions with a title like "Most of what you have heard about the Waterfall Development Model is Wrong!" or "How the Agile folks have misled you about the Waterfall Development Model" :-)
Most books on Software Engineering are mere compendiums with nothing much to recommend them eg. the texts by Sommerville or Pressman. Two exceptions that i know of are those by Ghezzi,Jazayeri,Mandrioli and Pankaj Jalote.
The first formal detailed diagram of the process later known as the "waterfall model" is often cited as a 1970 article by Winston W. Royce. However he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach.
Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.
There is a big difference between the stages involved in "Waterfall Model" and the various techniques of combining, using and transitioning from one stage to another.
"Waterfall" specifies the What while "Spiral and Iterative" specify the How.
i would say, everyone acts in their interests, at all times, except for individual actors who may value things like the city the work in or loyalty in themselves that may artificially tie them to a situation. i say, if you identify a problem with your organization that you can’t get over, be a grown up, and find another job. seriously, it’s the best thing you can do for yourself. if you feel an organization is rotten, leave. you will never ever fix the rot. if you’ve got bad hr you’ve unfortunately got bad hr, and that’s not your fault, but that also will never, ever, change.
This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. Each project is different. Each team is unique. Every individual performs differently, even one day to the next. Stop looking for this tool to make these plans. It can't exist.
>This mentality of thinking is exactly the problem
Damn right!
>We are telling you that no such tool can exist to do what you want
This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords.
The core of the solution lies with the Individual; understand their needs, wants, motivations, practice "Empathetic Management" and you will be successful.
Leaders may need to know some specific dates for some specific purposes. Responding to that need by demanding your methodology deliver a schedule for everything in case you need it is lazy and wasteful.
If your engineers are part of the same team, working on the same business goals, they'll be glad to contribute what you need to the decision about whether to announce at conference Y, and may even be able to suggest relevant aspects you haven't thought of.
I would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.
I'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?
I worked for several years on an extremely large and popular sports news/results website, meaning all our deadlines were absolutely set in stone by the outside world – sporting events start on specific dates. The Tour de France sure as hell ain't gonna postpone a few days until we've finished our team profile pages.
So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch).
I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.
You can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.
“Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot.
Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha!
Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?”
Stop using methodologies actively preventing any kind of planning (mostly agile stuff). Return to waterfall, write lots of documentations, spend time planning architecture, resist urges to rewrite non-ideal solutions. Do not allow changes.
It'll take more time and result will not be as clean.
Basically learn from older engineering disciplines.
The two replies below yours at the moment capture what you're trying to say...
> This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake.
> This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords.
Which is another way to say... if there was a system to do their thing, they wouldn't have to pay smarter people a lot of money to do it. Reliance on a system (any system) tells you that the people don't value your expertise, but rather see you as a cost to be minimized.
Also, build several prototypes of every important part of the product in order to learn how long they will take to be made and how each variant will perform, so when you make estimations they are as effective as possible; and then, make integration tests on the selected variants so you can reduce estimation risks due to integration. Just as in every other engineering discipline.
I can't really speak about managment here, but when I organize projects the three most important things are:
1. Create the room for every member of the team to comfortably do their job (what this means depends on the persons needs and at the work environment, communication structure, tools you provide them). Room not only means physical room, but also time, frame of mind etc. If everybody has 10 other daily things on their list they won't have the (mental) room to work on the project.
2. Communicate clearly why you think this is a workable plan and ask for feedback whether this is realistic. Communicate what happens if you are faster, what happens if you are slower. They are helping you, you are helping them, ideally both sides take away something from the project beyond purely finishing it.
3. Adapt, Improvise, Overcome. The primary goal should always be to finish the project in a good way, especially if the deadline is not a hard deadline, but one arbitrarily set by someone else. Defend the team, create the room for them. Don't let them slack around too much. A bit of slacking around is not too much, but precisely the right amount – this is the space needed if something goes terribly wrong.
A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could build reasonable error bars around every engineer's estimations, and then sum the estimates _with the confidence intervals_ together and figure out the probability of achieving a certain ship date.
> A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer.
To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates.
A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.
That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.
I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team.
(edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)
Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed.
I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.
I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.
> But if you have a practical idea on how to “solve” planning
Seems pretty straightforward to me - just don't use dates in your plans. That means don't announce features which aren't complete. Don't plan marketing campaigns for unlaunched products. Embrace "Now, "Next" and "Later" as headings on your roadmap. There are many successful companies that operate like this, Nintendo being a famous example. It doesn't seem to hurt their bottom line - quite the contrary.
The usual issue that folks have with planning is that business leaders are simply not willing to spend the resources to do it accurately enough to answer the questions they're asking. Think how much time it would take to break 6 months of work for several teams into detailed stories and estimate each one.
It therefore seems they're basically wasting everyone's time, since dartboards and magic-8-balls are just as good as engineering estimates without details.
> So show me a methodology that mere mortals can implement successfully.
There's an impedance between "Bob can do task of type A really quickly" and "we need to make sure that people other than Bob can do the task or else we have bus factor = 1 and this poses systemic risk". Clearly these goals are not really in conflict. In general, assign the work to Bob, but understand the effect on timeline in case Bob is unavailable. How long would it take if Bob isn't available? Is it worth the inefficiency from cross-training Mike? Is Mike even interested?
Modern militaries are not majority staffed by combat soldiers. Less than 10%. The rest are support of one kind or another. Smart engineering leadership in large companies, if they care about shipping on-time, eventually realize that roles like PMs are less effective if they understand themselves to be bosses and more effective if they understand themselves to be support staff.
> One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan.
Yep, just as I thought. This is why those teams hated plans - because once there is plan they will be beaten and abused to make it, despite the plan being unrealistic from the start.
> Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done.
In that case, teams in which you worked had stupid methodology about planning. It sounds like your plans did not accounted for uncertainty at all. They did not accounted for what if we are not making it, which features will be cut.
> Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve.
And many of them are abusive or exploitative about it and there is nothing in business organization to prevent or at least acknowledge that.
I'd imagine the corollary to this is assigning each of them the task you think they're most suited to. I think that's what used to be called "management".
I'm speaking as someone who has handled a fair share of timelines (with reasonable success) you have pointed out.
To begin with, it is interesting to see you lumping up different kinds of timelines. For example, the cost of not meeting SEC timeline different one compared to demo to be shown in a press conference.
> should we spend $50k announcing at conference Y in month Z, or should we wait until month A?
What is it that you want to announce? Product launch perhaps? Then let's work with the product folks to design it and then take it to engineers to figure out work estimate. Give them time to estimate; if the timelines don't match then reduce the scope.
> Our competition just launched; will we be able to launch this quarter
Sure, they launched this quarter. Do you know how long have they been working on it? If not then it's a similar exercise as above.
> we have to report material financial impact items quarterly or face SEC fines
Why are you telling me this? SEC doesn't ask for such reports overnight. You messed up by not telling us so fine it is. OR there is some human at the SEC with whom you negotiate.
> So show me a methodology that mere mortals can implement successfully.
If there were such a methodology we wouldn't be having this discussion to begin with. It would have been commoditised, similar to a car manufacturing assembly line.
What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. If you want to disrupt a domain then you either develop expertise in it or hire them from the industry.
> If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it.
In some cases that is indeed the reality. If you don't even want to acknowledge the reality then good luck hiring good people. If you say point out how Apple launches products like clockwork then I'll point out how they have had close to 50 years worth of experience and all the associated optimisations they have done with their supply chain and what not.
Reality is, whether you acknowledge or not, is full of detail[1]. It can't be bent to your convenience, unfortunately.
> What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history.
That's not quite true: the inventions of mathematics, writing and especially affordable material to write on were probably even larger culture shifts, but software and computers are of the same magnitude - perhaps it's easier to realize the shift needed in corporate culture when you compare it to those earlier changes.
This is cathartic to read, but I also despair at getting the people who need to hear it to take it seriously.
> But many people want the world to be simple
This is the source of so much insanity in the world, not just with regard to allocating labor. Details matter, but people who plan "timelines" desperately don't want to hear it. They can go through whole careers without being forced out of the cozy illusion that the world is simple. It's hard to get a man to believe something when his salary depends on it not being true, the market can stay irrational longer than you can stay solvent, etc.
Knowing what needs to be done is insufficient in programming too. You need to do careful archeology on the code base as well. Yes that code base you work on every day.
Weirdly I find "legibility" a little ... reductionist.
It's super-easy to identify the problems with e.g. Stalinism or modern China along these lines. The problem is that humanity is constantly failing in far more chaotic ways too, and what a surprise those are more associated with anarchist capitalism or imperialism, but since they don't reduce to a nice formula you get this somewhat smug analysis of human behavior. Where is the "legibility" problem of the US invasion of Vietnam for instance? There is none because the interests (contain China, destabilize the region) were quite clear, and were achieved, despite the US "losing" the war.
(I'm also really sick of the "Gervais Principle" blather so that may be biasing me against the ribbonfarm blog though)
One thing that I always think is undervalued is how variable a single persons output is. A bad day, illness, life changes, etc all dramatically impact a person’s efficiency.
Treating even the same persons output as abstract is fraught with issues. One month a rockstar the next a schlub.
Some of the most capable people I've ever worked with have been "bursty" in that they would go through intense periods of high value output and then need to almost go dormant for a while to reset. As long as the "high value" phase was uniquely and significantly valuable it wasn't a problem so long as management understood and planned their assignments appropriately.
I'd like to think I'm capable, but whatever I am, it's certainly bursty with periods of dormancy. To the other comment, it's probably on the bipoloar spectrum. Some of it is self-inflicted. Most of it isn't.
Before covid, I'd had 2 managers who knew something of what I was dealing with and gave me the space to deal with it and encouragement that my work was good enough often enough not to worry. With some 5+ other managers, I believe I successfully masked it and that it would have threatened my job had I failed.
In the remote world, it takes almost no work at all to manage around my work schedule. I don't even feel like I'm masking anything, just living. Weirdest part is I've now fallen into a far more social role.
Who would have thought remote work had such hidden benefits?
congratulations on finding a comfortable way to work that works for you, allows you to be productive, as well as more socially fulfilled. as someone currently attempting to find a nice niche for myself as well, much respect.
I'm like this. Not just in a commercial context, but also at home with pet projects. I go through phases of being extremely creative with things I come up with, for about 2 or 3 days, then I go back to normal for about 30 to 60 days before I get to that state again. Luckily I've been able to notice this behavioural quirk so I try to code/write as much as possible down to use as building block to use on my "boring" days, but sometimes it feels like I cannot remember doing it or it was a different person doing it, kinda baffling to be honest.
During the bursty periods, it affects both my creativity and the amount of work I output. I haven't found a way to trigger/force myself into this state yet. I've tried different sleeping patterns, food, sex, drugs & caffeine, different kinds of music etc, to no effect. Music has come the closest to getting me to that feeling/state.
I was just about to say that sounds very adhd like (I’m diagnosed as well). Have you tried adhd medication? Not sure if that was inferred by your comment on drugs.
Thank you. Everyone has up days and down days. Some of them can even be kind of extreme like not wanting to get out of bed. Variation is normal, we are not robots.
I am bipolar and this is completely wrong. People have variable output. Motivation comes and goes. Live circumstances change. People burn out.
These are not bipolar. The name "bipolar" is very misleading. One book I've read has called with multipolar disorder, which is far more accurate. There isn't just mania or depression. There is a whole world of possible dysfunctions that come with it: Anxiety, ADHD, insomnia, psychosis, and the list continues. There can be different moods, stages, and flavors of mania and depression in one person!
On top of this, these symptoms need to be severe enough to impair normal daily function to be diagnosed.
Motivation is a big one for me. Some tasks (or projects) just don't motivate me at all, and they turn into a dreadful slog. Others are captivating and I have a hard time logging out at the end of the day. I think there's easily a more than 10x difference in my own performance between those. Could be closer to 100x.
Completely agree, and reminds me of how much I hate the common Agile terminology of "sprints".
Sprints are an extraordinary effort and are by definition not sustainable. If you run a sprint, you have to recover for at least as long before returning to baseline.
I know it's just a word and doesn't literally mean to sprint, but I feel like it still subtly infects how development is viewed and approached. Even replacing it with something like "iterations" still implies that every 2-3 week period is cookie-cutter and predictable.
"Who can run at the top of their ability? Right. A short distance runner. You can’t run far at that speed. We programmers have figured out how to fix that, though. We just fire the start pistol every hundred yards and call it a new sprint!"
This right here is what everybody needs to factor into their planning. For some reason management doesn't seem to understand this. IMO this is one of the main reasons for
failure.
As an example; i was once complimented (backhanded?) as "you are brilliant but moody" :-) It really made me realize the variation in my productivity which others had picked up on.
Another example; in one project there was a real smart and knowledgeable programmer who had taken up a lot on his own shoulders. I was skeptical on whether he would be able to deliver on it and had tried to raise it diplomatically with management. Of course they didn't understand the human ramifications; result? A week before the deliverable, the guy cracked under the pressure and did not show up to work for the next two weeks. IMO, Management was squarely to blame for this since they did not understand the psyche of the people involved.
Realizing this is important for retention. It's damaging when upper management falsely thinks people are interchangeble, which is a common view among non-technical types and HR. This leads to 10x people feeling underappreciated and resentful, ultimately causing them to resign for higher compensation and more appreciation elsewhere. It can literally destroy small companies if an individual's unique contribution isn't properly understood and valued.
Managers should err away from language about "the group", "the team" or "collective" and really drill down to the level of individuals as much as is practical. This is the correct resolution for most decision making. "The team" is just an abstraction that's useful to a small extent for a certain class of decision making, but not beyond that.
What I've experienced at companies on a death spiral is that there are a few people everyone can agree are useless, and beyond that you start picking people based on your poor understanding of how the sausage is actually made.
Once someone really useful has been let go, you have the sudden realization that your situation isn't that different than theirs. If management can misunderstand Tim's value, they sure as hell can misunderstand yours. At which point everyone's productivity is compromised by existential dread, and the wheels just start coming off faster.
A senior at FAANG is worth sometimes well north of 500K/yr. There are plenty of folks strewn about small software companies that do similar work to a senior or even staff/principal at a faang at wildly huge discounts.
It's hard to find numbers for the value of small software businesses (OP's quote), but this article [1] puts the number at $667k. If that's true, the engineer is SUBSTANTIALLY more expensive than the business (you're not just renting the business for a year).
[1] In the period between 2013 and 2016, the average sale was $667,000. While some sales were obviously much higher, and some were actually a bit lower, this must be an encouraging figure for a business owner to see.
> A senior at FAANG is worth sometimes well north of 500K/yr. There are plenty of folks strewn about small software companies that do similar work to a senior or even staff/principal at a faang at wildly huge discounts.
Those discounts are why it's easier to poach the employees.
If a company has 10 engineers earning $200K/year, why would you buy the company for $667K per person and then pay the employees on top of that?
Just offer the employees $500K/year and they'll stream right over.
And when acquiring an existing company, the buyer is typically interested in keeping a lot of the engineering staff. I've only seen a few acquisitions where there was no interest in keeping the engineering staff (North comes to mind; this one was strictly for Google to get its hands on the patent the company had acquired from Intel).
There are only so many $500k spots available. If every engineer in the world said “I’m moving to SF and applying to Google” and assuming visa allowed that you’d see Google paying a lot less for talent! Which means that while some people earning 200k are underpaid, they can’t all be underpaid.
Big Tech and most established companies make billions in profits off software products developed by engineers. Engineering Software Products is a highly specialized skill and absolutely isn’t compensated to the same degree as its impact; Silicon Valley was the first to realize and reward this somewhat adequately (IMO still not enough).
It’s really great for management types that they’ve managed to restrict the median compensation at fairly low levels; this is also the case for software outside of the well known tech hubs.
This might be true, and I agree SWE should always push for getting a decent slice of the pie. However how much of the 'value' is establishing a monopoly in some area of tech, rather than the tech itself. The mysterious "good will" or "intangible assets" of the brand value, institutional knowledge, having the right software and hardware in one place etc.
There is only one Google, but there are plenty of bright people who are capable of learning SWE.
If all the little tech companies were making $1m revenue per SWE too, then yes you'd probably see tech wages raise in line with that.
However those little tech companies haven't solved traction and growth yet (if they are aiming to at all), so they can't compete with SV and stay profitable. They don't have $100M in funding to throw into salaries.
Or from another angle - a individual SWE starting their own mini SaaS makes $2k a month. They are happy for this as a start, but on the other hand they are extremely underpaid!
An analogy - shouldn't Amazon warehouse workers be on double what they are paid, as without them Amazon can't ship anything!
At the extreme, workers getting the full value of what they are putting in would be something different to a corp, more like a co-op.
Amazon warehouses is not a good example. Amazon can and does build warehouses where it can get cheap labor. Whereas most Big Tech firms are based in high CoL cities. Why? High skilled labor has much better leverage due to being in short supply.
I do agree with the point that many of these firms are operating under monopoly conditions. However, for them to be continue to be monopolies requires them to either hire or acquire the best talent that’s possible. The monopoly cannot run itself, and that’s the leverage that software professionals aren’t utilizing fully yet.
The larger worry for petite capitalists is not competition with large tech, but rather the possibility that senior engineers at small firms realize that they are the firm and have enough savings to jump ship, build an mvp, and cannibalize the old business.
Salary is per year, buying a company is a one time cost. Retention agreements are a part of the purchase so they know the employees they got will be forced to stick around if the purchase goes through.
The author is conflating two different things here. At large enough scale, almost everyone in a given role is practically interchangeable but there are some people who very much aren't. It's a hard leadership problem to both solve for making 99% of the staff function at a consistently high level while still carving out the exceptions for the 1% that really can move the needle at the company scale.
At a the level of a single team, nobody is interchangeable, but both reducing specialization and creating a "we're all in this together" spirit are both important goals for long term team performance (and so people can go on vacation).
Both of those problems have different solutions but can feel pretty similar when you're at the receiving end.
I think the worst of all cognitive biases which humans suffer from is the belief that observations about collectives can be usefully applied to individuals. How much faulty thinking, from racism and sexism onwards, stems from this simple category error?
strong disagree. there exist truths on a population level. oxycontin addicts traverse similar behavioral patterns, for example. for the worst of all cognitive biases i would say confirmation bias.
I don't think the person you replied to was claiming otherwise. The problem is when one takes those population-level truths and blindly applies them to individuals. You might be right 80% of the time (or whatever) with that approach, but that doesn't help when you're wrong _this_ time with the specific person in front of you.
> observations about collectives can be usefully applied to individuals.
> You might be right 80% of the time
or, as in my example of a collective of oxycontin users, you might be able to predict certain of their actions at a 99% efficiency rate, and that may enable you to make statements that apply to the collective as a whole, and as individuals.
Yep, you're exhibiting precisely that kind of bias. I've known a variety of addicts and there's absolutely no statement one could make about them with 99% certainty that it will apply to a given individual.
I don't mean that one should be naive about things. You might correctly observe that a high percentage of Oxycontin addicts exhibit behaviour X, and therefor you might want to keep a wary eye out for that behaviour when dealing with an individual Oxycontin addict. Of course that way lies confirmation bias, which one must also guard against. But it's still better than saying that because most Oxy addicts exhibit trait X, this individual addict will necessarily exhibit trait X. That's worse than confirmation bias becuause it's pre-confirmation bias. You're treating statistics about a group as evidence about an individual -- and that's wrong.
> I don't mean that one should be naive about things.
i think that’s the literal disagreement we are having
> I've known a variety of addicts
how bout they try to get more oxy by any means necessary? i think i’m safe. i also think that some people really like to believe the line you’re selling, but that’s all it is. want and belief. some call it faith. whatever you want to call it, it’s wrong.
i have to say though, i do appreciate the well thought out, reasoned and mannerly post. you are very good at arguing your position, so, even though we ultimately disagree, much respect
One thing missing is that author is assuming that talented people will like to work in one place indefinitely.
With developers skipping boat every ~2 years on average how do you make sure you will keep such person in-house.
You can compensate people only up to some level but as they got bored or feel they can do something better with their time they will move. Not to mention family reasons or whatever else can happen in persons life. You can have talented dev today - next day he might be hit by a truck, if you run your business by relying on people you will be affected by such accidents, if you run your business as if everyone is interchangeable you won't. Even if they are not easily replaceable.
That "corporations are doing it wrong" premise is also wrong - somehow those big corporations are chugging along for decades. Of course they leave "lucky ticket" profits on the table, but that "lucky ticket" has risk of loss - which is missing from the text.
Yes with small focused team you can achieve great ROI in one off project but those are not projects that are done by big corporations. Then you have all the startups that usually fail.
Then leave alone "my friend's team was composed of people who had a track record of being highly effective across a variety of contexts" - seems like author does not understand how hard it is to find such people and assemble a team especially if you are BigCorp. That friend just got lucky to be in specific time and place and their experience. Especially if you read that they just wanted to hire another scapegoat - so it is just survivor-ship bias.
In my view skipping boat every ~2 years on average is the result of a bad situation. Maybe people feel they have to do that to increase their comp or advance in their career, but I'd much rather stay in one place for 5-10 years growing it and growing with it.
I'd also wager that a good workplace that provides autonomy, fair compensation, strong peers and a good atmosphere will not see 2-year average attrition.
Developers wouldn’t skip a boat every 2 years if they were happy. Instead of accepting that as a fact to be worked around try to understand why your developers are leaving after a 2 year tenure.
I’ve worked at a few companies, all of them have had highly skilled senior engineers with long tenures. The “2 year tenure” is a self fulfilling prophecy that management types love as a way to treat engineers poorly (why bother? They’re gonna leave anyways!).
> if you run your business by relying on people you will be affected by such accidents, if you run your business as if everyone is interchangeable you won't. Even if they are not easily replaceable.
This right here is the problem and a fundamental error.
It is a recipe for guaranteed disaster because you have completely ignored all the knowledge, experience and expertise which one has gathered over a period of time. Unless and until the task is trivial and/or very well defined with all constraints, assumptions and risks clarified people are not interchangeable.
Paraphrasing Isaac Asimov: [Knowledge Work] does not mean my Ignorance is just as good as your Knowledge.
> That "corporations are doing it wrong" premise is also wrong - somehow those big corporations are chugging along for decades.
Once you have market dominance it is really hard to lose it, you have more resources and more experience than any startup. So they can carry a lot of bad practices without failing as a company, they have to be really bad to lose their position.
This is actually a common business question, how can big well funded companies ever fall? Well, things like this is how they fall. Any one of these things wont be enough, but it all ads up.
There is a lot of corporations that are far from market dominance. There is more to the world than Fortune 100. Some companies chug along with ~500 employees for multiple years with a lot of rotation.
Granny: “There’s no greys, only white that’s got grubby. I’m surprised you don’t know that. And sin, young man, is when you treat people as things. Including yourself. That’s what sin is.”
Mightily Oats: “It’s a lot more complicated than that—”
Granny: “No. It ain’t. When people say things are a lot more complicated than that, they mean they’re getting worried that they won’t like the truth. People as things, that’s where it starts.”
Mightily Oats: “Oh, I’m sure there are worse crimes—”
Granny: “But they start with thinking about people as things.”
Another way of saying this is "Don't use process to overcome people problems". I've seen a lot of dysfunction because the org chooses to put a heavy process in place because 1 or 2 people made obviously bad decisions. It then punishes everyone for the acts of a few, and usually is done because the org isn't healthy enough to give those people feedback or let them go.
the head of HR thought that the company's ~5% attrition was "unhealthy" because it was too low and in another, HR thought that the company's attrition sitting at a bit under 10% was too low
Can someone explain to me why fewer people quitting is seen as an unhealthy metric?
Retaining employees seems like something companies should want to try to prioritize above all else, especially in this market.
The argument essentially is that it hints to there being an exploitable slack in the system.
If you treat bargaining with employees as a zero-sum game (which it really isn't, but some companies do treat it that way) then the other party being very satisfied with the bargain indicates that they would be also willing to get a worse offer. So if all the employees are extremely satisfied with the compensation/effort ratio, that indicates that you could either lower the compensation some or extract more effort until they're satisfied "just barely enough".
It implies that the company isn't pushing their employees hard enough.
In otherwords, if managers are doing their job "correctly" they should either (1) be pushing their staff so hard that 1 in 10 of them quit every year (2) weening out the the poorest performer.
Peopleware calls this the Spanish Theory of Management[0].
Historians long ago formed an abstraction about different theories of value: The Spanish Theory, for one, held that only a fixed amount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people’s backs. Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold money chasing too few usable goods).
The Spanish Theory of Value is alive and well among managers everywhere. You see that whenever they talk about productivity. Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.
It's the same kind of bullshit as teams being penalized for meeting 100% of their goals because it means that their goals weren't aggressive enough. I can't say whether the strategy is effective or not, but MBA types seem to love it.
mbas see whatever they see for whatever reasons they do. it’s usually posturing and signaling to other mba types, often with delusions of grandeur and napoleon complex, not height based.
Depends how good your hiring is. At the places I've worked, I'd want to see 0.1 (involuntary) attrition at least, given that mishires happened 1 in 10 to 1 in 5 times. A low attrition rate in the context of lots of mishires means we're not firing people quickly enough.
While I agree that one shouldn't keep mishires around I wonder how you established that the rate of mishires is 10-20%. Seems like a bit of a chicken and egg problem. You don't know the actual rate if managers aren't firing the mishires. If you pressure managers into randomly firing 10-20% of their people you can't calculate the rate. In fact 50% of one team might be mishires while another is 100% made up of great engineers.
I knew the rate because I was on the ground working with the underperformers. But as to how to translate this into HR policy in a large org, I have no idea.
Maybe it was the environment, that a lot of these people could be better if supported the right way? Or to say it simply (and please understand I know nothing about you so it is not meant as a criticism of how you personally work), maybe it was because they worked with you?
I would also say that throwing x% and hiring again does not work well. The pool you are hiring from is people that are not happy somewhere else. You are not getting a 90% chance of finding a "good" person.
I would venture that you really can't if you want to be accurate and fair.
You were on the ground, which to me implies that you had a local view of the rate. In your area the observed rate of mishires apparently was around 10-20%. If you were in another team/part of the org you might have thought 50% or 0%.
My guess is that HR does exactly this sort of thing. Someone did a study once and averaged numbers that were obtained 'somehow' and that is then simply applied.
Like stack ranking. Everything is a normal distribution, right?
If you ask me: What large orgs are not good at is doing what actually makes sense. It's too much work and there is so much that could go wrong anyway. The way out are blanket policies implemented by drones, bean counters, the odd psychopath etc.
I observed the local rate, correct. I didn't really make a claim that a large org would be exactly the same as my local rate, so I agree with you that it could differ. But honestly, I do believe it would be over 0.1 for most orgs, just based on my experience with people in college and other areas of life. Competence at a high level is really rare and most people just are really not good at complicated tasks, even many graduates from top schools.
I definitely would agree that a lot of people in large orgs are unfortunately like that. I can corroborate that from having been in many of those. I can also attest to the fact that most managers don't deal with this. There is a lot of moving people around or simply ignoring the problem.
Now like my earlier sibling mentions, just because someone isn't a top performer at their current job at the current time doesn't mean they can't be great in another area or can learn. I have (and had) a bunch of people on my teams that were/are not senior people but they have a smart brain on their shoulders, are inquisitive and learn. Sure they don't know our stack fully, they don't have the exact same opinion on how to write code etc. but they are able to learn and adjust and maybe teach us where our customs aren't the best as well. And we teach them too.
I'm speaking of practices like at large banks where people have been hiding doing nothing but being on Facebook all day for 10 years and all that has happened is that every project manager tries to avoid getting these people assigned to their projects.
I'm an introvert, I love working from home, I live in the woods with a 1/3rd mile long driveway. Since my youngest went off to college I'm here alone with her fish and a cat. I go into town once or twice a week for supplies and the rest of the time I'm just out here in my little sanctuary enjoying the lack of people.
That said, even I know that while individuals matter, teams matter more. And I don't see anything in this entire post about how to build a team or sustain a team or inspire them to support each other. Absolutely nothing about how you can develop skill and aptitude in junior folks or redirect conflict or conveying the importance of actually shipping something vs running marathons on the tech debt treadmill.
You know all the shit that has to happen in the real world to keep people happy and invested. All I see is an ode to the 10x'er and how sucking up to them might keep them around long enough to be successful.
I love HN and the community overall but there are few things more predictable than this story making it from new to the front page lol.
No, they're not - at least if teams have some base level of autonomy. A team could choose to grow itself along the dimensions in https://danluu.com/culture/ without the company even knowing.
> All I see is an ode to the 10x'er and how sucking up to them might keep them around long enough to be successful.
Don't get me wrong: I enjoy Dan Luu's writings and I'm thankful that he shares his thoughts.
That said, a lot of his recent writings present extremely rare, specialized situations like small teams of carefully-selected 10X-er type programmers who are hand-picked from their sterling reputations and naturally extremely motivated. If you find yourself in a top 1% unicorn team like that, a lot of his writings ring true. Trying to apply arbitrary big-company management to highly-optimized, high-performing teams like that is a mistake.
However, statistically most of us won't be working on or managing those unicorn teams. Trying to apply top-1% advice to the median team is going to result in a lot of mismatches.
Generally speaking, HN isn't a great place to get any sort of management advice. The userbase is mostly IC engineers, and as a result the upvotes tend to follow what IC engineers want to hear. Writing an article about making the difficult management choices that come with managing real-world (not top-1%) teams is hard to do without upsetting a lot of readers, so instead we get a lot of "engineers good, managers bad" type articles even if the authors start out with best intentions.
I didn't get that feel out of this at all. Sure, there was mention of a few individuals who were "10x-ers", but I read it as appreciating each individual for what they can bring to the team and to the org, which is always different for each person.
The point is that people are not fungible. Some people have specialized skills, while others have a broad breadth of skills. They won't both be good at completing the same tasks, so you can't reorg to put them in positions that don't make use of their strengths and expect success.
The bit about budgets was really eye-opening. Reducing things to "headcount" instead of figuring out what kind of people you need for a team or project is a great way to fail. If you just say "hey, you can hire three level-2 people", but believe that hiring two level-3 people (assuming at your org that the total cost for both of those is the same) will be more successful, and get told you can't do that, that is a failure of the organization.
I agree. I think there is a strange trend of fetishicization of individual contributor capacity in tech world, some sort of hero syndrome. Even a lot of posts about 'culture' and 'organization' end up being about how at the end of the day these affect individual performance not how well the organization performs overall. Maybe we can all take lessons from playing in a team sport - it's true that the team will do poorly if each individual contributors perform poorly on their own for whatever reason but what wins the game is not about how well everyone played on their own.
"Individuals matter" does not mean that teams do not.
The "individuals matter" is contrasted with "individuals do not matter" and not with "teams matter".
If you think about this it is exactly pro-team. It means that the team is built from the people that compose the team and people are sometimes intimately linked together through the circumstances in which the team was built and cannot be easily replaced. The team building is path dependent and that path cannot be easily replicated.
Most effective people are not only because they are magical 10x people, but also because they have the right experience and knowledge in the situation. Skills and knowledge the company might have given them over years.
I think there are ways of reading this without ever thinking some people are 10x super humans while the rest are not.
i’ve had one for years. the way you start is, when you meet an asshole, write their name and company and job title down, and a short, less than 20 words, statement describing the assholery. keep doing that for a few years and watch as patterns start to emerge.
I think the article also applies to teams - in particular, how not to destroy teams by ignoring the individuality of the team members, and indeed of the team itself.
Each individual grouping of humans is unique in its social dynamics, relationships, culture, expertise, etc and so will be uniquely effective or ineffective at identifying and achieving desired outcomes.
I tend to enjoy the topics that Dan Luu discusses, but his "wall o' text" presentation can be somewhat intimidating. It's better on a computer, than on an iPad.
He's absolutely correct. I'm not sure that anyone in the industry (that can do something about it) cares, though.
Nothing will change, until C-suite pocketbooks start getting impacted. As long as people are willing to pay for the type of software generated by organizations that treat ICs as "LEGO blocks," then it will continue.
For myself, I care -deeply- about the Quality of my work. I. Simply. Cannot. Bring. Myself. To. Write. Crap.
Since no one is interested in paying me to do it, I write for free. I'm very fortunate that I am able to do this.
The reason being, is that I have made it a point to try to keep my [public] criticism to my own work.
I tend to hold myself to a fairly high bar. I'm quite aware that the level of Quality that I expect from myself is usually considered "commercially infeasible."
I'm OK with that. It's never been about the money, for me.
You are more than welcome to look at my [highly accessible] public portfolio, to see what kind of work I do. Check out my HN profile. I am not anonymous.
> The roadmap creation and review process maintains the polite fiction that people are interchangeable, but everyone knows this isn't true and teams that are effective and want to ship on time can't play along when the rubber hits the road even if they play along with the managers, directors, and VPs, who create roadmaps as if people can be generically abstracted over.
Agreed, and this breaks down when there's a large deviation from the mean for any particular team member, where the mean isn't necessarily some sort of "average", but more like what the rest of the organization has become used to in terms of productivity from that team/department.
But if the "polite fiction" enforcement resists this reality, it comes out in all sort of undesirable ways. It's... not nice.
We are interchangeable - everyone is. The president of the United States is interchangeable. The CEO is interchangeable. Is this really that difficult to accept?
I think attrition can be low as long as your team is steadily growing. No attrition can lead to no new people, and no new people is often the bigger problem.
A stable team becomes an echo chamber and/or rant fest. Certain arguments have already been won, right or wrong, and others can never be won.
New people come in and ask dumb questions that upset the status quo. They often are the only people who can.
> A similar thing happens with retention. A great engineer I know who was regularly creating $x0M/yr4 of additional profit for the company per year wanted to move to Portugal, so the company cut the person's cash comp by a factor of four, causing them to leave for a company that doesn't have location-based pay. This was escalated up to the director level, but that wasn't sufficient to override HR, so they left. HR didn't care that the person made the company more money than HR saves by doing location adjustments for all international employees combined because HR at the company had no notion of the value of an employee, only the cost, title, level, and location5 <
This is overall a brilliant post by Dan (as usual) but in this case he is harsh on HR; there is also a cultural cost on breaking salary structure for exceptional individual contributors - everyone else gets upset and threatens to leave. HR needs to calculate this, which is more likely the motivator rather than saving a few dollars here and there on a single individuals salary.
Individuals matter, but in exaggerating the point, he has neglected to consider teams / groups matter also.
OP touches upon a critical point of human reasoning: we have a bias towards simplicity.
We favor the legible (as the article calls it), the tractable, the countable, the fungible. At certain levels of complexity, seeing reality as it is is just impossible. This complexity can be in terms of the subject itself, or the organizational/communication overhead required to tackle that subject.
This bias towards simplicity is more often optimal than not. As he noted, the variance in performance becomes unbearably huge as you try to get more precise.
The thing is that it's easy to pick out where simple models are wrong. The more complex the subject, the more edge cases there are, the fatter the tails are, etc. But it's harder to replace those models with new ones that increase precision while retaining sufficient efficiency. So just as simple models account for the cost of an employee without accounting for their value; he critiques those models for their precision without accounting for their efficiency. It's not as easy to predict/calculate value as it is to calculate cost.
So while he's right in saying "these models are wrong", people won't be persuaded until they hear "these models are better". And "figure out the optimal solution in every individual context" is not a better model, not given the complexity of our work and the limited resources we have.
Anyone taking the message here as "managers are idiots", are also oversimplifying things. They feel the moral high ground of being right, and it can be helpful to highlight where our models are wrong. But we also need to replace them with better ones, which is much harder than critiquing the best usable-but-imprecise ones we have.
A team where you have to ask who is going to do the work is one where people can’t get help when they are in trouble. It shouldn’t matter who gets assigned to it first, if they can’t do it, someone with more experience will step in.
This is what those stand up meetings were supposed to be for. It’s not supposed to be a meaningless ritual. If people can’t get help, or are afraid to ask for help, something is wrong.
An experienced person will likely take half the time of an inexperienced person who gets help.
If the inexperienced person pesters the experienced one much that it doesnt take more time, that would imply that the experienced people aren't (on paper) getting much done, because they are too busy teaching to do much else.
The actual balance of course depends on the experience gap between the assignee and assigned work, but the notion that any two people on a team will always get the same work done in the same amount of time is silly.
This is also why I really love working with software, because it's one of the greatest force multipliers on the potential impact of an average individual I can think of.
We don't have to be once-in-a-decade level genius visionaries or hire a gigantic team with millions in funding to build something that can make the lives of millions of people tangibly better, while capturing some/most of that value in return to improve our own lives. People from all over the world are doing this every day and telling their stories and sharing their learnings on places like https://www.indiehackers.com/ and https://bootstrappers.com/.
Maybe one day we'll reach a point of diminishing returns where all software that can possibly be built by an individual/small team that adds non-trivial value has already been built, but that's just more motivation for me to try harder today while it's still very much possible.
If you want a great book on the subject of management legibility and what is lost when it is imposed, read Seeing Like a State. One of the most eye opening books about the world I’ve ever read.
> A similar thing happens with retention. A great engineer I know who was regularly creating $x0M/yr4 of additional profit for the company per year wanted to move to Portugal, so the company cut the person's cash comp by a factor of four, causing them to leave for a company that doesn't have location-based pay. This was escalated up to the director level, but that wasn't sufficient to override HR, so they left. HR didn't care that the person made the company more money than HR saves by doing location adjustments for all international employees combined because HR at the company had no notion of the value of an employee, only the cost, title, level, and location5.
I laughed because I've been on the other end of these conversations (poaching a talented engineer going remote). I guess I have some random HR department to thank!
Sales rep: "Boxes are nothing to do with computer performance"
Luu: "I understand. Still, please humour me?"
Rep: "But there are sneering people on HN who think you think you're better than them. Somehow this should be important to you"
Luu: "Anyway, moving on, I want to buy a computer"
Rep: "No. Not until you explain."
Luu: "Fine, I want to ship it to my mom in Alaska and want to minimise shipping cost."
Rep: "Ah! Gotcha! Apple will ship it for you, to anywhere"
Luu: "I don't want to use your shipping, I need to customise it first"
Rep: "Ah! Gotcha! iCloud sync will transfer her data when she signs in"
Luu: "I can't use that, I want to install custom new things"
Rep: "Smallness often comes at a cost premium. You might find that a bigger computer has a little extra shipping, but overall comes out cheaper"
Luu: "I'm paying for the computer, but my mom is paying for the shipping. It's more important for me to minimise shipping cost than computer cost"
Rep: "If you're going to pay part of a more expensive computer cost, why can't you pay part of a more expensive shipping cost?"
Luu: "When my mom sees the shipping price on the parcel, she will send me that amount of money, she can't afford it, and I don't want to argue with her about it."
Rep: "She can't afford shipping but you're not paying for it? You're not paying for food or rent?"
Luu: "What I am and am not paying my mom for is irrelevant. She doesn't want to live off me, but will accept a gift, but also wants to pay her way when she can, and I want to respect her wishes. This is the agreement we came to."
Rep: "You don't want to have a small discussion with your mom to save money? She won't change the agreement to save you money?"
Luu: "I won't let her change the agreement to save me money, if it makes her feel like she didn't contribute and then she feels bad using the gift"
Rep: "Luu, I..."
Luu: "This could go on literally forever. The people on HN are internet people who thrive on cynicism. There is no resolution to this which will satisfy them, nor is that a goal I am trying to meet. This is not what I came here to discuss. Will you please help me find the computer with the smallest box in exchange for money, for reasons which I am perfectly happy to agree are irrelevant and irrational, but nevertheless am sticking with?"
> People, as a whole, cannot be treated as an abstraction where the actions company leadership takes impacts everyone in the same way. The people who are most effective will be disproportionately likely to leave if you turn a knob that leads to increased attrition.
Damn correct.
An observation of mine is that a company may recognize the most valuable employees in informal ways. For example, they may have some peer recognition awards that the same employees get because their peers know how valuable they are, but due to other constraints (ex, politics) they may not hold a title/level that represents this. When the company turns the nob, as Dan says, these most valuable people are the first to leave. Management is mostly oblivious, but the other engineers know.
the last paragraph made me realise, i indirectly owe my current, amazing job to that. i was on a team at work which was fine, i wasn't hyped about it or anything but my boss was good and i had found an interesting subarea of the product to work on. then i got taken off it and moved to another product that absolutely did not motivate me in any way. stuck it out for a couple of quarters, finally talked to my boss about being put back on the old product. he talked to his boss, who said no way, we need people working on the new product. that finally gave me the kick in the pants to apply to change teams to work on something i was really enthusiastic about, and i've been here ever since.
My takeaway is that danluu is saying that, at the small scale, people understand how individuals contribute to teams. But at the large scale (like the HR department) we don't.
At the small scale, we're able to apply systems thinking - a team can be viewed as a system composed of a set of interacting parts.
However at larger scales, systems thinking becomes unwieldy - the interactions increase quadratically. There, we fall back to the Law of Large Numbers [1].
"Fungibility" and the related failures arise as a result of this.
The law of large number works well for some things (say, shoe sizes) and fails to work for others (e.g. income distributions, which follow a power-law).
So it's not odd at all that it would fail to adequately account for people. It's just sad we don't have anything better. Can't we find something better?
This conversation makes me wonder: has there been any halfway decent quantitative research on estimation methods?
I've lived through what seems like the de facto agile standard: you take some piece of work, and estimate it out according to a point scale, assuming the "average" dev does the work.
Curious to know now if it has any effect on project timeliness. Or are these estimates generally "vanity metrics" in practice?
Anecdotally, they are generally pretty useless for planning unless they are at a very fine grained level, with low complexity, on an extremely well-understood piece of software.
I suppose the opposite of all this is Guns’n’Roses taking ten years to record Chinese Democracy because Axl Rose wanted to hire a pro skateboarder to do mixing and stuff like that.
>Some people seem to view companies like a game of SimCity, where if you want more money, you can turn a knob, increase taxes, and get more money, uniformly impacting the city. But companies are not a game of SimCity. If you want more attrition and turn a knob that cranks that up, you don't get additional attrition that's sampled uniformly at random. People, as a whole, cannot be treated as an abstraction where the actions company leadership takes impacts everyone in the same way. The people who are most effective will be disproportionately likely to leave if you turn a knob that leads to increased attrition.
This gem applies to so many fields. It's bonkers that this has to be spelled out to people who are ostensibly experts. This is why you never, ever take anyone seriously who thinks of society like a model.
> This is why you never, ever take anyone seriously who thinks of society like a model.
I’ve never understood these critiques. If you want to study society, what’s the alternative? No matter what, you have to make a model of some kind. Yeah, some models are simplistic, but maybe they can capture the high order bits of the phenomenon they are modeling, and at least you are committing to an idea you can codify, find fault with, and improve. The alternative (never making models) seems to be a type of intellectual nihilism.
Every model is simplistic, otherwise it's not a model, but reality. Societal models (I've never heard of a remotely reasonable one, aside from psychohistory) have the unique problem where they influence the people they are supposed to model. If your business is societal models, planned obsolescence is part of the deal.
A lot of so-called experts don't quite grasp the former and don't care about the latter. They cannot be relied upon for actual decision making, since the low level details are what's hard!
> "This is why you never, ever take anyone seriously who thinks of society like a model."
Yet that is precisely what classical economic theory has done, for decades! It boggles my mind how long it's taking for that kind of reductionist, simplistic, reality-ignoring "thinking" to mature.
"Reality" is necessarily a model. Your brain doesn't see photons, doesn't touch objects, doesn't respond to audio waves.
If you are sane, then your model must not be subject to your will; therefore it is outside "you" even if within your skull, and performs as a trusted intermediary.
Sure, on that point we're agreed. Our perceptions (distinct from sensory input) are dependent on a conceptual framework / paradigm / model. But I didn't say models were useless, I was pointing out the profound flaw at the heart of typical economic models. Classical economic theory reduces the messy reality of human interaction to a handful of simple pseudo-mathematical axioms, then proceeds to build complicated formulas and algorithms atop this unreliable foundation. It's only quite recently that real-world complexity is (finally!) entering the picture, thanks to things like the Santa Fe Institute. It's reminiscent of the Copernican revolution.
I think it's something inherent in the self-selection for the politician/bureaucrat process that makes them inherently unable to believe that people aren't cogs.
This is not a planning problem - this is a power problem. If competent and incompetent people alike are told to regard each other as peers in a meritocracy, a range of possible outcomes ensues.
The only option for incompetent staff will be to game the system by ensuring that they pass a load off their shoulders to competent staff and cultivate cultural and organisational aspects that let them give the impression of performance without actually having to perform.
This article is quite anecdotal but it is possible for organisations to require high performance from members. E.g. I assume that there is less scope for less competent individuals to hide out in teams like SWAT teams, heart or brain surgery teams, bands or movie crews: every one is visible and under the spotlight for delivery at any one time and relied upon by others to be at the top of their game.
Critical dependence should trim incompetence from organisations, but will only work if scrupulously applied. Perhaps logically, this might work best in fluid structures where selection and deselection of team mates / suppliers is very easy.
Interestingly enough, the pay for these individuals differ too. And this matters as well. We should be taught to negotiate. This is the most underrated thing our industry and seniors don't tell juniors of the field.
I learned this the hard way. After 5 years when the company was winding down, I learnt 5 colleagues of varied gender and race who were my colleagues were paid shit ton more than me. I know this is a sensitive topic. But if you ask, they will pay more or you will know how much you are worth. I thought the system will acknowledge and reward accordingly after I got a surprising bonus. IT DOES NOT. You have to fight for it. I felt really betrayed. And this is when everyone told me how and when to negotiate.
From the moment you are hired, you bargain for a better pay. That itself, from that starting period itself, your pay differs compared to the other person who may have been hired with you. Then not everyone takes the same effort (they can't or don't want to for varied reasons). But some people do a 9 to 5, the other people does late nights, some people are dettached from company and it's vision, some are are very loyal. It depends on individuals and their circumstances.
Handling everyone the same way doesn't work. This discourages people who want to put in more effort. So they jump ship and move to another company for a better pay. No person want the same amount of pay, they all want more. And the answer is negotiate. And ditch and make some noise on companies which have stereotype pay. Trust me. It is not the right place for you to work.
Imagine this, giving $1 million dollar to ten people and see how much money they all have after a year. It will all be very different for each of them. It will not be the same amount. That is the same for salaries, you salary at this point are based on how much you worked and how much you bargained. It won't be the same for another person with same experience and same background. It just won't be.
Abstraction is necessary to deal with things at scale, on a programming focused site i think we all know that and know that often the trade off is inefficiency. Its probably to expensive to track all these peoples real value and really it doesn't even matter. What was the consequence of all these supposedly valuable people leaving? Did the stock drop after the guy saving millions a year left? Probably some pointless project was delayed that would have been delayed anyway. We are nothing but cogs in a machine that doesn't care about the cogs.
I think you'll just drive your self crazy worrying about corporate waste and monetary inefficiency (environmental might be the only thing worth thinking about). There always going to be waste and there's no awards when its fixed. I used to be concerned about money being wasted, but now, IDK why I cared in the first place. Its not my money and I don't get any of it.
> Abstraction is necessary to deal with things at scale, on a programming focused site i think we all know that and know that often the trade off is inefficiency.
We also all know that abstractions leak, and sometimes... Not always! But sometimes, those leaks will kill you. CPU details are irrelevant, until per-opcode details give you a 10x speedup. Compilers are a magic black box, until a compiler bug breaks your code. Hardware is cheap, until someone notices a way to save millions by caring. And yes, sometimes developers are interchangeable, until they make or break the company.
If you're at some adtech company where the entire point of the advertising is to cancel out some competitor's advertising and you're only there for the paycheck, efficiency is irrelevant because the company could be destroyed by a giant meteor and nobody else in the entire would would have any reason to care.
But not all jobs are like that. Some people make medical devices that save lives. If the company is inefficient, they don't save as many lives, and that matters. Some people are in charge of making loans to people or selling legally mandated insurance and the rate the customers pay has a significant effect on their economic well-being. Some jobs are in the production of food and the work impacts the quality and price of food. Some companies make fire suppression systems or automobiles or industrial equipment, and it needs to be safe without being unaffordable.
Today I worked with Company B, founded by former workers in Company A who were sick of Company A's dishonest, high-pressure, customer-hostile sales tactics (which I personally experienced).
The guys who left Company A didn't stop Company A from continuing to be the #1 provider of widgets (for now). I'm sure the Company A stock price didn't care.
I'm still very glad I get to work with Company B rather than Company A.
Individuals do matter but outside of their immediate manager no one has knowledge, time, or attention span to account for it. It is a case of "all models are wrong, but some models are useful" and this is why sufficiently high level plans and budget allocations follow the assumption of fungibility.
> But many effective interventions cannot have their impact demonstrated ex ante in any simple way because, among other reasons, the composition of the team implementing the intervention is important, resulting in a randomized trial or other experiment not being applicable to team implementing the intervention other than the teams from the trial in the context they were operating in during the trial.
This sentence really confused me, and I spent a couple of minutes trying to parse it. For anyone else reading, I think "not being applicable to team" is supposed to say "not being applicable to teams".
I’ve experienced a corollary to this: individuals don’t instantaneously gel into teams. I’ve found places that try to solve hard problems by “finding good folks and putting them together on a ‘squad’”. Or, deciding to reorganize and just breaking up teams and mashing them up in weird ways.
What I have seen work: swapping managers. Leaving the team intact but bringing a new manager in can actually change execution a lot. But this is just not how a lot of businesses like to think.
For large corporations I think it inevitably people with a C title regard troopers in the trench as mere numbers, just as a general does. He has to because his mindset doesn't allow otherwise. For such a large entity to survive, the leader has to have a "collective" mindset.
My recommendation is to move to smaller companies/organizations so that individuals may be treated more independently (regardless of whether their job matters or not).
It's certainly not perfect, but it is funny to me that the author on one line complains the Peace Corps "produce[s] little value" but then in the surrounding lines talks about how important it is for individuals to bridge and bring contextual incisive change that consistently resist abstractions and not just look at the problem from the outside.
He's falling for his own simplification of individuals and lifetimes.
That kind of nuance sounds exactly like the skills Kennedy and his associates were intending to cultivate in individuals from the USA during and returning from Peace Corps when they created the agency: see e.g. https://en.wikipedia.org/wiki/The_Ugly_American Ugly American (1958). Huge percent of state dept employees. I'd be willing to wager Guinea Worm intervention mentioned involved RPCVs. Notably, Netflix founder, RPCV. It has 3 stated goals. This is essentially one.
> He's falling for his own simplification of individuals and lifetimes.
Totally.
> complains the Peace Corps "produce[s] little value"
This is what happens when quantitative minds encounter the real world. It's a consequence of putting engineering on a pedestal and ignoring any and all context.
However, the top comments on the thread give me hope that many more people see the thought errors in this piece than people who revere it.
I've seen projects come in factors of 3 either way depending on the skill set of the individual.
Having myself made these mistakes another thing I have to make the effort to extract is "how long would it take me" vs "how long would it have taken me 5years ago before I knew what I know now".
It's amazing how many times the "big picture" changes can lead to complete overhauls or rewrites of otherwise consistent and well built software stacks.
I think there is a structural problem here that we are avoiding. The reason some higher ups don't see the merit of particular individual developers is that their pay does not reflect their contribution. Pay is the simple metric that should reflect worth, but we don't use 10x or 100x pay scales. We are failing to pay stars and superstars in accordance with the value they contribute to company. profits.
This is something I fail to understand. no-one blinks an eye when proposing a high performing CEO he compensated appropriately but propose the same for an engineer and everyone looks at you funny unless you give them a VP title and saddle them with a bunch of non-technical responsibilities in the process. If an engineer is the crucial individual in creating and delivering a product that the companies profits are derived from they should also receive appropriate performance based compensation in line with senior management, perhaps even more as senior management is definitely more fungible (namely C level roles like CFO, etc).
if your org doesn’t work for you in some fundamental way, find a way out, immediately. you can’t change the board, and the board gives hr it’s marching orders, so if you have management you consider to be terrible and a “clueless” hr team, you have to leave. orgs can evolve over time, but they don’t change for you or your feelings, no matter how smart you are or how justified your feelings.
An overlooked notion, analogous to fat-tail, high-upside ROI is the absence of a similar downside risk. In the case of the sclerotic, flagging, midsize company failing to adapt, we're actually talking about a fixed downside (the company can fail) and a virtually unlimited upside. In this case, allowing talented humans to explore seems mathematically-required. And yet...
Indeed, exactly as you say, people are _not_ interchangeable - we know that already since communism relied on that false premise, viewing individuals as just “means of production”, and utterly failed.
HR as a function has increasingly become an obstacle rather
than a managerial support function in recent years. Instead
of personal relations with trusted, long-term people staff, employees and managers get mailing lists attended to by outsourced cheap labor call Center agents. It is CPOs’ and CEOs’ fault that they let greed cut into employee well-being that much, and of course once one company does that, all other corporations adopt the same nonsense, since they all copy playbooks.
“… when ROI is a heavy-tailed distribution … then severely tamping down on the right side of the curve to improve legibility is very costly and can cost you the majority of your potential returns.”
The one strategy that the article doesn't cover, but which I see often, is where the top leadership says "We need to keep headcount down, but we need to get more software development done, so how can we do it without any extra people? Oh, I know, we will outsource this to an outside agency."
And yet, the outside agency costs more than actually adding to the headcount, so it is not cost effective. However, it is seen as temporary, so it this strategy is favored. There is the odd fear that headcount is permanent -- a fear that is mildly true in Europe, but definitely not true, at all, in the USA. Yet in the USA I still see managers who are eager to outsource.
The outsourcing tends to become permanent. The idea that it is somehow less permanent than headcount is a pure fiction.
But to the main topic, I appreciate this essay for emphasizing that "People are not fungible." I've tried to emphasize this in my own writing. I think, in general, writing about startups would be healthier and more realistic if we had more case studies that emphasized the role of specific individuals, for good or for bad.
In my own book, How To Destroy A Tech Startup, I tried to emphasize this:
-----------------------------
Emotions matter. We might hope that those in leadership positions possess strength and resilience, but vanity and fragile egos have sabotaged many of the businesses that I've worked with. Defeat is always a possibility, and not everyone finds healthy ways to deal with the stress.
More than once, I’ve seen startups self-destruct.
I'm making a point about the importance of the individual in a small startup. In a large company, an eccentric individual does not do much damage. Even when such a person is in a leadership position, the company will have a bureaucracy that can ensure some stability. But when a company consists of two, or only a few people, and one of them reacts neurotically to challenges, that company is doomed.
I’ll relate one of my previous experiences to illustrate this point. From 2002 to 2008 I spent most of my time working with an entrepreneur who had inherited a few million dollars when he was 25. He managed to burn through much of his legacy in just the time we were colleagues. He admired musicians and considered the music industry glamorous, so he built a sound studio. It never made money. The bands that stopped by were broke. Those few who came up with a hit song mostly signed with a major label which, typically, had its own recording studio.
I met him in 2002 when his focus was shifting to the Web. I had developed some software that allowed people to create weblogs. Typepad.com, which offered something similar to what I'd built, had just raised $23 million in funding. Surely we could do the same?
Working with him was difficult. We might go like maniacs on some project for four months, and when we were on the brink of unveiling it to the public, he would grow bored with it, and move on to something else. The first time this happened, and I asked him his reasons, he improvised some arguments that sounded plausible. Perhaps he suggested there were already too many startups doing the same thing. But this pattern, where he walked away from a project just when we were ready to introduce it to the public, repeated itself. What led to this self-sabotage? As I met his whole family over the years I got to see the sad dynamics that ate at him. He had a desperate need to impress his father. A modest business success would not be enough, in fact, it would leave him embarrassed. Only the creation of something as big as Google would impress his father. But to grow that big, we would first need to be small, and that was the step he had no patience for.
As the years went by, and he burned away all the money he'd inherited, the stress wrecked him. His self-image became increasingly grandiose. He told people that he was a visionary, someone who was able to tell what the future would look like. Late at night he would smoke marijuana and read articles on Slashdot and TechCrunch and then put together an amalgam of words that seemed full of the bright hopes of humanity, which he offered up as our marketing: "The Universe is fundamentally electromagnetic yet non-sentient, and we are sentient but only partly electromagnetic; the Internet is the ultimate harnessing of sentience to the fundamental forces of the Universe. Therefore our software will put you, our customer, in the driver's seat of real-time conscious human evolution." Later, when he wrote up our business plan, he put these two sentences in the Executive Summary. I’m not joking.
He had no ability for internal dialogue. Only by talking to others could he hear his own thoughts. At our peak in 2007, we had eight people on our team. Sometimes I would look around the room, when he was talking at everyone, and I would think, “If you add up what we pay all these people, we are spending $300 an hour so that he can have an audience.” When he felt fear about our chances of success, he would need to talk to everyone, and when he was euphoric about our chances of success, he would need to talk to everyone. Therapy would have been cheaper.
Something along the lines of what was described in this article has recently been forced upon my team. You could imagine how that turned out. Hint: not very differently from the outcomes in the article...
humans are herd animals after all. So big orgs are reluctant to listen to indiviuals but their leaders. They wouldn't do a thing but listening otherwiese - there's just too many individuals. Held a 5min talk about that 2018 https://txt.mro.name/35c3/35c3-dissolving-gafam_--_480p.mp4
this is pretty much obvious to people who study and design systems.
Russel Ackoff pretty much nailed it by saying: a system is a whole that consists of parts, each of which might affect the whole. taking the best parts from say a toyota and a mercedes won't make the best car.
same thing with individuals, in a team you need cohesion. not just the best individuals.
This is a really interesting and enlightening article that covers an important topic, and it's honestly sad that it will get less engagement than some clickbait or hot-topic issue.
It's really hard for me to take this author seriously after his "Willingness to look stupid" post that went viral here about a month ago. The entire post was ridden with a superiority complex about how he's willing to look stupid, but never willing to explain his actions that make him look stupid. https://news.ycombinator.com/item?id=28946490
Maybe his reason for wanting a small box computer was idiosyncratic and weird and he preferred not to discuss it. Maybe it was part of a bizarre prank or a secret project.
The dictum "think horses not zebras" has its value - ordinary possibilities are more likely - but it doesn't say that zebras don't exist.
To be honest, this comment is a perfect illustration of why Dan had to write that essay. Some people can't see beyond the obvious, and if the obvious is "this guy is stupid", well, you better not be afraid to look stupid.
It is far more important to be able to explain your line of reasoning to those around you, especially professionally (much of the essay was about school/work), than it is to hope your coworkers are able to "see beyond the obvious".
Or maybe it's far more important to be okay with looking stupid than to assume that lack of understanding from others always means something negative about your communication abilities or choices.
If someone can't imagine any other reason someone would look stupid in the eyes of others than because they explained something poorly, I wonder how much experience of life have they had?
> If someone can't imagine any other reason someone would look stupid in the eyes of others than because they explained something poorly, I wonder how much experience of life have they had?
This is not what I'm saying - of course I can personally relate to the experience of looking stupid due to a poor explanation, and I'd imagine most people here have too. My issue with the article is that the author doubled down that looking stupid was correct. When I feel like I look stupid because I can't explain my line of reasoning, or because I didn't have enough prerequisite knowledge for the conversation, I will typically apologize and immediately start explaining my line of thought and asking questions around the unknowns. However, the author's attitude is that when they look stupid it must be an issue with the other party, and they have zero obligation to try and make themself look better. This is a MASSIVE red flag (especially in terms of hiring)! If the author doesn't have the empathy or emotional intellect to understand why being able to explain what you're trying to communicate is a /good thing/, it's difficult for me to take them seriously.
I think you misread my post. There are other reasons people can look stupid than they did something wrong. It is neither accurate nor virtuous to blame yourself for every negative outcome.
Lacking emotional intelligence to explain my motivations is something I’ve struggled and worked to improve my whole life. But it doesn’t make my motivations invalid. Just harder for you to understand.
