Why some of the best developers keep quitting
fastcompany.com
fastcompany.com
I can only assume that right now the best developers are vastly underpaid relative to their worth. Why? Because it turns out every time they get annoyed with their current company they can send out some feelers and get a 20% raise. Most people can't do that. Most teachers can't just quit and get a 20% raise yearly. Do this a few times and ultimately you realize that your intrinsic value didn't really increase 1.2^3 (72%) over the last 3 jobs, it's just that companies were always willing to pay more if they needed to, but (if you were being honest about current salary) only in increments of 20%.
If they were willing to pay more, you were worth it.
There are very very few companies that exist right now that give you crappy work but top notch comp for that work. For those companies, there is not a "huge retention problem", it's just a normal-sized retention problem where in addition to paying their developers based on value they also try to ensure they get to mix things up a bit and enjoy a conference or two.
Most companies don't want to pay for retention. It's pretty sad that most companies can't make staying at their current company more attractive than the risk of starting a new job with a team/company that's unknown.
But many companies, the companies with that 20% greener grass, are willing to give a complete stranger a 20% raise.
"The irony ... the irony ..."
Here's the key, a lot of managers are too afraid, confrontation averse, or short sighted to make a fight for their employee.
There are cases where there isn't even a competition for funds. All you need to do is ask for a raise and it passes through without any problems, managers just don't do it because they are too afraid of even making that very request.
That being said, I've always been able to get _SOME_ money for retention, but I've not always been able to get enough. If they go interview somewhere else and their current salary is $120K, it's entirely conceivable they could be getting an offer of $160 with a bonus structure that's better.
I've even encouraged employees to leave before when it sounded like they were going to get put into a position for growth that we couldn't offer. If they're already feeling stifled or short changed enough to go looking, any move you do to keep them now is just delaying the inevitable. If I let someone leave with a clear conscience, that's someone who could come back to the company even better than they left (it's happened a surprising amount of times in my career). It's also someone who can help me and/or my company in the future, whenever our paths may cross again.
I have followed managers to companies and I've had employees follow me to companies. If you just adhere to the damn golden rule things are a lot easier for everyone involved.
They do not fight for their people, they get work and outcome from them to achieve the company objectives.
Most probably they are right if they consider who will give them their next career opportunity.
I'll venture to say this: Not every project knows how to produce long term value, and not every shop is a good long term steward of value. This is a big factor in retention, in part because it's correlated with meaningful work.
There is excessive profit taking at all levels including the IC level, however market dynamics actually create greater and greater differences in wealth despite the trickle down.
Note that, although managers may wish to throw money around because it's not theirs, shareholders view every penny spent on salaries as an expense that eats into their profits. They have an incentive to insist on lower employee salaries whenever possible, and they're typically the ones who make the rules in most firms.
Also, if situations like that could exist, you wouldn't only see them in the US.
Who do you think knew more about compensation at Apple, Steve Jobs, or the random employee? Or perhaps your argument is Steve Jobs was just lying?
But to claim that, there would be a vast conspiracy tobtake all of that money on a wide enough scale to make everyone in the USA overpaid is where the thing breaks down.
People quit because the modern, zero-loyalty, everyone-for-hire company does not provide a long term strategy for providing intrinsic motivation (autonomy, mastery, purpose); they don't want to pay for retention and therefore don't provide perks for retention.
Until this changes, it should never surprise a manager why churn is high and average tenure is less than 2 years. If you are a manager (especially middle management - meaning you don't have the scope to make massive, company-wide cultural changes), it's best to look at your directs as someone to help them advance for their next job. I know that sounds counterintuitive, but if you lead with transparency on the landscape, you build authenticity and trust with your directs, which will go much further for your relationship while you are working together.
Rands refers to this as your "shields down" moment.
I think the default state should be you being happy, fullfilled and well compensated in your job. And if you take a better offer somewhere else, it's not because you 'dropped your shield', it's because you're looking out for your own interests.
Managing Humans / Being Geek are also great books if you like this type of writing. I've shared them with lots of new managers/engineers and they've always been well received.
The "shield" is just your day-to-day (sometimes minute-to-minute) SELF-evaluation of your current job satisfaction and willingness to leave. It has nothing to do with you being shielded from anything by anyone else.
To pull another quote:
"If I’m sitting here talking with you it means two things: I don’t want you to leave and, to the best of my knowledge, you didn’t want to leave either but here you are leaving."
Calling this mode "shields up" implicitly means that it's something good for you, protecting you - but it's not quite so, this "shield" is protecting the company/manager instead of you. The exact same thing might be called not "shields up" but "complacent mode" or "ignoring opportunity" for the opposite implied evaluation.
I'm happy to say this is my manager's position. I joined this team nearly 2 years ago mainly on the strength of a great discussion with him during the interview process, and our team is clearly excellent thanks to him, with significant investment in growth, responsibility and empowerment (I know they're buzzwords but ick, I don't know how better to say it).
(Just want to stem the tide of inevitable gripes that are going to show up)
A) takes my ideas seriously even if she doesn't see the end game. Just says go for it and see what happens.
B) comes up with trainings and stuff that match my role that she can send me on.
C) holds me to a high standard without being a jerk about it.
I will be bummed to leave and stop learning from this person's example. I'm taking a hit financially but I've come a really long way. So I'm being reaaaal slow in the job hunt. I know when I'm in a good work environment, and I might not find that. At the next job.
As a manager myself, I will go out of my way to retain a good employee. Our wages are low (nonprofit) but we can be very flexible to the needs of an employee. Diligent, dedicated people who care about doing a good job are worth their weight in gold.
People quit because the modern, zero-loyalty, everyone-for-hire company does not provide a long term strategy for providing intrinsic motivation (autonomy, mastery, purpose); they don't want to pay for retention and therefore don't provide perks for retention.
Another belief I hold: most people want to be told what to do.. to a certain degree. That's the trick.
The political way of phrasing this is that leadership also has to be balanced. Too much results in predictability and people getting bored. Too little results in people feeling lost.
https://aeon.co/essays/how-work-changed-to-make-us-all-passi...
If a developer comes to me with a new idea, and it sounds viable, then I give them a bonus based on how well it executes. Everyone is incentivised and motivated to come up with new exciting projects.
Smart developers want to create, so set them free! Autonomy, mastery, purpose = productive and happy
This is much better advice than the whole article.
The article seems to be conveying vaguely that developers want advancement, interesting problems, etc. The problem with this phrasing is that it makes a manager think about placation strategies.
The root cause of the above is just poor tasking. If a senior developer says things need attention and keeps getting ignored, then how senior is the developer, really?
The advancement, engagement, product ownership, etc. all grow from a culture where strategic technical priorities aren't ultimately valued.
This looks like boredom or angst about "career progression" but you don't solve the problem by adding whiz-bang tech (gratuitous ML) or meaningless job titles.
The people with any standards at all only stay ~2 years or less at a place like this.
I meant that as part of professional development, technical leaders should have increasing say over the tasking of themselves and the team they're helping lead. There's lots of room to innovate and experiment on exactly how that works.
I'm thinking on the level of:
- If we haven't deprecated these old machines in 18 months, we're wasting piles of money
- This legacy code is too complex, but it will take some time to remove, so we need to start now
- Given the revenue numbers and the amount of maintenance effort we put into it, this part of the system and these features need to be removed. Let's split off a scrum of three for about a month to do it.
Another nice upside of this approach is it helps re-enforce a culture of doing the right thing because we ship and don't just write code.
You have to know your people, and give them support that motivates them. But that takes (gasp!) good managers.
My gut is that it goes the other way around. People who desire to work on the Big Cool Sexy New are often less motivated by peers, and more by personal drive, as by definition most of their peers won't know what the hell BCSN even is. Unless the person in question is working in a 100% BCSN shop, in which case there's likely to be fewer maintenance tasks in the first place as the codebase will be fresher.
For some developers (including me), working on projects with significant business value is the definition of glamorous. Since there's significant business value, then you should be rewarding people for delivering that value (with bonuses and raises).
If the task does not have significant business value, it's probably not actually important. A lot of maintenance tasks actually fall in this bucket.
I want to work on what's most important for the business and our users. Having engineers pick whatever they find fun to work on sounds broken, but I'm also interested in if and how that can be made to work.
Companies tend to try everything except the obvious: more money.
It might not work for everyone or every team, but it sometimes works for me.
Also I find it better to deploy juniors to glamorous tasks wherever possible. They benefit from the glamour to become self sufficient non-juniors.
Lying, witholding information, lack of communication, faking the cool manager just to show the atmosphere is open etc., how many should I still count?
So, the role of sw dev has to deal not only with the fact that it's not anymore about writing algorithms/data structure/rewriting the OS from scratch (which are super cool things to do), but ... also to deal with some incompetent people who under normal circumstances would not do certain things, but in the real world they are pushed from all sides and therefore behave quite bad. This is the reality I have seen so far, just because people don't take their own role seriously, tend to delegate as much as they can, etc. A lot like politics where nobody is really to blame, which creates a lot of frustration and people change "flags" quickly.
Companies seem to want loyalty but they don't want to give it. This leads to the merc approach of just selling to the highest bidder.
Often time's it's not actually about the money. But the low pay (relatively) is a signal to the developer of how much / little you value them.
The people that say this simply rationalize it differently than people willing to say it is about the money. (but yes, there is a group where it really isn't about money)
There is a large segment of the population that feels a stigma for admitting monetary motivation, so if its not "ALL" about the money, where all possible factors are money, they will say it isn't.
People that don't feel a stigma around admitting monetary motivation will reveal that money is a factor if it is at least 1 of the factors. It will be misinterpreted by the other population as being only about the money, whether it is or isn't.
It is just a form of conditioning that will distort any survey for now.
I happily admitted if someone offered me %30+ more money I would think hard about leaving. I remember telling my boss that exact thing at the time and he understood. The honesty is one of the reasons I enjoyed the job.
Quitting generally has more to do with:
A) "You (the employer) Waited Until The Exit Interview To Ask What’s Wrong"
B) "You (the employee) Waited Until The Exit Interview To Convey What's Wrong"
Leaving my last job, I told them what I wanted 1-2 years before I actually left (for more money, but that wasn't the primary cause). The CEO basically told me in the exit interview if it was about money, he'd give me another 30% to get me to stay (and they had countered with that before, back when I told them what I needed to stay long term).
Money isn't necessarily the cause. Its the lack of willingness to communicate and meet the other person's needs.
This can come from two reasons:
1. The company doesn't have sufficiently valuable projects to capture the developer's potential. There are a lot of companies which simply don't need very senior developers and hence cannot match the price for a senior developer on the open market.
2. The company perceives developers as second-class relative to management or their core business leaders. Thus, they can never have developers paid more than those core people.
These companies see a very consistent talent pool of mediocre developers (who have been mediocre for a long time) and junior developers who come in and leave after 1-2 years once they realize they can get more elsewhere.
Work less, get out and do fun things more.
So? That's pretty irrelevant since any good developer job in the US comes with excellent health coverage.
Health insurance being so culturally tied to "employment" is ... very problematic.
Good luck finding a senior developer for £70k over there.
You should be able to find remote work that pays £50k+ relatively easily. Although the whole Brexit thing may make that harder. :\
To me, £70k was more a geographic / economic area issue. Under $50k/£50k you just have to get out.
Most people aren't primarily motivated by money once they are making a full salary as a developer.
PTO, Work/Life Balance, and Geography are more relevant to my life choices than how much I'm paid (to a point, certain areas I've noticed don't pay enough).
https://ycharts.com/companies/GOOG/profit_margin
Alphabet was running a 13.55% margin for its latest quarter.
https://ycharts.com/companies/WMT/profit_margin
Walmart was at a 2.59% profit margin for its latest quarter.
Which of these companies do you think are providing better PTO, Work/Life Balance, etc.?
The reality is intangibles mean more to developers than another 10% salary bump once they are making $150k.
Ah, if it were only that easy. You fight your way through a half-dozen interviews, get an offer, negotiate until you just want to lay down and die, make it through the six-month ramp-up for the new environment, and then you're bored again. Lather, rinse, repeat, until you realize that laying on the sofa in your underoos is more satisfying than the bestest employer.
I'm interviewing for two jobs now.
* Insufficient raises. This is by far the most common reason, but it's been discussed in this thread well already so there's no need for me to dive into details here.
* Over-rewarding of managers and under-rewarding of developers. Very rarely are the management tracks and technical tracks actually equivalent. For instance, managers are granted extra power in the organization and can often grant themselves special perks like private offices.
* In the same vein, under-investing in developer workspaces. Toss me at random into a chaotic open floorplan and you're going to get very little loyalty from me. Show me that you care and are willing to do the best you can to provide me with a productive workspace and I might think twice about leaving, because I don't want to give up an employer who cares for another who'll just toss me into another open playpen.
* Shoehorning someone into a single role or project for years on end. Almost nobody wants to work on the exact same thing for more than a few years unless it's genuinely super interesting. And your projects are probably not super interesting.
That's a really, really tough problem actually. Businesses naturally want people to work on things that they are already very good at, to keep productivity high.
This is especially important in software consulting houses that churn out apps and whatnot without their own products, because their whole business scales only by the factor between the hourly price customers will pay for their work and the salary the developers are getting for that said work.
Which is not to say that I wouldn't agree with your point. It's just that I can also see how painfully expensive not going that route could (i.e. shoehorning) become for such a company, so I'm kind of sympathetic to their apparent reasoning behind it.
I did put it on the bottom of my list though because I think lots of folks will actually tolerate being shoehorned if the employer doesn't make any of the other mistakes listed.
I do not understand team sizes of 50+ for some web app product. The formula only requires a few (3) workhorses that make up a collaboration of skills in product design and engineering, and finding ways to keep them curious. Add a junior position if a workhorse is keen on mentorship.
Why take on such high risk with a large team?
But you still gotta pay off your tech debt or it all goes to hell quickly and then you're hiring like mad because changing anything is a herculean task and management is like "just hire more people and get it done faster!"
It has been a fairly decent indicator of how enjoyable I've found working those particular roles.
They may get surprised when you turn the table around, just remind them that interviews go both ways.
Perhaps I should re-phrase it to "most knowledgable person in the room", since there will always be a lot of new things to learn when switching jobs.
That's because while being the dumbest lets you learn from people, it can also breed complacency. You've always got someone better to pass the buck to. You can easily end up relying on better coders to do the hard jobs, and not learn new stuff as a result.
Being the smartest means the buck stops with you. You need to learn anything you don't understand, or the site never gets done at all. It can be a big learning experience in its own way.
So my recommendation would be to have at least one job where you're the dumbest and least one where you're the smartest. They're two different situations experts need to be able to cope with.
I don't imagine people up the chai hear when good ideas are back-burnered too long or technical debt is ignored.
For sure that's what's happened with me. We are a small company of ~10 people. We're meant to have a review with the CEO every 3 months, it's been over 6 months since I've had one, despite my constant reminders to the CEO, he keeps fobbing me off.
He's also managed to dodge giving my a payrise, despite having worked in total for 15 months, and still having the same pay that I did when I started as an intern. It took me until about 3 months ago to realise I was getting fucked hard.
In fact, not only is your job to provide company with a product of your labor, but it also is a job of the management to provide you what you want and need (interesting tasks, a path for long-term development).
Let me repeat again, it's not a privilege to ask for this, they HAVE to do this.
But seriously, open office is the devil incarnate. I don't see how it can foster communication, unless you think communication is to distract some people, so some other people can look like they're doing something.
Can you elaborate?
Also: You Fired The Employee When He Told You What's Wrong
Lots of companies have stories about a few 'genius' developers who wrote the core of a system, and then left.
That's because it's more fun to develop something from scratch, than to deal with the maintenance of that system later on.
Rather than stick around and attend bug tracking meetings that go on forever, many of us quit to move on to the next cool project.
Well-designed systems may eventually grow into something monstrously unpleasant, not because it's "fun" to shit all over the pristine design specs but because it's most pragmatic.
1. Usually if you've demonstrated success for two years, you can move upwards more rapidly switching companies (up to a point).
2. You've gotten past your vesting cliff, and - particularly with early stage companies - you want to diversify your ISO holdings in the hope of getting a 100xer.
As you say, there can be exceptions, but it's generally a big red flag and a sign that someone is overpaid and arrogant to boot.
I left a job voluntarily and they sent me an online quiz.
I can't imagine I'd make the same decision had the company's code base not been worthy of consideration for an exhibit in a museum.
There's too much opportunity to deal with any B.S. no matter the money you are paying me...ok id deal with some if it paid $250k and the govt took zero.
I'm freelancing now. How about yourself and what was your situation?
Back on point, here are a few other reasons:
- You give them no ownership over what they do, and do not encourage them to show initiative,
- You berate them for operating outside of a narrowly defined range of responsibilities,
- You spoon-feed poorly defined requirements to them,
- You isolate them from the customer and give them only second-hand information,
- You are excessively directive,
- You take a view that is excessively narrowed by an overly limited definition of what is the highest priority,
- You hamper them with bureaucratic processes that make it hard to get anything done,
- You continually break up their day with meetings and other interruptions making it hard to focus,
- Your meetings are undisciplined and run over,
- Your solution to any problem is to book a 60 minute meeting with no notice whatsoever,
- Your teams are too big, turning meetings into a long-winded and exhausting drama with everyone feeling they have to contribute and jockeying for position within some invisible hierarchy,
- You shut peoples' contributions and ideas down,
- When people spot problems there is no time or room in the backlog to fix them,
- Your agile ceremonies are bloated and tiresome, and your stand-ups are long,
- There is a constant need to engage in politics, especially if you want to be promoted or get a pay rise,
- The work is boring,
- It is necessary to build solutions for which other, viable, and considerably better/safer/more secure off the shelf solutions exist because of your aging systems/bad processes/excessive siloing,
- Many stakeholders and departmental siloing leaves developers trapped in the middle battling to reconcile conflicting viewpoints to reach a viable solution,
- Your teams are forced to operate in a way that is largely reactive,
- You manage by mob and/or by flapping and flailing around,
- At every meeting there is AV drama because everyone is using WebEx or some other crappy VOIP solution that leads to 5 - 10 minutes of buggering around for every single meeting,
- Cross-cutting concerns lead to even larger and more unwieldy meetings due to conflicting requirements across departments,
- The general atmosphere is conflict driven rather than cooperative,
- (Some of) your best developers are introverts yet you continually force them to engage in processes and practices that favour extroverts.
- Your office is a noisy and distracting zoo in which it is hard to concentrate.
I could go on (and on) but I'm beginning to depress even myself.