"Year" is not a unit of measurement for experience
"Year" is not a unit of measurement for experience
How to deprecate yourself and win your growth
Resumes, job ads, personal intros and even funerals have one thing in common: they use “year” as a unit of experience.
Measuring experience by years is like estimating the strength of a rope by its length!
This is fundamentally wrong! The quality of experience cannot be measured with a quantitative metric.
Year in nature
Let us start with what we know: a year is the time it takes for the earth to go around the sun once revolution. Some animals sleep half of that time while others go through multiple generations. A hard year may wipe out a species while making another one stronger.
Point being, not all years are the same and not all years are experienced the same.
Take trees for example. Seeds become young trees in a year. Trees get thicker. Growth is more significant at the start. After that, time adds strength but not necessarily in a significant way. With enough time, the tree decays and falls under its own weight.
There is a point of diminishing return where more time doesn’t mean more strength. We humans tend to think of ourselves as separate from nature, yet our growth path is not that different from a plant!
This is how the career growth of knowledge worker looks like:
Not everyone gets to see the end but it’s inevitable. If not for the ever-evolving tech and domain landscape, the brain (our core tool) diminishes over time. At some point we fail to unlearn the old and learn the new. At some point, it is cheaper to hire a fresh graduate with fresh education, unlimited energy, and ambition but less pay demands and baggage (past experience and opinions).
In what resembles the fermi paradox of a knowledge worker career, it’s fair to ask: “where is everybody?” Where are our elderly? Does the demography present at our workplace really represent the demography of knowledge worker graduates 40 years ago?
I know of some former programmers who ended up as taxi drivers, antique dealers, or stock investors. The lucky ones climb the corporate ladder high enough not to be threatened by fresh talent but stuck in a meaningless ivory tower avoided by the people they are supposed to “empower” at all costs.
They may function as the wise elderly that our species has evolved to look up to in times of uncertainty. They have mastered the art of delivering advice that is vague enough to apply to the common pain but not specific enough to justify the pay.
Those are the lucky ones. There is also a champion minority. I know of a handful of them who defy the laws of nature and still code at the age of 60+. I have immense respect for any knowledge worker who is still in the game in an industry that is known for all sorts of bias including ageism.
If you are aiming to be among the lucky ones or the elite, think again. Are you in the top 1% of your industry now? If not, it doesn’t hurt to have a backup plan.
Year as a measurement unit
Back to where we started. Year is the wrong metric to measure experience. The "years" is a quantitative metric which doesn't map well to the quality of challenges, one's learnings, performance, or growth.
The quality of experience depends on two main factors:
Stimulus: the challenges one is exposed to
Response: how one handles those challenges
Being exposed to the same type of stimulus reinforces the response. Variations in the stimulus leads to mastery. Practice makes perfect.
There’s a point of diminishing return where longer exposure yields minimal improvement. And that’s the best time to change.
If we internalize the fact that there’s an end, why passively wait in fear instead of actively taking control and embracing change?
It is counter-intuitive to quit at your peak. One would naively think that continuing to do the same old thing will lead to learning new things. We are notoriously bad at understanding exponential change. To top that, nature’s gift that exists within all of us makes us a sucker for efficiency: we all want maximum pay for minimal effort. We all crave comfort, but life has other plans.
Ever heard of “what doesn’t kill you make you stronger”? It’s a testimony to the impact of challenges on our very essence. We are an adaptable species and that is key to our survival and evolution.
The thesis is: exposing ourselves to challenges, even synthetic ones, makes us stronger. i.e.. more experienced.
Story time
My own career as a software engineer is full of these synthetic challenges and seemingly abrupt changes. If I were to stay where I started, I would have 23 years of experience as a Delphi Windows application developer. Nothing wrong with that. But I would miss mobile development, UX, frontend, backend and SRE. The world would look very one-dimensional to me. I would be as good as my tool (Delphi, which is now deprecated by the way) and job function (Windows application developer).
The full story is too long, and I’ll write about it in my upcoming book titled “Deprecate Yourself” but for the context of this blog, I’d like to tell a couple of stories:
Many years ago, I joined a company which primarily made money from a Windows application. I joined an “elite” team of six including CTO which was working on the next big thing. The “thing” was web based. These people, smart as they were, started learning JavaScript, CSS, Angular (it was hot back then), Gulp (yeah! it was a thing before Webpack) and a few other web technologies. When I joined, they were on it for 18 months. All they had was a login screen. I saluted their effort and got to work. In a few months we had the first version of the UI up and running.
This was by no means a certificate of my skills. It boiled down to a simple fact: by that time, I had 3 years of front-end development experience under my belt from 3 companies. They didn’t. As the UI got praise, we started to expand. New front-end developers joined. Either there was a problem with our recruitment pipeline or something wrong with the way we architectured the CSS, the new front-enders spent most of their time in JavaScript land. CSS wasn’t getting much love, so I found myself in CSS-land more often than the others. Having a background in UX by that time (story for another time) contributed to that. It went on for a while until I was called “the CSS god”! As flattering as it sounds, I saw it as a big red flag.
The moment you become the go-to person is the moment of decline. I saw it as a personal failure to hand-over my CSS knowledge. I started doing CSS workshops while in parallel started interviewing elsewhere and was out in a few months. My next job was tough; I didn’t make it. But that’s beside the point. I could stay there and be the CSS-God for as long as that product existed, but I chose not to.
A few years later, a similar incident happened. A consultant left us with a code base that was not maintainable. It was a backend code. I was trying to dip my toe in the backend and volunteered to work on it. A few months later, I became the go-to person for that repo. That was a sweet deal. In fact, that’s how the consultant who made the codebase could afford to buy an expensive luxury car. He had optimized the code to his way of thinking, and as beautiful as it was, it wasn’t intuitive. I did what any [apparently] stupid person in my position would do: I refactored the code to comply with common conventions and documented the hell out of it. I even did some workshops for a larger group of internal developers. I would do anything to deprecate myself.
Once the DX (developer experience) was good enough, the people came. Turns out people really didn’t want to go through me for every minor change, they just didn’t know how to find their way. Seeing how documentation gave such traction to the product, I motivated others to do the same. Alas, I got the reputation of being the “documentation master”. Yep, you guessed it. Time to hand over, do interviews and move on with my life.
The point I’m trying to make is that each of those stories show an objectively comfortable place to optimize for the pay/effort equation, but I chose not to. Who doesn’t want to be the go-to person for something? Who wants to let go of such a sweet leverage for salary raise and promotion?
I have changed my company or team consistently every 1-2 years and don’t regret it. And it paid back. I managed to triple my salary since I started with this method. Had I stayed in the same place, I would have had to deal with a raise that was hardly catching up with inflation and at best, had to twist my employee’s arm to squeeze some money. The salary is a bonus. For me, learning and personal growth is the main reason for challenging myself even at those seemingly “peak” moments.
Conclusion
I can confidently say my years count more than average and I invite you to rethink your career. No one owns your career but you.
Am I preaching to be disloyal to your employee? Hell no. But also realize that companies are not charities. You’re getting paid for a nominal service. The moment you aren’t worth it, companies are not shy about firing you.
In a true capitalist market companies are responsible for their growth, and you are responsible for yours. It’s ideal if the two match but internalize the fact that companies can live way longer than a typical person’s career. Deprecate yourself and own your growth. If you like the company, switch teams. Expose yourself to risk and challenges. That’s how you grow in a methodical and semi-controlled manner.
"It's not the years, honey. It's the mileage." - Indiana Jones
To recruiters and hiring managers our there: stop recruiting with years of experience. Focus on attitude, performance, and growth potential. Spend the time to hear one’s story. It all comes down to what the person has made from those years.