Individuals Matter
danluu.com
danluu.com
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.
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.
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.
Practically all the actual work a PM does can be replaced with a script and dashboard
That is entirely true if you have an organised, disciplined dev team that communicates well.
Good luck with that.
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
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".
/s, obviously
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.
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.
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.
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.
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.]
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.
I think you've been fed some exaggerations.
- Bill Gates
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.
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.
Are you HR, by chance? Have you ever coded something in your life?
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.
The latter I've seen. A lot. The former I have not.
I have also seen -10x engineers. Generally the best you can do is stay well clear.
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.
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.
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)
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.)
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.
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.
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.
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.
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.
Former is peaceful, the latter is deceit.
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.
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.
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.
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.
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.
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.
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).
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? Aren't you supposed to be re-estimating regularly?
This had to be accurate, as it’s consulting, if the hours are wrong we lose money.
But only a direct line manager can do this, anyone else won’t have the knowledge of the staffs capabilities.
Fire me into some unknown terraform and I'll be able to orient myself faster than someone who only does C# every day.
Send me into my own terraform and I'll be faster still. Not all things are equal.
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 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 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.
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.)
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.
I haven't overshot the estimate yet.
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.
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.
"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.
Why do we pay these people, again? Remind me?
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.
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.
"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.
This has been so endlessly repeated without thought that people assume it is a fact when the Truth is far from it.
Excerpts from wikipedia - https://en.wikipedia.org/wiki/Waterfall_model ;
* 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
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.
Do the hard thing and plan projects individually.
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.
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.
Commit to a deliverable or a deadline, but never both.
Should I attribute it to xvilka or did you get it from somewhere else?
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.
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?”
Etc etc.
It's remarkably powerful.
It'll take more time and result will not be as clean.
Basically learn from older engineering disciplines.
> 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.
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.
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.
(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)
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.
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.
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.
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.
It is about making sure resources are most efficiently allocated to meet the business objectives.
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.
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
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.
> 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.
You are on the money[1]. People want to estimate work without even telling what is it that needs to be done in the first place.
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
It's not just wishing for a goal - a three year old can do that - but enabling to go the way there.
But a statistical estimate may be possible indeed.
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)
Treating even the same persons output as abstract is fraught with issues. One month a rockstar the next a schlub.
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?
/...almost everyone
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.
Anyone else have more things to try?
Periods of very high output, and then periods of slump. Not much of a long term stable in-between.
I wouldn't be surprised if that's very effective for the right kind of project.
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.
Rich Hickey
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.
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.
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.
It's generally cheaper to poach engineers than to buy a company. Just food for thoughts.
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.
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.
A good team can be better at something than all it's seperate members.
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 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.
> 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.
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.
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.
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.
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!).
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.
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.
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.”
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.
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".
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.
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.
[0] https://blog.bryanbibat.net/2009/08/31/spanish-theory-of-val...
Weening is the process if transitioning from milk to solid food as in babies and puppies
a) it makes you inflexible (i.e. you cant readjust by constantly hiring people that fit whatever your new goals are better)
b) it means you are to easy on people and keep low performers around
c) b) means it also makes trajectory upwards harder for good employees, so the good employees are more likely to be the few who quit
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.
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.
Of course firing low performers is quite different from high performers leaving, but HR doesn't see or care about these distinctions.
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.
Company culture matters https://danluu.com/culture/
Different organisations have radically different expectations about how fast and well you can work https://danluu.com/productivity-velocity/
Different organisations are capable of different things because of the (kinds of) people who work there https://danluu.com/in-house/
Two different kinds of oransations work very differently https://danluu.com/startup-tradeoffs/
Different organisations hire differently and this can be an enduring (dis)advantage https://danluu.com/tech-discrimination/
Being better than most people isn't that hard because most people aren't trying https://danluu.com/p95-skill/
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.
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.
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.
There are even examples of this in the article.
I think there are ways of reading this without ever thinking some people are 10x super humans while the rest are not.
Put a person who doesn't get along with people as a team leader and watch what happens.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That's why we make new JavaScript frameworks.
That's why the brightest minds of a generation are dedicated to making surveillance advertising more effective.
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!
Luu: "I want the computer with the smallest box"
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?"
Of course I can, but I want to hear the horse's reason from the horse's mouth.
> 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.
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.
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?
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.
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.
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.
> This is why you never, ever take anyone seriously who thinks of society like a model.
The description above is just a different 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.
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.
How can this be done for white collar roles?
Maybe like Amazon? - See this article : https://chrislaing.net/blog/the-memo/ (just a suggestion)
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.
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.
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.
Not all jobs are an exercise in futility.
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.
There is still such a thing as honor among men.
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".
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.
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).
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.
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.
EDIT: Quanti- not quali-
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.
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.
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.
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
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.