Too Old for IT

I have a terrible admission to make. It's not some terrible crime in my past, nor non-standard sexual orientation, not a question about my sanity or health. I am, all things considered, a fairly typical person. My awful, devastating secret is this:

I am 53 years old.

I am too old for IT.

The Spectre of Ageism

There are professions where there being a bar for age makes sense. By your early twenties, you are in your prime - you will be at your strongest, you will have the most energy, you recover most easily from injury. When Cal Ripkin retired from the Baltimore Orioles in 2001, he was one of the oldest people playing baseball. He was 41 at the time. He'd been in one of the most "age-resistant" positions, that of shortstop, where the primary damage to players is at the knees.

This is true for sports in general, and almost as true in entertainment. Forty seems to be the magic age where an actor moves from being "action star" to "character actor". For women the tipping point is even earlier - roles for women dry up rapidly for women as young as 36, and by fifty, most women who are still working in front of the camera are now in the character actor graveyard which is often far less lucrative than the roles available at 28. There's some pressure on Hollywood (and elsewhere) to create movies and shows targeted to older viewers, but in the calculus of Hollywood, women in their forties are more likely to go to a movie that will entertain their kids (if they have them) than go to one to entertain herself, and economic numbers (couple with two kids = 3.3 adult tickets compared to two for a husband and wife) mean that it is still more profitable to create the more juvenile fare.

In the field of information technology, such ageism bubbles just under the surface. It takes, on average, about six years to train a programmer so that they are truly productive in the dominant technologies, four of which are in college with a two-year "internship" period where developers are typically thrown on smaller projects to get up to speed. Most developers hit their peak optimal period around the age of twenty-eight - they will have typically learned two or even three computer languages to a comfortable degree of fluency, they have learned basic design patterns, and they usually have achieved a specialization.

Moreover, programmers, as a rule, tend to marry later as well, in their late twenties or early thirties, and as such are less likely to have the need for higher salaries - they have no kids, their primary debt comes in the form of student loans, they can work when and where they want to with few constraints, so any excess income they make typically tends to get spent on luxury items that may be above their means later. Put another way - young workers may be inexperienced, but they are cheap, and are usually good enough for most basic needs.

The equation shifts after these workers start a family. Gone is flexibility. For men, young family means reduced hours and less energy (anyone who has to deal with a colicky baby at 3am will not be at their best during the day), and once they get into school then schedules tend to revolve around school schedules, so commitments become longer (and summer tends to be the primary time for moving). For women, the impact is much greater, as they will be out of the work force for at least six months and possibly for years - to the extent that the bias against women in the workforce in IT is in many respects even more restrictive than it is for ingenues in Hollywood, because most IT companies are nervous that a woman in her twenties or thirties who becomes an effective programmer will show up one day and announce that she is pregnant.

Computer languages and technologies change constantly, and even the same languages may undergo radical upgrades in the space of a few years. Javascript code written today would be nearly unrecognizable to someone who was a Javascript coder a decade ago. As a rule of thumb, it takes three months of time to regain proficiency in a language for ever year that you are away from it, so being sidelined for a couple of years means that it will be six months before you're back up to speed - and you will be competing with twenty-somethings who are not laboring under that catch-up factor.

Yes, you have more experience in general - someone who's been coding for twenty years has a vastly larger repertoire of experiences to pull from about the art of programming than someone out of college - but for most hiring managers who are not themselves programmers, that difference is far from obvious: you either know X or you don't.

Ageism, the Economy and the SDLC

This becomes especially problematic when software life-cycles and economic activity intersect. Software development follows a clear life-cycle (often known as the SDLC) - requirements are gathered, the product is green-lighted, software is designed, then implemented, then tested. The product is disseminated and the software goes into maintenance mode until a new version is required (if ever). Architects and sales engineers dominate the first phase (design) of this, developers, devOps and testers the second phase (development), and maintenance engineers the third. Even with agile methodologies, it takes about eighteen months to go from inception to deployment.life-cycle - requirements are gathered, the product is green-lighted, software is designed, then implemented, then tested. Even with agile methodologies, it takes about eighteen months to go from inception to deployment.

There is a quasi-cycle in the economy that also controls how software development takes place. After a recession has peaked, you get a few companies that start exploring whether there is enough pent up demand to create new software. If there is, then you get early hiring (mainly of contractors) and software design begins. This begets more companies doing the same, until the surplus pool of developers begin to tighten as demand for specialized skills. Architects tend to be busy from the beginning, but developers and devops are usually brought on only once design has reached a point of rough completion.

For a while, you have full employment. A company may end up doing two or even three different software projects, though typically the later projects often tend to be lower priority and require fewer resources, so you end up with more developers doing "makework". The economy peaks, demand noticeably slackens, and profit vs. payroll slides dramatically. Layoffs begin and snowball, as projects all begun at more or less the same time now end at more or less the same time. This cycle takes about 7 1/2 to 8 1/2 years, and it will then be eighteen months between the time of layoffs to the start of rehiring.

This pattern has persisted since the 1960s. It means that the average developer will be out of the workforce between 20% and 30% of their career. During the off cycle, they will be living off of savings, trying to anticipate and retrain in the latest and greatest, and if they are smart, developing new software of their own.

Developers who are with a company for a while are usually eventually tapped to become IT management. The closest analog to an IT manager is a sergeant or petty officer in the military. IT managers generally do not have formal management training, nor are they sales people (the personality traits that make for a good programmer tend to make for abysmal sales people, and vice versa). Within all but the most technical of organizations, they are not considered "management track".

CIOs and CTOs correspond to chiefs and master sergeants. Within the IT ranks they have the ability to control development and even hiring authority, but it is rare for a CTO to become a CEO within the same organization (and almost never outside the same organization unless the CTO elects to go entrepreneurial). Their base salaries may be commensurate, but they typically have much weaker equity and bonus options, and former technical officers are usually very underrepresented on boards of directors. The average age of a CTO is forty-six.

Most older programmers who "fall out" of the field do so at the bottom of the economic cycle. If you are not in IT management at this point (and many aren't), then when the reaper man from HR shows up, you know that you'll be on the next boat across the River Lethe (or at least the tour group escorted down to the parking lot, boxes in tow). Hiring slows dramatically at the end of the cycle, wages slip then go into freefall, and getting that next gig becomes harder and harder. If you're in your forties at this point and have built up some savings, this is a good time to take a sabbatical for a year, because you'll be taking one regardless, and figuring out next steps becomes increasingly important.

Navigating the Org Chart As An Elder IT Worker

Employers consider gray hair a disqualifying mark for IT. All of the things that make someone attractive at 28 make them unattractive at fifty. Fifty means pensions, higher salaries and higher insurance rates. Insurance for someone at 20 is roughly a third that of someone in their fifties. At fifty, you have obligations - houses that have to be bought and sold (which means higher relocation costs), kids heading for college, health issues are developing. You have too much experience - at best you can be a mentor, but mentors are also spending less time coding. Younger employees will find you to be a fossil, because you're not up on the latest paradigm changes or frameworks.

Outside of project management positions, within an organization about the best possible place for an older worker to land is in architecture. Architects are expected to be bigger picture strategists, and are responsible for design. Unfortunately, the architect slot is coveted by developers, so there's usually a lot of competition for becoming an architect, especially from hotshot developers (most of whom would benefit more from being in project management roles). Architecture is also a good role for consultants.

The one area where age is less of a factor for IT workers is, ironically, in sales. Because most IT workers tend to deal with management at a distance, many fail to appreciate that most management positions are also sales positions (including the CEO). It's not that unusual for IT people who have reached their own glass ceilings in organization to give up IT altogether to go into sales. They often know the product better, can talk technical when needed, and in general the age of a salesperson is a positive factor for customers buying from the company in question - it enhances their authority. The downside for the IT worker is that they are walking away from writing code.

It used to be that going into recruiting was another logical career jump for a programmer, for precisely the same reason as going into sales was. For executive recruiting agencies, this still holds true to a certain extent, but as I've written elsewhere, recruiting has become a commodity business: wages and commissions have dropped dramatically, and the average recruiter today is more likely to be working from an offshore call center, having only marginal training and working on razor thin margins.

The Older IT Entrepreneur

If an older "beached" developer has trouble getting back into the workforce once the economy begins to improve, the only other course of action is to go freelance - set up an LLC, hang out your shingle, and become a consultant. At this point you are giving up job security, but in reality, if you are in IT and are older than forty five, you have no other option. The weight of your resume will work against you, as will your appearance. You can go to work for a "consultancy", with decent rates and someone else doing the sales work, but at the same time, you are basically contingency labor - minimal insurance and retirement savings plan, with little in the way of benefits. It pays the mortgage, but doesn't allow for much in the way of saving for your when you retire.

Starting your own company, on the other hand, is (somewhat) more risky financially, but at fifty affords you more benefits than contingent work. However, it is also a commitment that, once made, will almost guarantee your ability to work as an employee at another company ever again is severely diminished. Most companies become very skittish about entrepreneurial employees, their HR marketing notwithstanding.

One of the biggest benefits of going independent is simple: you are negotiating your own contracts. This may seem counterintuitive - don't you write your own contracts whenever you get a new job? The answer, usually, is no. In most cases, employment contracts are very heavily specified, to the extent that you usually have a little wiggle room with per hour rates, but beyond that you either take what is given to you or you don't take the job.

As an independent contractor, however, you're providing specialized services that usually can't be boiler-plated, so need to negotiate more details. This includes striking work-for-hire provisions (something that is HIGHLY recommended, as these provide no benefits to you as a contractor), establishing kill fees on projects, and determining delivery schedules, change request provisions, and, most importantly, identifying when a given project is done. (This is the topic for another post, so won't belabor the point here).

A second consideration is that, as an independent consultant, you cannot be limited to only one client exclusively. This is again important, because in order to succeed in business, you WILL need multiple revenue streams active at an given time, and diversifying revenue streams becomes important if you are in a position where you have to fire a client (or they you).

Now, one of the most important questions you have to ask once taking this route is whether you take on employees? For consultancies, the answer is more complicated than it is for most other types of business. Are you selling your own expertise? Then the answer is usually no, you don't want employees for a while. On the other hand, if you are packaging your expertise and selling that through licenseable products, then you will eventually need a support staff and perhaps a sales agent, if only so you can concentrate on the business of building those products. In general, the latter is the preferable option, but this also requires that you walk a tight rope between financing your day to day operation and getting to a stage where you can produce this content.

Beyond IT

Unfortunately, beyond entrepreneurialism, the options for older workers in IT are limited. Ageism is a discriminating factor in the courts, but it is hard to prove that age by itself is the reason for getting or not getting a job, and usually only effectively applies when you can show a clear pattern of age-based discrimination in firing employees. Since most companies are more interested in settling such suits out of the eyes of the press, this also means that systemic change in this area is likely to be slow at best.

One alternative that may be worth considering is teaching. This may require going back to school to get at least a Master's Degree, if the goal is teaching in high school, and typically tenure track positions almost always require a PhD. However, the area of continuing education (offered by both universities and community colleges) seldom requires anything beyond a bachelors degree, usually focuses on teaching advanced technical subjects beyond the normal scope of their curriculum, and often faces a chronic shortfall of good teachers, because the pay and scope is well below that of industry.

On the other hand, this is also a good place to help train up the next generation of programmers, to pass on your own knowledge and experience, and to build connections. I've taught, over the years, and have on occasion been contacted by managers at companies where my students have gone to work for, in order to provide additional training for other students at their facilities.

Similarly, if you can afford it, this is a point in your career where writing books makes the most sense. The technical book market went through a collapse in the early 2000s, and you're not likely to make anywhere near as much in advances today as you could even in the 1990s, but books can be worked on during slack times and self-published through Amazon or similar venues, and the cost of publishing is seldom more than a thousand dollars to cover production and marketing. These books can serve to establish your "brand", and while you won't normally get rich from writing a single book, if you can publish a couple of books a year, in the aggregate you can get a very comfortable income after four or five years of writing.

Put another way, there is life after working in IT. We can bemoan the fact that businesses shouldn't discriminate on the basis of age, but in reality, this needs to be tempered with the realization that what most businesses seek are IT workers that are "good enough", and see experience and expertise not as a premium but as a cost to be paid only when "good enough" isn't. Once you've passed that big five-oh milestone, taking the mantle of the teacher, advisor or authority is not only recommended but almost required, if you want to stay in a position where your experience remains meaningful.

Kurt Cagle ([email protected]) is a writer and technologist who has been writing on coding, information and employment in that sector for more than thirty years. He lives in Issaquah, WA with his wife, daughters and cat, sipping coffee, writing words, stroking his graying beard and watching the rain come down.