Humans are ridiculous bad a taxonomy. We look for patterns to group stuff together, even though most stuff is different from most other stuff. Nature defies any classification system we humans try to create, but it is our nature to try anyway. Our classification systems can never be applied universally. Just look at how poorly we define seasons.
Drift between theoretical classification systems and the tangible stuff they try to classify isn’t always a bad thing. Classifications are a kind of abstraction that hides some details in order to make others easier to reason about. For example, Linnaean taxonomy is good at grouping individuals into “species” because we find it useful; even though nature is far too messy to ever be accurately represented in a general taxonomy, having a taxonomy nonetheless helps us study biology.
Classification systems are most useful when they describe something that already exists. They lose much of their usefulness when we use them to prescribe what we want to exist.
Today I want to discuss career ladders! If your engineering team is worth their salt, they try to help you grow as a software developer using a “ladder” of different stages of your career. I’m using my own career and Artsy’s own engineering career ladder to illustrate shortcomings in engineering careers in general. Hopefully this will resonate with your and you can help your team work around those shortcomings.
I have two main complaints with engineering career ladders:
Okay so let’s deal with the tacit suggestion that to grow in your career, you need to advance up the ladder. From junior to intermediate to senior and beyond. There is an expectation from businesses and peers that developers ought to seek to advance their careers, that we should always be working towards the next rung of that ladder.
This problem is exacerbated by conflation between growing one’s career and growing one’s skillset; continual learning is inherent to being an engineer, but continual progress up some arbitrary career ladder is not.
This is something I’ve been facing lately in my own career. According to Artsy, I am a “Senior Engineer” despite fulfilling many of the requirements for the next level role of “Staff Engineer.” I had convinced myself that I needed to broaden my skills and praxis to advance to that next level, despite how it was affecting my happiness and satisfaction with my career now. Let’s take a look at a Staff Engineer’s responsibilities at Artsy:
The requirements that I already fulfill are fulfilled because I enjoy doing them. The requirements that I don’t fulfill are largely because I don’t enjoy doing them.
Why aren’t I happy just being a “Senior Engineer”? Probably the hedonic treadmill I guess. I didn’t even realize how much my pursuit of the ladder’s next rung was making me unhappy and dissatisfied with what I already have and do. I was a coyote.
I believe that the expectation of engineers to continually advance up a career ladder is intrinsic to the overwhelming breadth of the ladders themselves. These ladders attempt to describe the complete range of developer experience levels, despite that how you grow as a junior dev is very different from how you grow as a senior dev.
The fault is in the ladder metaphor itself. It works well as a prescription of how to grow from novice to competency but does not work well as a guide to growing from competency to proficiency. Let me explain.
When starting a software developer career, there are basics that everyone needs to learn. Things like familiarity with source control, command line tools, and a programming language. Once you learn those basics, you can move onto more complex, but still universally applicable skills such as writing idiomatic code or contributing to open source. But beyond these fundamentals, things vary wildly based on individual engineers.
A senior engineer might pursue a career in user interface systems, people management, community building, system reliability, and so on. No career “ladder” can possibly prescribe steps and goals for such a wide gamut of paths because careers defy classification. The ladder metaphor works very well for junior engineers but loses applicability the more an engineer advances.
A better metaphor might be that of a tree: roots and a trunk that follow a single path upward before splitting into many branches. This provides structure for beginning engineers while still accommodating the breadth of ways individual engineers grow.
The core problem with prescriptive, linear career ladders is that the limitations of the ladder metaphor cause them to be imbued with the biases of whoever writes it. For example, Artsy’s engineering career ladder requires public speaking and/or blog posts (which excludes developers who aren’t interested in or able to practice those activities). It’s also very oriented around “services”, which excludes developers who work primarily on apps.
That’s not to say Artsy’s ladder isn’t useful – it is! I’m just highlighting that the experience and background of the engineers who wrote Artsy’s ladder have influenced it. By extension, those biases have impacted the careers of dozens of engineers who have worked at Artsy. That impact, of biases on career ladders, is going to be present in any ladder, no matter who writes it and no matter how useful that ladder is.
I’ve realized that my focus on advancing to the “next level” of Artsy’s ladder is hurting my satisfaction with what I already have. I need to learn to pursue career growth that leaves me fulfilled and not dissatisfied.
And I’ve realized that the ladder metaphor itself is prescriptive and every ladder is imbued with the biases of its authors. Maybe I need to write my own career ladder, specific to me.
As an industry, I hope that we move away from prescription towards description, away from linear tracks towards intertwining paths, away form the relentless pursuit of what’s next towards an appreciation for what we’ve already accomplished.