Is it Truly All about Age?

Scott Francis
Next Post
Previous Post
TechCrunch and Vivek Wadhwa have a controversial article up about Age-ism in high-tech in the US.  TechCrunch is no stranger to controversy, having also just caused a bit of a stir around systemic gender bias in the venture-funded tech startup business. Vivek makes a few key points. Paraphrasing, High Tech companies prefer younger workers because:
  1. They are cheaper (salary, benefits, insurance, etc).
  2. They have fewer competing interests (lower percentage are married with kids)
  3. They are perceived to be easier to mold (into culture fit)
  4. They are perceived to be “more current” on whatever the latest technologies are
  5. They can be trained up on new tech more cost-effectively than older workers
I’ve certainly seen this logic play out, but more in the 90’s than today.  I see a lot of pressure from small companies to hire someone who already knows the technology in question, not someone who still has a lot to learn.  I see a lot of companies hiring someone with an existing track record.  Hiring a college recruit is a multi-year, long-term investment – which a lot of startups aren’t ready to make.  But perhaps things are a bit different in the Valley than in Austin.  Perhaps there, the pressures are more like the pressure to offshore: get the cheapest labor inputs you can get.  Certainly, one way to do that without the pain of offshoring, is to hire less experienced (or less costly) talent. In fact, in another article, it was predicted that labor (or jobs) will migrate to less expensive parts of the US (this seems logical, over time, if other parts of the country prepare people with the right skills). My observations about experienced hires (I won’t say older) in the same order as above:
  1. Usually (but not always) much shorter ramp-up time from day 0 to first fully independently productive day.
  2. The competing interests are also balancing interests – keeping more experienced team members balanced emotionally, more so than some less experienced hires.  They have other positive things going on in their lives which allow them to pursue work with confidence, rather than fear of failure.
  3. Whether easier to mold or not, it is easier to judge what an experienced hire’s real work values are – and to find people who already align with your values, rather than trying to mold (some might say brainwash) less experienced hires.
  4. Often more experienced hires are actually more current on the new tech than students, because it takes quite some time for educational institutions to switch gears.  I remember distinctly Stanford University rolling out its C++ computer science classes (intro classes), just as Java was about to hit the scene.  It was several years before Stanford switched the curriculum to start with Java, though they did start offering a class in Java right away.  It was many years before we could hire people with Java skills learned in college that were more than trivial.
  5. This last point is true, if you assume ramp-up time is equal, and that the less experienced worker is cheaper than the more experienced hire. However, as I pointed out in my comment on TechCrunch, I have come to believe that learning itself is a skill, which can be practiced and improved over time.
We run a services business at BP3, so it isn’t apples to apples comparison with the TechCrunch article, but there are a few more things that we note about our firm when we talk to candidates.  First, our business requires a lot of travel for nearly everyone on our team.  That is easier to accommodate when you’re single (it may even be a benefit) than when you have a family.  And while it may be true that younger or less-experienced people are more likely to be single, it really has to do with family vs. no family.  Because our firm is run by people with families, we take our commitment to make our job sustainable for our families *very* seriously.  Second, if we’re going to pay for experience, we want that experience to be relevant to our specific business – that of BPM.  I’ve had conversations with people who have previously made considerable salaries, and are interested in switching to focus on BPM – but they don’t know the BPM space yet, or the specific technologies we use to support BPM.  I tell those folks that they can’t expect to switch into BPM and not have a hit to salary in the short-term.  But I believe that is true for any career change -when you switch specialties, your compensation takes a (hopefully short term) hit.  If it is a good long-term change,  compensation will catch up to and surpass the old compensation at some point, but more importantly, the career change will breathe new life into working.

Tags:

  • Anonymous

    Hi Scott,

    High-Tech is too large an area to generalise.
    In our BPM industry, I would break it down into roles:
    • Programmers – I would agree with Vivek.
    • BAs, EAs – I would disagree. Here experience talks.

    The magic words here are rework and delivery.
    Young programmers, as long as they have an experienced PM watching over them – will delivery faster, cheaper (well.. maybe just cheaper..).
    The amount of rework depends on how eagle-eyed the project managers are.

    BAs and EAs usually have less eyes looking into their work.
    Their mistakes will not only cause a lot of rework, but can stop the project in its tracks.
    “easier to mold”, “conflicting interests” , “most current” are all things that cross every employer’s mind, but the decision is usually made based on cost, rework and delivery.

    Cheers,
    Adam

    • I think Vivek’s post is largely about “hightech” as defined by prevailing tech industry in the valley – EE and Software. So, programmers and engineers. I think he was implicitly excluding non-technical roles in his consideration.

      I think the basic problem is this: Companies measure cost in terms of per-unit-of-labor. But the meaningful measure is cost-per-unit-of-output. The problem: unit of output is difficult to quantify, by comparison.

      The opportunity: if you are a business hiring people, if you evaluate your hires (and team) based on cost per unit output, you’re using a better measure than your competition (by and large) and are likely to reap the rewards. This is how we’ve attempted to evaluate our hires and team, though I freely admit our approach has some gross generalizations built-in.

      I haven’t found the experienced PM as important to young programmer productivity as the experienced programmer. Programming is still, by and large, a craft more than science or engineering. Crafts get passed down from person to person more than they are learned from reading tomes by experts that have gone before.