Stories about Software


How To Keep Your Best Programmers

Getting Philosophical

Given that I’ve just changed jobs, it isn’t entirely surprising that I’ve had a lot of conversations recently about why I decided to do so. Generally when someone leaves a job, coworkers, managers, HR personnel, friends, and family are all interested in knowing why. Personally, I tend to give unsatisfying answers to this question, such as, “I wanted a better opportunity for career advancement,” or, “I just thought it was time for a change.” This is the corporate equivalent of “it’s not you–it’s me.” When I give this sort of answer, I’m not being diplomatic or evasive. I give the answer because I don’t really know, exactly.

Don’t get me wrong. There are always organizational gripes or annoyances anywhere you go (or depart from), and it’s always possible that someone will come along and say, “How would you like to make twice as much money doing the coolest work imaginable while working from home in your pajamas?” or that your current employer will say, “We’re going to halve your pay, force you to do horrible grunt work, and send you to Antarctica to do it.” It is certainly possible that I could have a specific reason for leaving, but that seems more the exception than the rule.

As a general practice, I like to examine my own motivations for things that I do. I think this is a good check to make sure that I’m being rational rather than impulsive or childish. So I applied this practice to my decision to move on and the result is the following post. Please note that this is a foreword explaining what got me thinking along these lines, and I generalized my opinion on my situation to the larger pool of software developers. That is, I’m not intending to say, “I’m the best and here’s how someone can keep me.” I consider my own programming talent level irrelevant to the post and prefer to think of myself as a competent and productive developer, distinguished by enthusiasm for learning and pride in my work. I don’t view myself as a “rock star,” and I generally view such prima donna self-evaluation to be counterproductive and silly.

What Others Think

Some of my favorite blog posts that I’ve read in the last several years focus on the subject of developer turnover, and I think that these provide an excellent backdrop for this subject. The oldest one that I’ll list, by Bruce Webster, is called “The Wetware Crisis: the Dead Sea Effect,” and it coins an excellent term for a phenomenon with which we’re all probably vaguely aware on either a conscious or subconscious level. The “Dead Sea Effect” is a description of some organizations’ tendency to be so focused on retention that they inadvertently retain mediocre talent while driving better talent away:

…what happens is that the more talented and effective IT engineers are the ones most likely to leave — to evaporate, if you will. They are the ones least likely to put up with the frequent stupidities and workplace problems that plague large organizations; they are also the ones most likely to have other opportunities that they can readily move to.

What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers. They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.

Bruce describes a paradigm in which the reason for talented people leaving will frequently be that they are tired of less talented people in positions of relative (and by default) authority telling them to do things–things that are “frequent stupidities.” There is an actual inversion of the pecking order found in meritocracies, and this leads to a dysfunctional situation that the talented either avoid or else look to escape as quickly as possible.

Bruce’s post was largely an organizational perspective; he talked about why a lot of organizations wind up with an entrenched group of mediocre senior developers, principals, and managers without touching much on the motivation for the talented to leave beyond the “frequent stupidities” comment. Alex Papadimoulis from the Daily WTF elaborates on the motivation of the talented to leave:

In virtually every job, there is a peak in the overall value (the ratio of productivity to cost) that an employee brings to his company. I call this the Value Apex.

On the first minute of the first day, an employee’s value is effectively zero. As that employee becomes acquainted with his new environment and begins to apply his skills and past experiences, his value quickly grows. This growth continues exponentially while the employee masters the business domain and shares his ideas with coworkers and management.

However, once an employee shares all of his external knowledge, learns all that there is to know about the business, and applies all of his past experiences, the growth stops. That employee, in that particular job, has become all that he can be. He has reached the value apex.

If that employee continues to work in the same job, his value will start to decline. What was once “fresh new ideas that we can’t implement today” become “the same old boring suggestions that we’re never going to do”. Prior solutions to similar problems are greeted with “yeah, we worked on that project, too” or simply dismissed as “that was five years ago, and we’ve all heard the story.” This leads towards a loss of self actualization which ends up chipping away at motivation.

Skilled developers understand this. Crossing the value apex often triggers an innate “probably time for me to move on” feeling and, after a while, leads towards inevitable resentment and an overall dislike of the job. Nothing – not even a team of on-site masseuses – can assuage this loss.

On the other hand, the unskilled tend to have a slightly different curve: Value Convergence. They eventually settle into a position of mediocrity and stay there indefinitely. The only reason their value does not decrease is because the vast amount of institutional knowledge they hoard and create.

This is a little more nuanced and interesting than the simple meritocracy inversion causing the departure of skilled developers. Alex’s explanation suggests that top programmers are only happy in jobs that provide value to them and jobs to which they provide increasing value. The best and brightest not only want to grow but also to feel that they are increasingly useful and valuable–indicative, I believe, of pride in one’s work.

In an article written a few years later titled “Bored People Quit,” Michael Lopp argues that boredom is the precursor to developers leaving:

As I’ve reflected on the regrettable departures of folks I’ve managed, hindsight allows me to point to the moment the person changed. Whether it was a detected subtle change or an outright declaration of their boredom, there was a clear sign that the work sitting in front of them was no longer interesting. And I ignored my observation. I assumed it was insignificant. He’s having a bad day. I assumed things would just get better. In reality, the boredom was a seed. What was “I’m bored” grew roots and became “I’m bored and why isn’t anyone doing anything about it?” and sprouted “I’m bored, I told my boss, and he… did nothing,” and finally bloomed into “I don’t want to work at a place where they don’t care if I’m bored.”

I think of boredom as a clock. Every second that someone on my team is bored, a second passes on this clock. After some aggregated amount of seconds that varies for every person, they look at the time, throw up their arms, and quit.

This theme of motivation focuses more on Alex’s “value provided to the employee” than “value that employee provides,” but it could certainly be argued that it includes both. Boredom implies that the developer gets little out of the task and that the perceived value that he or she is providing is low. But, beyond “value apex” considerations, bored developers have the more mundane problem of not being engaged or enjoying their work on a day to day basis.

What’s the Common Thread?

I’m going to discount obvious reasons for leaving, such as hostile work environment, below-market pay, reduction of benefits/salary, etc., as no-brainers and focus on things that drive talented developers away. So far, we’ve seen some very compelling words from a handful of people that roughly outline three motivations for departure:

  • Frustration with the inversion of meritocracy (“organization stupidities”)
  • Diminishing returns in mutual value of the work between programmer and organization
  • Simple boredom

To this list I’m going to add a few more things that were either implied in the articles above or that I’ve experienced myself or heard from coworkers:

  • Perception that current project is futile/destined for failure accompanied by organizational powerlessness to stop it
  • Lack of a mentor or anyone from whom much learning was possible
  • Promotions a matter of time rather than merit
  • No obvious path to advancement
  • Fear of being pigeon-holed into unmarketable technology
  • Red-tape organizational bureaucracy mutes positive impact that anyone can have
  • Lack of creative freedom and creative control (aka “micromanaging”)
  • Basic philosophical differences with majority of coworkers

Looking at this list, a number of these are specific instances of the points made by Bruce, Alex and Michael, so they aren’t necessarily advancements of the topic per se, though you might nod along with them and want to add some of your own to the list (and if you have some you want to add, feel free to comment). But where things get a little more interesting is that pretty much all of them, including the ones from the linked articles, fall into a desire for autonomy, mastery, or purpose. For some background, check out this video from RSA Animate. The video is great watching, but if you haven’t the time, the gist of it is that humans are not motivated economically toward self-actualization (as widely believed) but are instead driven by these three motivating factors: the desire to control one’s own work, the desire to get better at things, and the desire to work toward some goal beyond showing up for 40 hours per week and collecting a paycheck.

Frustration with organizational stupidity is usually the result of a lack of autonomy and the perception of no discernible purpose. Alex’s value apex is reached when mastery and purpose wane as motivations, and boredom with a job can quite certainly result from a lack of any of the three RSA needs being met. But rather than sum up the symptoms with these three motivating factors, I’m going to roll it all into one. You can keep your good developers by making sure they have a compelling narrative as employees.

Guaranteeing the Narrative

Bad or mediocre developers are those who are generally resigned or checked out. They often have no desire for mastery, no sense of purpose, and no interest in autonomy because they’ve given up on those things as real possibilities and have essentially struck a bad economic bargain with the organization, pay amount notwithstanding. That is, they give up on self-actualization in exchange for a company paying a mortgage, a few car payments, and a set of utilities for them. I’ve heard a friend of mine call this “golden handcuffs.” They have a pre-defined narrative at work: “I work for this company because repo-men will eventually show up if I don’t.” These aren’t necessarily bad or unproductive employees, but they’re pretty unlikely to be your best and brightest, and you can be assured that they will tend to put forth the minimum amount of effort necessary to hold up their end of the bad bargain.

These workers are easy to keep because that is their default state of affairs. Going out and finding another job is not the minimum effort required to pay the bills, so they won’t do it. They are Bruce’s “residue” and they will tend to stick around and earn obligatory promotions and pay increases by default, and, unchecked, they will eventually sabotage the RSA needs of other, newer developers on the team and thus either convert them or drive them off. The narrative that you offer them is, “Stick around, and every five years we’ll give you a promotion and a silver-plated watch.” They take it, considering the promotion and the watch to be gravy.

But when you offer that same narrative to ambitious, passionate, and talented developers, they leave. They grow bored, and bored people quit. They refuse to tolerate that organizational stupidity, and they evaporate. They look for “up or out,” and, realizing that “out” is much quicker and more appealing, they change their narrative on their own to “So long, suckers!”

You need to offer your talented developers a more appealing narrative if you want them to stay. Make sure that you take them aside and reaffirm that narrative to them frequently. And make sure the narrative is deterministic in that their own actions allow them to move toward one of the goals. Here are some narratives that might keep developers around:

  • “If you implement feature X on or ahead of schedule, we will promote you.”
  • “With the work that we’re giving you over the next few months, you’re going to become the foremost NoSQL expert in our organization.”
  • “We recognize that you have a lot of respect for Bob’s Ruby work, so we’re putting you on a project with him to serve as your mentor so that you can learn from him and get to his level.”
  • “We’re building an accounting package that’s critical to our business, and you are going to be solely responsible for the security and logging portions of it.”
  • “If your work on project Y keeps going well, we’re going to allow you to choose your next assignment based on which language you’re most interested in using/learning.”

Notice that these narratives all appeal to autonomy/mastery/purpose in various ways. Rather than dangling financial or power incentives in front of the developers, the incentives are all things like career advancement/recognition, increased autonomy, opportunities to learn and practice new things, the feeling of satisfaction you get from knowing that your work matters, etc.

And once you’ve given them some narratives, ask them what they want their own to be. In other words, “we’ll give you more responsibility for doing a good job” is a good narrative, but it may not be the one that the developer in question envisions. It may not always be possible to give the person exactly what he or she wants, but at least knowing what it is may lead to attractive compromises or alternate ideas. A new team member who says, “I want to be the department’s principal architect” may have his head in the clouds a bit, but you might be able to find a small, one-man project and say, “start by architecting this and we’ll take it from there.”

At any point, both you and the developers on your team should know their narratives. This ensures that they aren’t just periodic, feel-good measures–Michael’s “diving saves”–but constant points of job satisfaction and purpose. The developers’ employment is a constant journey that’s going somewhere, rather than a Sisyphean situation where they’re running out the clock until retirement. With this approach, you might even find that you can coax a narrative out of some “residue” employees and reignite some interest and productivity. Or perhaps defining a narrative will lead you both to realize that they are “residue” because they’ve been miscast in the first place and there are more suitable things than programming they could be doing.


The narratives that you define may not be perfect, but they’ll at least be a start. Don’t omit them, don’t let them atrophy and, whatever you do, don’t let an inverted meritocracy–the “residue”–interfere with the narrative of a rising star or top performer. That will catapult your group into a vicious feedback loop. Work on the narratives with the developers and refine them over the course of time. Get feedback on how the narratives are progressing and update them as needed.

Alex thinks that departure from organizations is inevitable, and that may be true, but I don’t know that I fully agree. I think that as long as talented employees have a narrative and some aspirations, their value apex need not level off. This is especially true at, say, consulting firms where new domains and ad-hoc organization models are the norm rather than the exception. But what I would take from Alex’s post is the perhaps radical idea that it is okay if the talented developer narrative doesn’t necessarily involve the company in five or ten years. That’s fine. It allows for replacement planning and general, mutual growth. Whatever the narrative may be, mark progress toward it, refine it, and make sure that your developers are working with and toward autonomy, mastery, and purpose.


Edit: For anyone interested, there is an E-Book of the (edited for E-Book format) contents of this post. This is the publisher’s website, which has links to all of the book stores in which it appears. Or, here are links to it for Amazon, Barnes and Noble, and iTunes. The price is the lowest one for each store, which is $0.99 in all but iTunes, where it’s free.

  • Bruce Webster

    Great post, and I’m not just saying that because you linked to one of mine. 🙂 I also think that Alex’s post is very important, because it defines a professional arc at a given company that is important but often unconscious. Let me add a few more explicit factors that affect why good developers stay or leave:

    — Education/conferences. Good (and great) developers want to stay current with the technologies they use and to learn new ones as they emerge. An unwise company one will refuse, saying, “That will just make them more valuable and then they’ll be hired away!” That has it exactly wrong: good developers will often leave in order to gain that education elsewhere, but they’ll stick around if they know they have a regular educational benefit of some kind, and they become a source of new ideas and technologies within the organization.

    — The little things. In doing a software startup in San Diego some 20 years ago, I worked very hard — first by myself, then (once we could hire him) with our outstanding VP of Engineering, Jim Hamerley — to keep engineer turnover to a minimum. We didn’t have the lavish, over-the-top perks you often hear about in Silicon Valley (and which I think are silly), but we did have free and unlimited sodas, M&Ms, and peanuts in the kitchen, and if three or more engineers were working during the evening, they could order takeout/deliver dinner, and the company would pay for it. During the all-too-long stretch between getting funding and finally shipping our first product, our CFO — John Curry, also an outstanding professional and excellent at his craft — kept eying cutting out those expenses as a way to save a bit of money. I understood his motivations but argued (successfully) that that the financial gains from such cuts would be wiped out many times over by just one engineer leaving.

    — Tying individual goals to team goals to company goals. I don’t know where I got this idea from — probably from Weinberg or DeMarco & Lister, or perhaps Sun Tzu; I’m pretty sure it didn’t originate with me — but at that same startup, I did a engineering team offsite where I had everyone answer the questions, “Why are you here? What do you hope to get out of working here?” We then talked about what the startup’s goals were, i.e., what it needed to do to be successful. Finally, we crafted a set of team goals that bridged the gap — that is, they encompassed our collective individual goals in a way that supported the startup’s goals. The result is that we as a team were working to achieve each team member’s individual goals in a way that would help the company as a whole to succeed.

    For what it’s worth. ..bruce..

    • Hi Bruce,

      I’ve always enjoyed the Dead Sea Effect post and I’m glad you stopped by for a comment here. Thanks for the additional points for keeping developers around. I’ve never personally encountered a company that would actively block learning, but that would definitely kick the job search into high gear for me. I’m definitely appreciative of perks like sodas and lunches and other such things — it conveys that the company is willing to invest in you in the same way that a flex schedule conveys a willingness to treat you like an adult. And tying company goals to individual goals is huge for me. That brings the “purpose” and “autonomy” motivations directly in line with one another while recognizing that some kind of pure altruistic motive (“I’m just in it for the love of the company”) is unrealistic.

      You raise some excellent points here.

    • Matthew Skelton

      Bruce, I think you’re spot on in relation to Education. Building up a common, shared sense of learning and development produces its own rewards. In particular, it allows talented staff to’put their head above water’ and see what other folks are doing, thereby avoid getting too dragged down by the day-to-day difficulties of the particular toolset or implementation they are working on. Having regular report-back sessions from training and conferences helps to spread not just the knowledge itself but also the ethos or mindset around learning and self-development.
      The ‘engineering’ blogs run by Twitter, Google, Netflix, LinkedIn (and most other big players) also have a good motivating effect in my experience (I ran such a blog at my previous employment), especially if staff can post articles under their own name.
      The Marshall Model is relevant here: http://flowchainsensei.wordpress.com/rightshifting/the-marshall-model/

  • Really great article! I had quit my job a few months back in favor of an opportunity that would allow me to grow professionally. A friend, and former co-worker, is still working for my previous employer. I fear he is slipping into the “collecting a paycheck” mindset, and would like to see him muster up the motivation to find something better.

    • Hi Charles — thanks for the kind words. I’d say that in my experience, your friend’s situation is not terminal from a career perspective. I think a lot of people sort of mentally check out for a while and then leave, rather than becoming permanent “residue”. Hopefully your friend is in that camp.

  • As a web developer who recently left a 14 year position with the same company, I wish you had written this a year ago. I loved my work but not my job. I probably hit my “value apex” a couple of years before I left but was determined to stick it out — bored or not.

    Unfortunately, my last straw was the “organizational stupidities” that you mentioned. My previous boss encouraged (and rewarded) my quirkiness so I stuck around. Once that person and feeling of acceptance was gone, so was I.

    I’m starting my own company and if I decided to expand (just me now), I will take your article to heart. Not only is it good advice for developers, but every employee. People want to feel they are making a difference, not just a body in a chair.

    • I’m glad you enjoyed the post, and I’m glad that you got out of a situation that had past its expiration date. Just the fact that your own personal narrative includes your own business (autonomy) and possible expansion (purpose) makes it sound as though your current situation is a happier one. I have to imagine that you’ll pass that on to anyone working for you – just as the “residue” seems to beget more “residue”, people with ambition and purpose seem to do the same.

    • I have to point out that there are lots of jobs that are truly a body in a chair. This is unskilled labor, by definition. To fail to acknowledge that and treat every position as if it’s mission critical is much surer to lead to failure than the converse.

      • Jack Pines

        I have met unskilled laborers who have taken their job with great pride, feeling a sense of purpose in fulfilling roles so much of our society takes for granted. Perhaps it’s the being taken for granted, not the menial-ity of the work, which makes such jobs “bodies in a chair”. The work must be done so appreciating that the work is being done and helping that person build their own narrative, in or out of that chair, is where a manager (and most of us in just being grateful) can help.

  • Guest

    Amazing post, I feel this will hit home with many developers out there, great job.

  • Mark Smith

    I’d have to admit Erik, I have a Love/Hate feel towards this post. I love the post, and I hate the events leading up to you writing this post.

    I think the post as a whole means a lot to me personally since as you know it wasn’t that long ago that I switched positions and realized a lot of these things were missing from my career before then. Unfortunately, the events leading to this post also left me with the feeling that the other half of the things you mentioned are still missing from my career. Hopefully as time passes, I’ll learn to fill those holes myself and be able to keep the self motivation regardless of my surroundings.

    Best of luck to you in your new endeavors!

    • Perhaps jobs are like houses over the course of your life. Each time you move, you get 5 or 6 new things that you didn’t have before, giving up the odd thing here and there in the switch. But the overall arc is that you collect nice things while not leaving too many behind. I imagine that you’ll find yourself in situations with fewer and fewer “holes” as time goes on. Here’s hoping, anyway.

  • Great post Erik, you make some excellent points. A large part of my job is recruiting and retaining developers. Over the years, I’ve learned two important things about that:

    1. There are many reasons not to hire bad (or even mediocre) devs, but one of the most important ones is that they almost never leave voluntarily. They’re fine doing whatever as long as it produces a paycheck.

    2. It’s hard to keep good devs. Money doesn’t really work, nor do the perks. One of the few things that seems to work is being surrounded by other great devs. This is especially effective because very few places actually have that type of team.

    • Being surrounded by good developers is an interesting perk and one I didn’t really consider when posting. I think that this certainly helps with both mastery and purpose, since you will naturally feel some positive pressure to improve and the group will probably do impressive things. And, you might be willing to trade autonomy for that, at least temporarily (or you might hit the trifecta and not need to).

    • Alex, does this mean you would rather hire a developer that is currently employed. I just changed positions and had to answer lots of awkward questions about why I want to leave my current position. You are trying not to say anything bad about your current employer because you don’t want to come off as someone that doesn’t get along with anyone yet you are hoping to “evaporate” into a better position.

      • RKrieg

        You don’t have to say anything bad in order to clarify why you’re leaving, if you really do get along with your current team. I left a job with a bunch of fine folks that I respected and enjoyed working with, and had no problem talking about them positively in an interview with potential employers…but could still make it clear that I wanted to work with newer technologies and with a management team that was experienced with modern software development methods. That played nicely with whoever I talked to because it showed respect for the things they did well, and also made it clear that I was looking for a good fit, not desperately seeking any job I could find just so I could get out of where I was.

  • Sandro Mancuso

    Very good post. Really enjoyed reading. You captured really well the situation of many companies, expressed how passionate and talented developers feel about their jobs and what they expect from employers. Well done.

    • Thanks for the kind words and for reading — I’m glad you enjoyed the post.

  • Pingback: How To Keep Your Best Programmers | DaedTech | Petr Zaparka()

  • Pingback: The Man-Month vs. the Human Narrative | I must follow, if I can()

  • Pingback: The Perils of Free Time at Work | DaedTech()

  • Pingback: How Developers Stop Learning: Rise of the Expert Beginner | DaedTech()

  • I would agree that working in an apprentice role with senior devs is part of mastery, but when those senior devs don’t want to mentor the more jr devs, or are too busy with fire drills because “no one else knows how to fix it”, it creates almost a class system within the organization, and you start to see resentment by those that aren’t included to work on the more interesting projects.

    • That’s a great point about the idea of a class system created by busy-ness. It’s the same system that makes it somehow a status symbol to be late for meetings or to skip certain activities, which I think is an element of a culture trending toward the destructive. I’ve always kind of tended to be of the philosophy that really top notch developers with a lot of years and leadership under their belts develop a knack for making others more productive. They’re not putting out fires because they’re working ahead of time with junior team members to prevent them.

  • It is entirely the organization’s fault if a developer ever reaches their value apex for any reason except they’ve reached their fundamental capacity of growth. That capacity is finite for some people. (Also excluding if the developer just gives up for external from work reasons)

    • Often, there just isn’t a position for the developer to move into, or the developer’s goals don’t match the organization’s timeline. It’s still the organization’s fault, but at the same time, there’s no avoiding the conflict of interest.

      In these cases, if the developer were to leave, then the organization loses someone with useful/developed skills and knowledge and they have to backfill the role, so they get hurt. In the case where there is no room for growth, it’s in the organization’s best interest to encourage the developer to maintain a holding position, because if a developer is interested in improvement and the organization can’t support that goal, it’s in the organization’s best interest to never tell the developer.

  • Mike

    All good stuff, qorth noting that it ain’t no different in other careers, people doing “job type x” could equally be the subject, it’s their emotional side you are appealing to (or not, in the case of a poor employer) and that’s consistent across a culture not a profession, probably Western culture in this case. Might be different in other cultures though…

  • Pingback: A Blog Grows Up: DaedTech Year in Review for 2012 | DaedTech()

  • Pingback: Programming | Annotary()

  • cbroome

    Great post, I’d only add that in the world of small teams and small to midsized companies “promotion” may not apply as elsewhere. As typically stated it tends to mean assuming more management-orientated responsibilities. Some developers may want to transition to management, but it’s a totally different skill set. That aside, it’s fairly easy to reach “senior” status, many earn the distinction by 30. Afterwards, there’s not really any other title to strive for.

    This is fairly unique to developers and reflected in wages. Developers tend to max out in earnings relatively soon in their careers. I believe my case is not atypical: my pay doubled within five years of entering the industry, with nominal raises since. Other industries typically see a gradual incline in payroll that maxes out after decades of service.

    Similar to this, as small companies grow larger in terms of expanding the workforce, tenured developers who never moved to management often find more and more layers of management and process stacking over them, changing and diminishing their earned role in the organization.

    • They pay arc of the developer who doesn’t want to get out of development is an interesting point. I suppose that I’ve usually heard this referred to as the “architect track” and talented developers on this track would have a narrative that takes them to architect and then, really, probably out of companies on off on their own as self-employed consultants or experts in the field.

      But “out of the company” is unusually high-risk and many will avoid that simply because it may not make sense within the context of one’s financial obligations. It’d be nice if our industry could reach a point where there was a track for this that didn’t max out at a “line” position.

      • So then you went and wrote a post about this particular nuance two years later: http://www.daedtech.com/programmer-is-a-career-path-thank-you

        • Nice to see I maintained some consistency of position, particularly given that I didn’t have any recollection of this particular exchange when writing that recent post.

      • fishsquad

        I remember coming across a conversation on Twitter not too long ago where a game developer was lamenting his decision to stay or leave at the game company he was working at. He saw the choice as a dichotomy. While he said he really loved the company and loved the stability of pay, what he really dreamed of was working on his own game, yet felt that he couldn’t make it on his own (perhaps “make it” in the sense of developing it on his own, but not “make it” in the sense of survive without the stability the company provided). However he expressed fear and dread at the prospects of staying at the company for another 6 months to a year without any sense of autonomy or growth.

        What if the company knew how he felt and instead of seeing him either wilt in the position or risk losing him to striking out on his own, they offered him some kind of third option, like using the company as an incubator to develop his game, or giving him a flexible schedule where he could spend a portion of his time at home working on his game, in exchange for a share of any possible revenue, or IP, or co-ownership of tools developed in the process.

        It seems like if a company were to see a situation like that as either a downward spiral for the developer that could potentially infect the other devs (e.g. Dead Sea Effect) or permanently losing a good dev (which could still lead to a Dead Sea Effect), then coming up with a third option, like you say, a track that doesn’t max out, would instead allow the developer to continue doing what they love to do, while still maintaining a relationship with the company. It would almost be the exact opposite of the Dead Sea Effect. It would be more like a vibrant marsh.

        • This is exactly the kind of thing I’d love to see companies do. I’m of the strong opinion that the professional trajectory of developers is going to be similar to doctors or lawyers, which is going to mean that the “we own you from 9 to 5” relationship with companies is going to become less and less relevant.

          I’d much rather see companies *partner* with developers than try to employ them.

  • Ash

    This is a truly incredible article and pretty much explains how I feel with words I could never conjure up myself. The list of reasons is spot on, I can relate to everything so well, the meaningless job title, the lack of education, the unstoppable chain of pointless and repetitive work and the watching of the world move on in terms of technology and methodology whilst being shackled by the chains of incompetent seniors who prevent any form of free thinking, research and investigation, let alone actual advancement.

    I think you’ve hit the nail on the head by mentioning that the boredom can be from the lack of growth and change, and when a good developer reaches their value apex they certainly will look either onwards or upwards.

    This helps me solidify my reasons for leaving, now knowing that it’s not childish or rash, but a mere natural human tendency to strive towards progression.

    Thank you.

    • Glad if the post helped you feel better or at least provided a sort of “I’m not alone” feeling. The pay-your-dues corporate culture that’s ubiquitous in society makes you feel like an oddball if you think anything other than, “I should count myself lucky to have a job.” I just think we can do better than that.

  • Jack Pines

    I think this article hits home in any career field. More managers of people need to understand the motivations of their people and if they want excellence (and not all managers do, many being of the “it’s a paycheck” mentality themselves) then they will help build a winning narrative.

    • I think the parenthetical point is a sad, but important one to realize. Unfortunately, there are going to be some managers that take the short-view and are not willing to make a good faith effort to assist in career development for their reports. Hopefully that’s a minority, but it’s definitely worth pointing out because not all situations are ‘fixable’ so to speak.

  • Pingback: Most interesting links of April ’13 « The Holy Java()

  • Boyzl

    regarding workers who don’t leave – there are 2 sorts of them:

    #1. those who are paid enough regarding their contribution and work

    #2. those who work and contribute good enough regarding their wage

    …all other have already left or are in search for a new job right now!

    • Boyzl

      ps: payment & wage not meaning just real cashflow but all other means of “payment” too, including opportunities to learn, selfeducate, etc

    • I agree with point (1), but with (2) I’d say this is only true of the pathologically honest. I think most people (especially the people who wind up being “Dead Sea” types) are willing to collect a wage, if a company will offer it, that exceeds the worth of their contributions. In a mercenary sense, that’s actually a great deal, so it’s economically rational of them to do this. And this is one of the key premises of the post — that companies tend to overvalue contributions from people based on the length of their tenure.

      • Boyzl

        sorry to correct you – with #2 I meant another aspect (opposite of yours) of meaning of my statement: people who are underpayed and don’t give their most but work “just good enough” not to be fired. they tend to minimize their contribution until they feel reaching THE critical point with working as less as possible and yet not to be fired asap. (I hate those most, though in fact they are not to be blamed, leaders are to blame ’cause they don’t get the point).

        but from our point of view (positive one) you’re of course right too.

        • Oh, I see. I certainly agree with your point then. Unmarketable people who feel slighted because they are paid too little (in their estimation) will certainly look to minimize their contributions.

  • larrybud

    I look at it in much more simple terms. One’s head can only be banged against the wall so many times. Once that limit is met, it’s time to move on.

    • I think from a programmer’s perspective, that’s certainly true and probably the most common case for leaving earlier than one might. But I think they’ll also leave even if there hasn’t been too much banging of heads against a wall, but rather just simple boredom or stagnation too.

  • Metro

    Some weeks ago, my struggling company offered a generous buyout to the first 100 employees accepting to leave the company of free will. I know that my management did not ever read one of the articles refered to above, because within 3 days the best and youngest coders and project managers were all gone, increasing our companys average employees age by 10 years.

    This is one sure way how to loose your best programmers.

    • Wow. That might be one of the most pure, unadulterated examples of the so-called “Law of Unintended Consequences” I’ve ever heard of. That policy seems like it could easily be the answer to the question “how can we get our most marketable, in-demand people to leave?”

  • Pingback: 如何留住你最好的程序员 at Book & Man()

  • Pingback: The Best Programmers | Voice of the DBA()

  • Pingback: A moment of reflection ← Grokee()

  • Dan

    There’s something I feel needs mentioning here: narratives need to be genuine and honest and this has to come from both sides (both the employer and the employee).

    Some employers come to some form of “narrative strategy” intuitively or fail to use it “correctly”: two employers ended up sending me on wild goose chases to keep me motivated. You can imagine my reaction upon finding out that the amazing new module or functionality I was tasked with was never meant to be delivered in the final product: while I was somewhat amused by the fact that they opted to pay me for “nothing”, that feeling was soon replaced by darker thoughts and it wasn’t long before I filed in my four weeks’ notice.

    • That’s an excellent point. If the narrative is phony or manufactured, that should be a surefire sign that the employment/work arrangement doesn’t actually make sense. With the demand for developers being what it is, having to create make-work tasks to tide some of them over and stave off boredom seems like a sign of deep organizational incompetence.

  • Pingback: Links – October 2013 | Ninad's Blog()

  • zakret

    Oh man. Thank you for this article. It changed my life.

    • Glad if you liked! (I hope it changed your life in a good way)

  • Pingback: Managing Startups: Best Blog Posts of 2013 | njdrmtrade.com()

  • This article came out at a time when I was going through some heavy soul-searching of my own. I will always be grateful for the service it provided in helping to synthesize my decision tree in addition to validating my narrative.

    • Glad to hear it. This is one of the more reflective posts that I’ve ever written, so it was pleasing to me that it resonated with people. It’s nice to give voice to something that extends beyond your own experience.

  • Jaycee

    My solution to this has been contract work. I join an organisation for 6 months or a year or two, get to largely ignore corporate politics, I’m able to put up a fight for what’s right because I’m not dependant on promotion **, then when the project finishes I move on to another role.
    I spent many years as a programmer, but now do technical design or “applications architect” roles, helping dev teams put together a well designed (I like to dream…) solution which we build out.
    For the notional uncertainty of contract work I get paid more than market, which is nice.
    ** In my current role the dev team needed technical training, and I told the project manager the project would crash and burn if they didn’t get it. He replied that it was against corporate policy, but there was money in the project budget and if that was my recommendation he’d push it through – and he did.

  • Furiant

    Forwarded this to my boss, who is trying to figure out how to attract and retain higher quality developers. Unfortunately, our agency exhibits every single issue you listed, and is not willing to solicit feedback from any actual developers. It’s time for me to move on, but maybe this article will help them improve in the future, if for no other reason than that it was written by someone who isn’t me.

    • I hope it has the effect you’re seeking, but in my travels, that’s been somewhat rare. Companies that are failing hard at developer retention these days seem to be the ones that remain stuck in the “people are lucky to have a good job” mindset. They’ll forever stand around, scratching their heads and wondering how they’re so unlucky when it comes to hiring ‘loyal’ people.

      Glad to hear you’re on to bigger and better things 🙂

  • Sander

    Wow, when I read the “narratives that might keep devs around” I got a warm fuzzy feeling inside. Damn, I’ll frame those somewhere, they are so true! Sadly I’m only confronted with items from the first list, two top devs have already left and more might evaporate.

    • I’m not normally accused of giving people warm, fuzzy feelings with my writing, but I’ll take it 🙂 Sorry to hear about the current situation, but here’s hoping it improves or you wind up in greener pastures. I said on twitter a while back that life is too short for crappy projects — you only get a finite amount of codebases to work on in your life, so make ’em count!

  • FracktyFrakFrak

    I’m glad there is a name for this. I almost left my current organization because of this. Under my former manager, I saw the one of the least skilled people in our group become our lead and made a point to tell rest of us that he was our boss. I reached a point that I was so bored with my work and completely uninspired with our leadership that I told former manger that I was bored with what I was doing and open to learning new technologies to keep things fresh. Of course nothing was done. Thankfully, the head of our IT department realized that we had a very poor manager and that manager “resigned”. When our new manager came in, I wasn’t sure about him, but thought to give him sometime before I resigned my position. After a few month, our new manager made a point to tell us that our team lead was not our boss and is only acting as a point of contact for other departments. He also gave me a new project that involved learning three new languages and a pretty nice raise outside of my review raise. I think he realized I was very close to leaving and did what was necessary to remedy it. For now I’m happy again with our organization.

    • That’s a nice success story to hear and one that is all too rare in the industry. In my time managing software developers, I lived in perpetual paranoia that the good ones were going to bolt, knowing how easy it is. Sounds like you wound up with a manager that had a similar outlook, and it’s good to hear that the manager set about keeping you happy. And that’s not just random populist, feel-good stuff, either. Knowledge workers contribute FAR more value when they’re challenged and engaged. Micromanagement and the kind of fire-hydrant peeing your old “tech lead” subjected you to absolutely destroy team productivity.

  • Evelyn Milani

    Wow, great article- In my role, I interview tech talent every day and I agree with several key points here. People “peak the summit” in the value apex both value they bring and the value they receive and things get boring. Good info for CEO’s and Dev Managers to take to heart.

    • Glad you found it helpful! Feel free to use it as you see fit, per your message over LinkedIn. I’m always happy for the eyeballs on the page.

  • Like many others i like this post (and your posts in general, read a few now and will read more.)

    Many of the reasons you list as reasons to quit are ones I consider as well when I evaluate my position. Motivation is a large factor and a feeling that you are evolving as a programmer. I don’t just want to be more competent in some speciality but I want to improve as a developer and if there are things that the team I work with don’t know enough about, we need to have the spirit of exploration, there needs to be a will to discover the new technology or whatever it is rather than a fear of the unfamiliar.

    I would like to add a thing to the list though. For me, development is by people for people. There are a few who can develop only for machines, but the projects I like to work with need to be used by people for me to find them interesting. Consequently one of the most important things for me is not to do harm to the users. If the development team or the ones making the decisions don’t share my sympathy for the user I suffer and in the end will start looking elsewhere for a job opportunity. Often it is bad practices in development that lead to bad software so it is very much a quality thing.

    • Hi Antero, thanks for the kind worlds, and I’m glad you like the post.

      There’s been a lot of elapsed time since I wrote this, but it strikes me that what you’re talking about here could be construed as a subset of the “purpose” motivation. In your case, the purpose has to involve helping the users of the software that you’re building…? Is that fair?

      • More or less. I mean it in a general sense that whatever I develop, I don’t want it to be a cause for discomfort. It was important enough to develop so it must be important enough to do right.

        Not hearing “I get that error again” from customer service is also a form of praise.

        Pushing boring repetitive tasks to others because “your time is too valuable” is also an energy drainer, especially on those occasions where it can be easily improved.

        I want to do better.