These things always have a grain of truth to them, in that they describe some places some of the time, but I also think there's so many things going on in any given place it's hard to generalize.
A well-run organization will hire the right people, and then foster their development in such a way that they are productive, happy, and grow, and will compensate them sufficiently. If any of those things break down, you can run into any number of problems, and they won't necessarily take the form that seems obvious at first.
I've seen organizations take very competent people and ruin their morale and shunt them into projects that were really detrimental to them getting out, in ways that aren't obvious at the time. Or weird organizational dynamics cause changes over time that make someone look bad in ways that aren't their own fault.
There's just weird things that happen that don't simplify to simple models of "talent that is completely independent of environment and perfectly visible."
Have you ever personally had a long term career in a corporation that somehow managed the escape velocity to actually become something other than typical? i.e. typically toxic and bound to these laws?
Yes but only due to near 100% turnover of management and toxic coworkers in a short amount of time. It was weird the day I realized I was essentially working at a different job.
I'm always going to cringe at Twitter's "star" engineers who spend an average of 7 months in each company. HTH do you even understand the product and contribute in that time frame? One of two things needs to be at play:
1. You were brought in to do very specific work (i.e.: migrate something to k8s).
2. You were brought in as a token due to your social media following.
Haha, it typically takes 6 months to get up to speed at a company as everyone has their own set of unique tools and infrastructure. Also at that cadence you are not vesting any stock(1 year cliff?) so that seems very strange. Having worked with high-vis engineers in the past, alot of them seem to be vanity hires, they really don't impact much change and probably stoke the egos of the upper managers/execs much like (prof. slughorn from harry potter), collecting "geniuses".
if an engineer can't make impact until 6 months later is this engineer even worth hiring? Large organizations typically take longer time to ramp up, but regardless of size I expect to make impact at least to my team within the first month of hiring.
>1. You were brought in to do very specific work (i.e.: migrate something to k8s).
That's how most work gets broken down though. Just find an entry point and start reading code. Read docs, comments, find dependencies, figure out what needs to change in light of your change.
You shouldn't need deep product and tribal knowledge to make simple changes.
In most places you don't need deep product and tribal knowledge to make small changes. You need deep product an tribal knowledge to know what small change to make. Almost anyone new at a company will have someone else telling them what the first thing they need to do is, and that person is telling you to do something that wasn't important enough for them to do themselves.
For what it's worth, the best interns/juniors I've had started out making simple changes like this. I'd break down the work and parcel it out for them every day until they had accomplished something big. Then I'd start parceling it out less and less until they just knew what they were doing.
As we are just transforming people quotations into laws and effects, let me add mine.
”In a heated market, where it is easier to crack code interviews than to prove yourself a talented and effective IT engineer, the least talented and effective engineers are more likely to leave, to float away, because their employers have less reason to try to keep them. Those who tend to remain are the ones who have more “weight” in the company, as their effectiveness and talent are better evaluated by their colleagues than external audience from conference talks, blog posts, and code interviews”
I've heard this as one of the key justifications for an internship program. Outperformers are likely to be aggressively retained by their first employer, so if you want a fighting chance at landing them, that had better be you.
My general experience, at least in start-ups, has been the exact opposite. In a good company with great culture and good compensation, strong talent was usually in for the long haul, and those who don't find their place leave after a year or so.
In bad companies that's not true of course, so perhaps this can be a good measure of company quality - if their top talent are indeed good and are there for a long period of time, it's a very positive signal.
One example I can think of is Redis Labs - the core group of engineers have been with the company for almost a decade, and these guys are some of the nicest, most humble and most talented engineers I've ever met (And of course there's antirez who's in a league of his own).
The most important thing you can do during a job interview is to as best you can figure out who the talented people are and how long they've been at the company. If the most talented people are the people who have been there the longest, it's a good sign. If the people who have been there the longest don't seem to do any technical work and seem like powerpoint monkeys, it's a dire warning sign that the company is deeply dysfunctional.
In any case, the "Dead Sea Effect" is not a general truth, it's only true in dysfunctional organizations. The author of the linked post seems to be a consultant who helps failing IT organizations turn the ship around. I think his experience has led him to self-select into the dysfunctional ones.
A good company will appreciate talent, enable it, recognize any lack of it, and create some form of community. So it's a bad place to be a vampire, but a great place to be talented.
A bad company will fail to appreciate or enable talent, not notice vampires, and have no real community. Great place to clock in and get a paycheck, but not very fulfilling.
Talented people tend to be driven by interest at least enough that it's worth it to do things they're interested in.
One way we try to combat this is the way you get salary increases is mainly through promotions. Promotions are based on reasonably solid criteria and you can go up for promotion anytime you want (max every 3 months). Engineers senior to you determine whether or not you meet the criteria in a forum that is loosely based on a thesis defense. you answer questions and show your work and how it demonstrates the skills. People are either learning, executing, or teaching a skill.
People that dont get promoted get very few raises so are incentivized to leave.
The levels are essentially:
1) learning core skills under heavy supervision
2) ability to develop a feature with moderate supervision
3) ability to develop a product as it was envisioned, independently
4) ability to conceptualize a product, kick off a new product, and change direction in the middle if need be
5) ability conceptualize a portfolio of products and how they interface
6) ability to run a business unit of products
7) ability to start your own company (at this point we fund people to start their own company)
There are more detailed criteria around leadership, growing other people, contributing to recruiting, understanding, finance/accounting (P&L), following a solid methodology, contributing to the intellectual property of the company, improving the operations of the company, ability to deal with various level executives outside the company, exhibiting the values, being an expert in something etc
(This could explain why google has a hard time maintaining their old projects: Google on the resume is so so valuable that whoever doesn't rise within google leaves and gets a rise at another company.)
I too think this depends on how dysfunctional the company is and in what way it is dysfunctional.
Overall, with reasonable management, people have better idea about your skills and abilities after working with you then shortly after interview. Interview is artificial short situation. If that applies, staying makes a lot of sense because you get more challenging tasks, more autonomy, your word is trusted, you have more say in negotiations. Leaving to another company means that you have to start again less trusted, won't get those challenging tasks and generally need to prove yourself before gaining the same back. Plus yoi risk that environment in new company will be more toxic. Changing team is in the middle - you have reputation and sometimes simply need change so that you don't stagnate.
In such organization, pure talkers loose credit over time, get moved from team to team and no one wants to keep them and end up on project they themselves don't want and nobody wants and leave.
Obviously, if the company starts to be dysfunctional over some treshold or stagnates, the high quality people will leave as the above benefits get lost. If it is toxic or unchallenging right now, you are good chance another company will be better.
> Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven’t all gone away! There is a profound lack of professional and institutional memory in IT;
Brooks also used his analysis to give a solution -- which (AFAICT) nobody has ever implemented. The problem isn't lack of 'memory'. His ideas weren't adopted even when they were new. It's amazing that after 45 years we're still pointing to this book as a must-read which correctly explained the problems of our industry, yet managers universally ignore the chapters which explain what to do instead. I don't see that happening in other fields.
> almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.
Good luck with that. Brooks' book is sitting on every manager's desk in the world, and he couldn't get them to read and follow it. Another blog isn't going to help. Things are only going to change when the industry has a "come-to-Jesus moment" -- like if software starts killing people and the government steps in and says "hey maybe you should all be required to adopt NASA's methodologies".
There needs to be some sort of prerequisite to make this valid.
Having been through a number of downturns in my career, you do see really talented people leaving at the worst time possible for the business. But assuming that everyone who leaves is your best talent is not such a good thing to do.
For people leaving in a downturn that is a reasonable assumption. If the employment market is bad, then mediocre employees have no good options to leave - they might try, but they won't find anything better; but really good techs will have opportunities in any market; well, at least they had in the last 'busts'.
I've seen plenty of people in IT with mediocre skills having no problem at all finding new jobs. I've also seen talented developers stay in the same place for a long time.
I'm much more willing to believe that the quality of engineers at an organisation has more to do with the organisation itself and the sector.
I've noticed that some people hold a grudge against mediocrity that I don't entertain, and yet they don't know what to do with belligerent incompetence and so they try not to think about it, whereas I can't stop thinking about it.
Overqualified people working on a project can produce some heinous code. What I want as a team lead is to know how far I can trust people with different tasks, figure out who can be stretched in what directions, make a stab at scheduling the work out to try to minmax that equation, course correct a few times, observe outcomes and root causes and try to put safety equipment or process in the places where things start to go wrong the most.
You can get a lot of important if boring work done by 'average' or 'below average' developers - as long as they don't suffer from Dunning-Kruger.
Performance is on a bell curve (and not static). If you're trying to run your project like you only have to deal with the top 20%, well guess what, you're still going to have a bell curve. If you're in charge of any strategy and you won't acknowledge this, then you are the biggest idiot in the room, and I don't want to hear your opinions on who the second biggest idiot is.
> Overqualified people working on a project can produce some heinous code
> You can get a lot of important if boring work done by 'average' or 'below average' developers
This is why google developed the go programming language - dumb enough that people can't build overly complex abstractions, but capable enough that average engineers can churn out productive work.
Here, I reversed it and it sounds about as believable to me:
> The "Anti Dead Sea Effect" suggests that in any organisation, the skills/talent/efficacy of engineers is often proportional to their time in the company.
> Typically, lowly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to leave the company, as finding employment elsewhere is not difficult. This is particularly pronounced if they have not gained incremental pay rises over their time in the company, due to their poor skills, as it can be easier to fool someone else to pay them more.
The other side of the coin is salary compression and inversion.
That’s where HR policies dictate that no one will get more than slightly above cost of living raises no matter what while at the same time having to bring new employees in at market rates.
You find a situation where the more tenured employees are getting paid less than new employees with the same skillset but without the corporate understanding.
This varies enormously by the history of the company. I've seen situations where companies are quite stable and very happy to give tiny increases to manage their costs and don't care if they lose engineers because it's not like an individual engineer is actually going to make or break the company. This tends to be true at very large organisations with mature markets. These are the sort of companies that kind of know they aren't going to increase their revenue beyond a certain point so they're focused on reducing costs. A side effect is managers hire in at high salaries because they know the increases won't be big and you end up with a shuffle of slowly inflating everyone's job title. Suddenly you're hiring senior staff out of university.
On the flip side though I've also seen senior (long serving) staff massively overpaid, because they got massive bumper promotions and pay rises during growth periods for the company, and then when things tighten and growth slows, they're still sitting on very generous pay. Particularly in 2010-2015 where staff had got big increases in 2000-2007 but all the new staff had been hired during the recession.
It can be true to a certain extent in that you may have _some_ engineers who aren't very good sticking around in some organizations. But why would you think that is the case for most of them? You might have engineers deciding to stay because they have a family and think their job is fine.
Or maybe for organizations that have poor leadership or existing engineers, that is the case that the good engineers realize that and leave. But for really good organizations, they are extremely selective in terms of recruiting and compensate employees highly, with difficult but rewarding work, it might be the opposite -- people who weren't really cut out for it are quickly eliminated.
For me personally I eventually came to the conclusion that there was no perfect job, and my plan for personal growth is not to flit from job to job anymore trying to get higher salaries, but rather to save and work on side projects to hopefully eventually have my own business. So for that strategy it doesn't make sense to keep switching jobs.
To all those people throwing doubt on this, you are highlighting a situation where there are a dozen downturns in a career. Better people last longer.
People who switch more often however ladder up on their skill sets. Taking a diverse number of approaches that change from place to place and adapting nicely to them all and maybe even bringing a few skills from elsewhere to help in their current job.
A comfortable job makes you stagnant. Movement is good. Even within company.
To provide some context on this, Bruce Webster worked mainly as a consultant that triaged projects that have missed their targets. Therefore, his definition of the "Dead Sea Effect" probably comes from his almost exclusive experience with failed projects and ineffective teams.
Source: He taught my software engineering class and this blog post was required reading. I think his "thermocline of truth"[1] is one of his more effective metaphors.
This assumes that skill and efficacy don't come from domain specific/company specific experience.
You can be a lousy engineer, but if it is all your lousy code and you know it line by line, you will be a heck of a lot more effective than the star engineer who has been there for just a few months and hasn't learned the codebase yet.
I'm not sure that's true. I've seen incompetent engineers working away to maintain their own "house-of-cards" systems that break easily and take forever to change. Then within a matter of weeks a competent engineer comes in and replaces the whole ball of yarn with something that fast, clean, and doesn't break.
It's a cute anecdote, but I don't think it really illuminates enough or even thinks through the implications of its analogy.
Water evaporates out of the Dead Sea because there is somewhere better (in the sense of lower humidity at least) for it go.
If you treat people as evaporating and disappearing when they leave your company, you'll never have a clear picture if the dynamics at play. You need to think about where they are going and the relative difference between their current environment and the other one they escape too.
When the air holds enough humidity, it rains on the Dead Sea too sometimes.
In an ecological sense, the water level in the Dead Sea is dropping because Israel and Jordan siphon off too much water from the Jordan river for irrigation. By the time the river gets to the Dead Sea, the average flow rate is lower than average evaporation.
There is probably some metaphor in here for having a bad reputation decreasing your hiring funnel.
I think that's primarily true for companies that don't pay their engineers enough. The companies that pay a lot of money obviously don't have problems attracting and retaining talent.
Yeah, the reason some company might experience this effect is because the company is managed in a way that makes people want to leave as soon as they have a chance. The problem isn't the employees.
Anecdotally, I find the opposite to be true. Also part of being "effective" is having a large amount of system knowledge which you would build over a long time.
The problem with general advice. I would say most engineers take 1-2 years to truly grok the business, internal relationships and the whole of the technology stack you have deployed. So if you’re jumping ship every year or so like I sometimes see recommended you’re not really ever firing on all cylinders.
Once you have the big picture and have deployed multiple projects - is when you can start proactively fixing systematic issues that you’ve identified
For engineers, is it ever really worth it to understand the business?
I can see the enormous harm having no technical people who know the domain causes in my current role, but the benefits of learning it seem to be slim to none for the individual engineer. The harm is in low productivity for my employer, but they don't seem to care about retention anyway. Most do not.
The Dead Sea effect is also what you get when people are rewarded for designing a system with unknown performance properties. They get promoted and move onto another project, meanwhile lower level people stay on board and discover all the quirks, oddities, bugs, flaws, shortcomings, etc of the "well designed system", and have to do solid work to keep it running.
Of course, that's all they are viewed as doing - keeping the system running - all the glory was reaped by the evaporated developer who moved onto other teams to make similar mistakes as before(since they weren't around to experience/fix them).
I have seen this a few times. In fact one place I've worked had it so bad that this was entire MO for a "director's pet" engineer. it would not even be a fully functional product but just a proof-of-conceptish hacked together design that demos basic feature with a bunch of shortcuts. this would be just credible enough to take credit of the design and move on. I have even seen him create a bunch of confluence pages with half baked info just so that the claim could be staked.
usually this is accompanied by technically clueless management.
This feels like a gross oversimplification. The last company I left had plenty of brilliant people that I would consider at least as smart and knowledgable as I am. Many are still there. Those people have a lot of influence and credibility within the organization and value those things. Some people stick around because of the maturity of the organization, as they have worked in less stable operations, i.e. lots office politics and backstabbing, and know how bad it can be.
I'm not saying I don't think I'm smart, but my primary motivation was compensation.
Please follow the site guidelines. Note this one: "Please submit the original source. If a post reports on something found on another site, submit the latter."
EDIT: a comment on that link makes the point one of the best ways to retain great developers is to surround them with other great developers. I think this hits the nail on the head.
Here's a good example of companies and execs min-maxing their human cattle. How about you just do a good job evaluating your employees? If you're happy with them, great, if they need improvement help them. If they're doing a bad job replace them. Stop assuming the personal motivations of other people's lives with your pop-psychology nonsense.
> How about you just do a good job evaluating your employees?
Sadly, bemoaning the capriciousness and unfairness inherent to workplace politics does nothing to diminish the presence of politics in the workplace.
The in-crowd gets the good work, the promotions, the clout, and the money. Everyone else gets to maintain the balls of mud that these people crank out as stepping stones on their way to the next position. Certainly a state of affairs which is appropriate to bemoan! And then when you're done bemoaning, you can either ride the train or get run over by it, your call.
You can say the fancy guys, the "10x engineers", the "thought leaders", the people posting on Twitter all the time aren't the real, true engineers, because they don't stick around to see their efforts through. And maybe you'd even be right about that in a lot of cases. But somehow that notion doesn't seem to bother those people very much...
This is something I've been mulling over for such a long time and want to resist simple answers.
But this phenomenon seems to hold true no matter the organization: A new hire for position or level X with Y years of experience will ALWAYS have a higher salary than a veteran at that organization with level X and experience Y, for Y > ~2yrs.
Some people bounce around to different companies. They are never necessarily productive in the roles they are constantly leaving. They may be only "talented" at being hired.
On the other side of the coin, the author defines the "residue" as "the least talented and effective IT engineers... that tend to be grateful they have a job and make fewer demands on management" and "tend to entrench themselves, becoming maintenance experts on critical systems".
Aren't these so-called "residue" people at least demonstrably "talented"? They are providing value to the company by maintaining things that actually make the business money without grumbling about it.
As others have mentioned, this is entirely dependent on the organization. The issue is that talented people hit a ceiling faster than anyone else. Organizations aim for stability, and that will usually come at the cost of stifling top performers.
Businesses have their growth cycles, and ambitious people are attracted to growth. Many times, they will ride the growth wave of a company until its crest, then catch a wave at a different company.
I have personally never encountered a company that had an adequate mechanism for retaining these kinds of people, and maybe they shouldn't. As long as they don't burn bridges, maybe they will come back and work on a future project.
The principle would be just nice if it were true, but it has different assumptions that don't hold in quite many situations.
To me, it appears it presumes almost something like Santa Claus existing world, where "everybody gets what he deserves" (where you "evaporate" to some place better for you) which isn't how typically the world functions.
Moreover the concept of "talent" is involved in the principle, which is not something that I would use as the name of the property that I would use for selection of people who'd work on some project.
Yeah, I can't help but detect some wishful thinking on the part of the author. If you're asserting some principle, there ought to be an objective way to validate it - so, how do you know? If it's really true that "the best people will always leave", they'll leave the next employer after they left you. So, the best people are definitionally the people who never keep any job for any appreciable amount of time? How could you possibly measure their contribution anywhere?
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
The word "clever" has always been a low key insult when coming from me about code, and this describes the reason perfectly.
my acid-test for the code is 'what if we have to add a conceptually incremental feature to this?', apply this and see many of these clever concoctions fall apart.
I spent nearly 27 years at my last job. I must be terrible.
I ran a small, high-functioning team of engineers with over 30 years' experience each, writing advanced image processing pipelines in C++.
When our team was finally disbanded, the person in my team with the least tenure was ten years.
Nowadays, I am "refactoring" myself back to being a full-time coder (as opposed to a manager and part-time coder), and, most likely, a teacher and author.
I'm much more junior that you, but I don't think it necessarily makes someone a "chump" to work at the same company for so long. it might not be what you would do if you optimize solely for lifetime earnings, but there's more to life than that. sounds like the people on your team found a job where they did interesting work with a manager / team lead they respected. I wouldn't be in a hurry to leave that either.
This is a very problematic Ayn Randian bullshit that should not be propagated and spread. Not every culture revolves around a constant race to the top. Outside of a very competitive circle that mostly consists of a few towns in the EU, but mostly small parts of the US, the rest of the world actually has the concept where a programmer or any worker finds a good place and just works there until they retire. That is not a problem. That should not be a problem.
Yes, there are people who will keep amining for their percieved top, but whatever they do, lets not ever take this concept and look at actual human beings that you see in a company and treat them as "Residue". This is behaviour that would place you firmly in the "ignore, only deal with this person if I absolutely have to" category.
I would love to work at the same company until I retire. The problem is that to actually make more money and gain skills you MUST, as a software engineer, hop jobs every 2-3 years. I wish it weren't so, but that's just how it is right now. Add to it the fact that most companies don't care to actually train or retain their talent, and you've just got more incentive to hop.
You are right that it takes luck or very careful strategy to be able to learn multiple fields within programming inside one single company. In my current place, I consider myself very lucky that I got the opportunity to do multiple languages (starting off as TS, to move into C# and backend), and also had the chance to do a (p)React-based ui redesign as well, so that ticks three boxes without having to move around.
But lets not forget that many companies usually do change up web stacks as well, so there might be opportunities every now and then too.
There are plenty of level 9-10's at amazon who didn't move every 2 years. Pay is around $600 - $900K? Someone can correct.
I'm not sure if this is enough for the job hoppers but retention is not terrible (despite the Amazon stories that no one lasts longer than a week and cries at their desk every day).
Not sure if anybody has mentioned this flaw yet, but this supposed "Dead Sea Effect," if real, would rely upon the least-talented engineers being able to accurately asses their own talent level.
"[Dunning-Kruger effect] is related to the cognitive
bias of illusory superiority and comes from the
inability of people to recognize their lack of ability.
Without the self-awareness of metacognition, people
cannot objectively evaluate their competence or
incompetence"
Also, as others have said...
Even if the low-skilled engineers were able to recognize their lack of talent -- which they often cannot -- this "effect" would only hold true, if ever, in a company where folks are actively trying to leave.
The company I work for is a pretty happy place. Whether I am the most talented person there, the least talented, or somewhere inbetween... the reason I'm there has nothing to do with a belief that I won't be able to find equivalent or better work elsewhere.
> Not sure if anybody has mentioned this flaw yet, but this supposed "Dead Sea Effect," if real, would rely upon the least-talented engineers being able to accurately asses their own talent level.
No, it only requires hiring managers from other firms to do so; better alternative prospects is sufficient to explain the effect.
> This is contrary to the well-known Dunning-Kruger effect
No, even if the prior part was wrong, it would be contrary to the popular misperception of D-K, but not the actual D-K effect [0], in which self-assessment is compressed (on both ends) toward somewhere in the third quartile, but still monotonically increasing with actual ability, such that the better people are at something the better they think they are, it's just that the bottom ~2/3 somewhat overestimate where they are in the distribution and the top ~1/3 underestimate it.
But, relevant to the situation at end, since positive self-assessment still increases with ability, even if higher self-assessment with higher real ability was needed to drive the Dead Sea effect, that would be exactly what the D-K research shows exists.
These things always have a grain of truth to them, in that they describe some places some of the time, but I also think there's so many things going on in any given place it's hard to generalize.
A well-run organization will hire the right people, and then foster their development in such a way that they are productive, happy, and grow, and will compensate them sufficiently. If any of those things break down, you can run into any number of problems, and they won't necessarily take the form that seems obvious at first.
I've seen organizations take very competent people and ruin their morale and shunt them into projects that were really detrimental to them getting out, in ways that aren't obvious at the time. Or weird organizational dynamics cause changes over time that make someone look bad in ways that aren't their own fault.
There's just weird things that happen that don't simplify to simple models of "talent that is completely independent of environment and perfectly visible."
Have you ever personally had a long term career in a corporation that somehow managed the escape velocity to actually become something other than typical? i.e. typically toxic and bound to these laws?
I work for myself, but I have quite a few friends who have worked for large companies for 10-20 years.
Some companies just know how to treat their employees well, and they benefit from that.
Yes but only due to near 100% turnover of management and toxic coworkers in a short amount of time. It was weird the day I realized I was essentially working at a different job.
What? You think all employees will inevitably hate working at every company if they stay awhile?
26 replies →
I'm always going to cringe at Twitter's "star" engineers who spend an average of 7 months in each company. HTH do you even understand the product and contribute in that time frame? One of two things needs to be at play:
1. You were brought in to do very specific work (i.e.: migrate something to k8s).
2. You were brought in as a token due to your social media following.
Seriously, how else?
Haha, it typically takes 6 months to get up to speed at a company as everyone has their own set of unique tools and infrastructure. Also at that cadence you are not vesting any stock(1 year cliff?) so that seems very strange. Having worked with high-vis engineers in the past, alot of them seem to be vanity hires, they really don't impact much change and probably stoke the egos of the upper managers/execs much like (prof. slughorn from harry potter), collecting "geniuses".
If it takes 6 month to come to speed for an experienced engineer, I would say you are working with dinosaurs, in a jurassic age company.
6 replies →
if an engineer can't make impact until 6 months later is this engineer even worth hiring? Large organizations typically take longer time to ramp up, but regardless of size I expect to make impact at least to my team within the first month of hiring.
1 reply →
I know one like this and the truth is that he doesn’t bother.
He dramatically improves the processes and code which isn’t domain specific and just leaves the rest a mess.
Improve auth? Yes. Improve finance module? Yes. Build better APIs and SQL queries? Yes.
Fix the problems in the actuarial system for funerals? Nope. That’s when you leave and do it all over again.
They contribute to all the parts not specific to the product but common between many products.
I agree, this seems an extremely self-serving creed for "Twitter devs"
Other companies offer added benefits to retain their valuable talent.
The push among "social media stars" to declare long tenures as a negative is problematic, to say the least.
>1. You were brought in to do very specific work (i.e.: migrate something to k8s).
That's how most work gets broken down though. Just find an entry point and start reading code. Read docs, comments, find dependencies, figure out what needs to change in light of your change.
You shouldn't need deep product and tribal knowledge to make simple changes.
In most places you don't need deep product and tribal knowledge to make small changes. You need deep product an tribal knowledge to know what small change to make. Almost anyone new at a company will have someone else telling them what the first thing they need to do is, and that person is telling you to do something that wasn't important enough for them to do themselves.
For what it's worth, the best interns/juniors I've had started out making simple changes like this. I'd break down the work and parcel it out for them every day until they had accomplished something big. Then I'd start parceling it out less and less until they just knew what they were doing.
Is this really true? Do you have any sources for this? I'm interested in learning more.
As we are just transforming people quotations into laws and effects, let me add mine.
”In a heated market, where it is easier to crack code interviews than to prove yourself a talented and effective IT engineer, the least talented and effective engineers are more likely to leave, to float away, because their employers have less reason to try to keep them. Those who tend to remain are the ones who have more “weight” in the company, as their effectiveness and talent are better evaluated by their colleagues than external audience from conference talks, blog posts, and code interviews”
Soneca
You can call that ”The Gravity Effect”
I've heard this as one of the key justifications for an internship program. Outperformers are likely to be aggressively retained by their first employer, so if you want a fighting chance at landing them, that had better be you.
My general experience, at least in start-ups, has been the exact opposite. In a good company with great culture and good compensation, strong talent was usually in for the long haul, and those who don't find their place leave after a year or so.
In bad companies that's not true of course, so perhaps this can be a good measure of company quality - if their top talent are indeed good and are there for a long period of time, it's a very positive signal.
One example I can think of is Redis Labs - the core group of engineers have been with the company for almost a decade, and these guys are some of the nicest, most humble and most talented engineers I've ever met (And of course there's antirez who's in a league of his own).
I violently agree with you.
The most important thing you can do during a job interview is to as best you can figure out who the talented people are and how long they've been at the company. If the most talented people are the people who have been there the longest, it's a good sign. If the people who have been there the longest don't seem to do any technical work and seem like powerpoint monkeys, it's a dire warning sign that the company is deeply dysfunctional.
In any case, the "Dead Sea Effect" is not a general truth, it's only true in dysfunctional organizations. The author of the linked post seems to be a consultant who helps failing IT organizations turn the ship around. I think his experience has led him to self-select into the dysfunctional ones.
This makes sense.
A good company will appreciate talent, enable it, recognize any lack of it, and create some form of community. So it's a bad place to be a vampire, but a great place to be talented.
A bad company will fail to appreciate or enable talent, not notice vampires, and have no real community. Great place to clock in and get a paycheck, but not very fulfilling.
Talented people tend to be driven by interest at least enough that it's worth it to do things they're interested in.
One way we try to combat this is the way you get salary increases is mainly through promotions. Promotions are based on reasonably solid criteria and you can go up for promotion anytime you want (max every 3 months). Engineers senior to you determine whether or not you meet the criteria in a forum that is loosely based on a thesis defense. you answer questions and show your work and how it demonstrates the skills. People are either learning, executing, or teaching a skill.
People that dont get promoted get very few raises so are incentivized to leave.
The levels are essentially:
1) learning core skills under heavy supervision
2) ability to develop a feature with moderate supervision
3) ability to develop a product as it was envisioned, independently
4) ability to conceptualize a product, kick off a new product, and change direction in the middle if need be
5) ability conceptualize a portfolio of products and how they interface
6) ability to run a business unit of products
7) ability to start your own company (at this point we fund people to start their own company)
There are more detailed criteria around leadership, growing other people, contributing to recruiting, understanding, finance/accounting (P&L), following a solid methodology, contributing to the intellectual property of the company, improving the operations of the company, ability to deal with various level executives outside the company, exhibiting the values, being an expert in something etc
So who maintains the 'legacy code' aka the products your company actually makes money selling?
The ones who don't reach the next level
(This could explain why google has a hard time maintaining their old projects: Google on the resume is so so valuable that whoever doesn't rise within google leaves and gets a rise at another company.)
4 replies →
you can replace product with project and it would still apply.
There is some distinction between being able to kick off projects with existing products and kicking off a totally new product.
most people are working on kicking off updates to existing products.
I too think this depends on how dysfunctional the company is and in what way it is dysfunctional.
Overall, with reasonable management, people have better idea about your skills and abilities after working with you then shortly after interview. Interview is artificial short situation. If that applies, staying makes a lot of sense because you get more challenging tasks, more autonomy, your word is trusted, you have more say in negotiations. Leaving to another company means that you have to start again less trusted, won't get those challenging tasks and generally need to prove yourself before gaining the same back. Plus yoi risk that environment in new company will be more toxic. Changing team is in the middle - you have reputation and sometimes simply need change so that you don't stagnate.
In such organization, pure talkers loose credit over time, get moved from team to team and no one wants to keep them and end up on project they themselves don't want and nobody wants and leave.
Obviously, if the company starts to be dysfunctional over some treshold or stagnates, the high quality people will leave as the above benefits get lost. If it is toxic or unchallenging right now, you are good chance another company will be better.
> Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven’t all gone away! There is a profound lack of professional and institutional memory in IT;
Brooks also used his analysis to give a solution -- which (AFAICT) nobody has ever implemented. The problem isn't lack of 'memory'. His ideas weren't adopted even when they were new. It's amazing that after 45 years we're still pointing to this book as a must-read which correctly explained the problems of our industry, yet managers universally ignore the chapters which explain what to do instead. I don't see that happening in other fields.
> almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.
Good luck with that. Brooks' book is sitting on every manager's desk in the world, and he couldn't get them to read and follow it. Another blog isn't going to help. Things are only going to change when the industry has a "come-to-Jesus moment" -- like if software starts killing people and the government steps in and says "hey maybe you should all be required to adopt NASA's methodologies".
There needs to be some sort of prerequisite to make this valid.
Having been through a number of downturns in my career, you do see really talented people leaving at the worst time possible for the business. But assuming that everyone who leaves is your best talent is not such a good thing to do.
The prerequisite is a lackluster/dysfunctional/toxic work environment, which is probably like 99% of jobs out there.
Is it though?
7 replies →
For people leaving in a downturn that is a reasonable assumption. If the employment market is bad, then mediocre employees have no good options to leave - they might try, but they won't find anything better; but really good techs will have opportunities in any market; well, at least they had in the last 'busts'.
I've seen plenty of people in IT with mediocre skills having no problem at all finding new jobs. I've also seen talented developers stay in the same place for a long time.
I'm much more willing to believe that the quality of engineers at an organisation has more to do with the organisation itself and the sector.
I've noticed that some people hold a grudge against mediocrity that I don't entertain, and yet they don't know what to do with belligerent incompetence and so they try not to think about it, whereas I can't stop thinking about it.
Overqualified people working on a project can produce some heinous code. What I want as a team lead is to know how far I can trust people with different tasks, figure out who can be stretched in what directions, make a stab at scheduling the work out to try to minmax that equation, course correct a few times, observe outcomes and root causes and try to put safety equipment or process in the places where things start to go wrong the most.
You can get a lot of important if boring work done by 'average' or 'below average' developers - as long as they don't suffer from Dunning-Kruger.
Performance is on a bell curve (and not static). If you're trying to run your project like you only have to deal with the top 20%, well guess what, you're still going to have a bell curve. If you're in charge of any strategy and you won't acknowledge this, then you are the biggest idiot in the room, and I don't want to hear your opinions on who the second biggest idiot is.
> Overqualified people working on a project can produce some heinous code
> You can get a lot of important if boring work done by 'average' or 'below average' developers
This is why google developed the go programming language - dumb enough that people can't build overly complex abstractions, but capable enough that average engineers can churn out productive work.
Here, I reversed it and it sounds about as believable to me:
> The "Anti Dead Sea Effect" suggests that in any organisation, the skills/talent/efficacy of engineers is often proportional to their time in the company.
> Typically, lowly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to leave the company, as finding employment elsewhere is not difficult. This is particularly pronounced if they have not gained incremental pay rises over their time in the company, due to their poor skills, as it can be easier to fool someone else to pay them more.
The other side of the coin is salary compression and inversion.
That’s where HR policies dictate that no one will get more than slightly above cost of living raises no matter what while at the same time having to bring new employees in at market rates.
You find a situation where the more tenured employees are getting paid less than new employees with the same skillset but without the corporate understanding.
This varies enormously by the history of the company. I've seen situations where companies are quite stable and very happy to give tiny increases to manage their costs and don't care if they lose engineers because it's not like an individual engineer is actually going to make or break the company. This tends to be true at very large organisations with mature markets. These are the sort of companies that kind of know they aren't going to increase their revenue beyond a certain point so they're focused on reducing costs. A side effect is managers hire in at high salaries because they know the increases won't be big and you end up with a shuffle of slowly inflating everyone's job title. Suddenly you're hiring senior staff out of university.
On the flip side though I've also seen senior (long serving) staff massively overpaid, because they got massive bumper promotions and pay rises during growth periods for the company, and then when things tighten and growth slows, they're still sitting on very generous pay. Particularly in 2010-2015 where staff had got big increases in 2000-2007 but all the new staff had been hired during the recession.
1 reply →
> Typically, lowly skilled engineers find it easy to gain employment elsewhere and are the first to do so
Not really.
I feel like that is a ridiculous generalization.
It can be true to a certain extent in that you may have _some_ engineers who aren't very good sticking around in some organizations. But why would you think that is the case for most of them? You might have engineers deciding to stay because they have a family and think their job is fine.
Or maybe for organizations that have poor leadership or existing engineers, that is the case that the good engineers realize that and leave. But for really good organizations, they are extremely selective in terms of recruiting and compensate employees highly, with difficult but rewarding work, it might be the opposite -- people who weren't really cut out for it are quickly eliminated.
For me personally I eventually came to the conclusion that there was no perfect job, and my plan for personal growth is not to flit from job to job anymore trying to get higher salaries, but rather to save and work on side projects to hopefully eventually have my own business. So for that strategy it doesn't make sense to keep switching jobs.
To all those people throwing doubt on this, you are highlighting a situation where there are a dozen downturns in a career. Better people last longer.
People who switch more often however ladder up on their skill sets. Taking a diverse number of approaches that change from place to place and adapting nicely to them all and maybe even bringing a few skills from elsewhere to help in their current job.
A comfortable job makes you stagnant. Movement is good. Even within company.
Or, as a former boss put it: "the problem with this place is that anyone with 'get up and go' has already got up and gone."
Come to think of it, he was gone too about a month later.
To provide some context on this, Bruce Webster worked mainly as a consultant that triaged projects that have missed their targets. Therefore, his definition of the "Dead Sea Effect" probably comes from his almost exclusive experience with failed projects and ineffective teams.
Source: He taught my software engineering class and this blog post was required reading. I think his "thermocline of truth"[1] is one of his more effective metaphors.
[1]: http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...
This assumes that skill and efficacy don't come from domain specific/company specific experience.
You can be a lousy engineer, but if it is all your lousy code and you know it line by line, you will be a heck of a lot more effective than the star engineer who has been there for just a few months and hasn't learned the codebase yet.
I'm not sure that's true. I've seen incompetent engineers working away to maintain their own "house-of-cards" systems that break easily and take forever to change. Then within a matter of weeks a competent engineer comes in and replaces the whole ball of yarn with something that fast, clean, and doesn't break.
If you know what the house of cards is supposed to do, sure. If not, you can't easily replace it as then you are requirement generating again.
1 reply →
It's a cute anecdote, but I don't think it really illuminates enough or even thinks through the implications of its analogy.
Water evaporates out of the Dead Sea because there is somewhere better (in the sense of lower humidity at least) for it go.
If you treat people as evaporating and disappearing when they leave your company, you'll never have a clear picture if the dynamics at play. You need to think about where they are going and the relative difference between their current environment and the other one they escape too.
When the air holds enough humidity, it rains on the Dead Sea too sometimes.
In an ecological sense, the water level in the Dead Sea is dropping because Israel and Jordan siphon off too much water from the Jordan river for irrigation. By the time the river gets to the Dead Sea, the average flow rate is lower than average evaporation.
There is probably some metaphor in here for having a bad reputation decreasing your hiring funnel.
I think that's primarily true for companies that don't pay their engineers enough. The companies that pay a lot of money obviously don't have problems attracting and retaining talent.
Yeah, the reason some company might experience this effect is because the company is managed in a way that makes people want to leave as soon as they have a chance. The problem isn't the employees.
It's not even simply a matter of pay. Even companies that pay well often have a fair bit of churn.
What often matters is whether one is in a position to develop skills and enhance one's impact on the organization.
Anecdotally, I find the opposite to be true. Also part of being "effective" is having a large amount of system knowledge which you would build over a long time.
The problem with general advice. I would say most engineers take 1-2 years to truly grok the business, internal relationships and the whole of the technology stack you have deployed. So if you’re jumping ship every year or so like I sometimes see recommended you’re not really ever firing on all cylinders. Once you have the big picture and have deployed multiple projects - is when you can start proactively fixing systematic issues that you’ve identified
For engineers, is it ever really worth it to understand the business?
I can see the enormous harm having no technical people who know the domain causes in my current role, but the benefits of learning it seem to be slim to none for the individual engineer. The harm is in low productivity for my employer, but they don't seem to care about retention anyway. Most do not.
1 reply →
The Dead Sea effect is also what you get when people are rewarded for designing a system with unknown performance properties. They get promoted and move onto another project, meanwhile lower level people stay on board and discover all the quirks, oddities, bugs, flaws, shortcomings, etc of the "well designed system", and have to do solid work to keep it running.
Of course, that's all they are viewed as doing - keeping the system running - all the glory was reaped by the evaporated developer who moved onto other teams to make similar mistakes as before(since they weren't around to experience/fix them).
I have seen this a few times. In fact one place I've worked had it so bad that this was entire MO for a "director's pet" engineer. it would not even be a fully functional product but just a proof-of-conceptish hacked together design that demos basic feature with a bunch of shortcuts. this would be just credible enough to take credit of the design and move on. I have even seen him create a bunch of confluence pages with half baked info just so that the claim could be staked.
usually this is accompanied by technically clueless management.
This feels like a gross oversimplification. The last company I left had plenty of brilliant people that I would consider at least as smart and knowledgable as I am. Many are still there. Those people have a lot of influence and credibility within the organization and value those things. Some people stick around because of the maturity of the organization, as they have worked in less stable operations, i.e. lots office politics and backstabbing, and know how bad it can be.
I'm not saying I don't think I'm smart, but my primary motivation was compensation.
Url changed from https://github.com/dwmkerr/hacker-laws#the-dead-sea-effect, which points to this.
Please follow the site guidelines. Note this one: "Please submit the original source. If a post reports on something found on another site, submit the latter."
https://news.ycombinator.com/newsguidelines.html
That's a great resource.
Why is this rule (Dead Sea Effect) chosen for promotion more than all the other ones that list?
It must be because as a representative it can do the least damage (Dilberts Principle) or because... ;)
A corollary is that any open position is more likely to be for a "Dead Sea" employer/team/manager. (more likely than for a non-open position)
Turnover is far higher for bad situations.
Erik Dietrich has a great article expanding on this principle [1].
[1]https://daedtech.com/how-to-keep-your-best-programmers/
EDIT: a comment on that link makes the point one of the best ways to retain great developers is to surround them with other great developers. I think this hits the nail on the head.
Here's a good example of companies and execs min-maxing their human cattle. How about you just do a good job evaluating your employees? If you're happy with them, great, if they need improvement help them. If they're doing a bad job replace them. Stop assuming the personal motivations of other people's lives with your pop-psychology nonsense.
> How about you just do a good job evaluating your employees?
Sadly, bemoaning the capriciousness and unfairness inherent to workplace politics does nothing to diminish the presence of politics in the workplace.
The in-crowd gets the good work, the promotions, the clout, and the money. Everyone else gets to maintain the balls of mud that these people crank out as stepping stones on their way to the next position. Certainly a state of affairs which is appropriate to bemoan! And then when you're done bemoaning, you can either ride the train or get run over by it, your call.
You can say the fancy guys, the "10x engineers", the "thought leaders", the people posting on Twitter all the time aren't the real, true engineers, because they don't stick around to see their efforts through. And maybe you'd even be right about that in a lot of cases. But somehow that notion doesn't seem to bother those people very much...
This is something I've been mulling over for such a long time and want to resist simple answers.
But this phenomenon seems to hold true no matter the organization: A new hire for position or level X with Y years of experience will ALWAYS have a higher salary than a veteran at that organization with level X and experience Y, for Y > ~2yrs.
How is "talented" defined here?
Some people bounce around to different companies. They are never necessarily productive in the roles they are constantly leaving. They may be only "talented" at being hired.
On the other side of the coin, the author defines the "residue" as "the least talented and effective IT engineers... that tend to be grateful they have a job and make fewer demands on management" and "tend to entrench themselves, becoming maintenance experts on critical systems".
Aren't these so-called "residue" people at least demonstrably "talented"? They are providing value to the company by maintaining things that actually make the business money without grumbling about it.
As others have mentioned, this is entirely dependent on the organization. The issue is that talented people hit a ceiling faster than anyone else. Organizations aim for stability, and that will usually come at the cost of stifling top performers.
Businesses have their growth cycles, and ambitious people are attracted to growth. Many times, they will ride the growth wave of a company until its crest, then catch a wave at a different company.
I have personally never encountered a company that had an adequate mechanism for retaining these kinds of people, and maybe they shouldn't. As long as they don't burn bridges, maybe they will come back and work on a future project.
Is a nice catchy phrase, but not a good model
It fits a certain segment of organizations quite well, but it's not universal.
The principle would be just nice if it were true, but it has different assumptions that don't hold in quite many situations.
To me, it appears it presumes almost something like Santa Claus existing world, where "everybody gets what he deserves" (where you "evaporate" to some place better for you) which isn't how typically the world functions.
Moreover the concept of "talent" is involved in the principle, which is not something that I would use as the name of the property that I would use for selection of people who'd work on some project.
Yeah, I can't help but detect some wishful thinking on the part of the author. If you're asserting some principle, there ought to be an objective way to validate it - so, how do you know? If it's really true that "the best people will always leave", they'll leave the next employer after they left you. So, the best people are definitionally the people who never keep any job for any appreciable amount of time? How could you possibly measure their contribution anywhere?
This one is amazing: https://github.com/dwmkerr/hacker-laws#kernighans-law
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
The word "clever" has always been a low key insult when coming from me about code, and this describes the reason perfectly.
my acid-test for the code is 'what if we have to add a conceptually incremental feature to this?', apply this and see many of these clever concoctions fall apart.
I guess this is about me.
I spent nearly 27 years at my last job. I must be terrible.
I ran a small, high-functioning team of engineers with over 30 years' experience each, writing advanced image processing pipelines in C++.
When our team was finally disbanded, the person in my team with the least tenure was ten years.
Nowadays, I am "refactoring" myself back to being a full-time coder (as opposed to a manager and part-time coder), and, most likely, a teacher and author.
I'm much more junior that you, but I don't think it necessarily makes someone a "chump" to work at the same company for so long. it might not be what you would do if you optimize solely for lifetime earnings, but there's more to life than that. sounds like the people on your team found a job where they did interesting work with a manager / team lead they respected. I wouldn't be in a hurry to leave that either.
Here is the direct url to the "Dead Sea Effect":
https://github.com/dwmkerr/hacker-laws/blob/master/README.md...
This is a very problematic Ayn Randian bullshit that should not be propagated and spread. Not every culture revolves around a constant race to the top. Outside of a very competitive circle that mostly consists of a few towns in the EU, but mostly small parts of the US, the rest of the world actually has the concept where a programmer or any worker finds a good place and just works there until they retire. That is not a problem. That should not be a problem.
Yes, there are people who will keep amining for their percieved top, but whatever they do, lets not ever take this concept and look at actual human beings that you see in a company and treat them as "Residue". This is behaviour that would place you firmly in the "ignore, only deal with this person if I absolutely have to" category.
I would love to work at the same company until I retire. The problem is that to actually make more money and gain skills you MUST, as a software engineer, hop jobs every 2-3 years. I wish it weren't so, but that's just how it is right now. Add to it the fact that most companies don't care to actually train or retain their talent, and you've just got more incentive to hop.
You are right that it takes luck or very careful strategy to be able to learn multiple fields within programming inside one single company. In my current place, I consider myself very lucky that I got the opportunity to do multiple languages (starting off as TS, to move into C# and backend), and also had the chance to do a (p)React-based ui redesign as well, so that ticks three boxes without having to move around.
But lets not forget that many companies usually do change up web stacks as well, so there might be opportunities every now and then too.
There are plenty of level 9-10's at amazon who didn't move every 2 years. Pay is around $600 - $900K? Someone can correct.
I'm not sure if this is enough for the job hoppers but retention is not terrible (despite the Amazon stories that no one lasts longer than a week and cries at their desk every day).
one exception: people too autistic to have the connections needed for finding new jobs, especially outside of SV.
I wish it were the case
Good to see Hofstadter's Law in there.
Not sure if anybody has mentioned this flaw yet, but this supposed "Dead Sea Effect," if real, would rely upon the least-talented engineers being able to accurately asses their own talent level.
This is contrary to the well-known Dunning-Kruger effect which, unlike the "Dead Sea Effect", has at least been backed by some studies: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Also, as others have said...
Even if the low-skilled engineers were able to recognize their lack of talent -- which they often cannot -- this "effect" would only hold true, if ever, in a company where folks are actively trying to leave.
The company I work for is a pretty happy place. Whether I am the most talented person there, the least talented, or somewhere inbetween... the reason I'm there has nothing to do with a belief that I won't be able to find equivalent or better work elsewhere.
> Not sure if anybody has mentioned this flaw yet, but this supposed "Dead Sea Effect," if real, would rely upon the least-talented engineers being able to accurately asses their own talent level.
No, it only requires hiring managers from other firms to do so; better alternative prospects is sufficient to explain the effect.
> This is contrary to the well-known Dunning-Kruger effect
No, even if the prior part was wrong, it would be contrary to the popular misperception of D-K, but not the actual D-K effect [0], in which self-assessment is compressed (on both ends) toward somewhere in the third quartile, but still monotonically increasing with actual ability, such that the better people are at something the better they think they are, it's just that the bottom ~2/3 somewhat overestimate where they are in the distribution and the top ~1/3 underestimate it.
But, relevant to the situation at end, since positive self-assessment still increases with ability, even if higher self-assessment with higher real ability was needed to drive the Dead Sea effect, that would be exactly what the D-K research shows exists.
[0] https://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-...