The dev career ladder needs reassessing — not all senior developers should be managers
This article was originally published on .cult by Nadya Primak. .cult is a media platform for untold developer stories, where developers can read content around the softer side of development and watch documentaries about the tech they love. You can read this original piece here.
The career ladder for software engineers is often confusing and inconsistent. Many people who go into software development tend to go in with tunnel vision – they don’t even think about the career ladder because they’re so focused on the next pay bump or the next feature release. Also, they know that there are at least two steps in the ladder to worry about before anything dramatic can happen: junior developers become mid level developers and mid level developers become senior developers. But what about after that?
A lot of the problems that developers complain about in the tech industry are nested within that question. If you’ve been coding for the last four or five years of your life, spending more time in front of the computer than in front of other people, chances are your social skills might have taken a hit. If you are an extrovert or even moderately outgoing, this probably wouldn’t be a big deal. But if you’ve always been the type to prefer staying indoors, or worse, preferred the company of computers over people, a manager is probably the last thing you want to be.
The problem with promoting all senior developers to managers
Unfortunately many organizations promote senior developers to managerial roles. There is a mistaken assumption among people in leadership that those who develop a high level of expertise in their field will naturally be good at managing. They fail to consider that what makes a good software engineer and what makes a good manager can often be at odds with each other. Good developers are detail-oriented, deep thinkers who thrive on solving technical challenges that are, at the end of the day, either solved or not solved. Good managers can see the big picture, and thrive on solving problems at the organizational level that require negotiating with, compromising, and sometimes confronting other people. These types of problems rarely have a black and white outcome, and usually there is no tangible reward besides the relative happiness of the employees.
I have experienced this first hand with one of my past managers. He had an impressive looking resume, having worked on the ground level of many start-ups as CTO and founder, but he seemed to be much more proud of the fact that he had been coding for three decades. On the surface he seemed like he would make a good manager, probably because he exuded a great deal of confidence.
Unfortunately it ended up being quite the opposite. It took months for leadership to take action despite many employee complaints. What was especially uncomfortable was the way the manager responded when he discovered he was under fire. At every 1:1 he would ask me directly for negative feedback I had about him, as if I would just tell him to his face. It was incredibly awkward, and demonstrated a complete failure of grasping social norms. Not to mention empathy for the other person in the room and how they might feel being asked such questions. He also seemed to believe that if nobody gave them the negative feedback to their face, that this must mean he was actually performing well.
Ultimately, this particular manager was much better suited to programming as an individual contributor rather than leading a team.
Alternative pathways for senior developers
Luckily, some companies have moved away from promoting all of their software engineers to managers. One alternative approach is to give software developers three different “tracks” to choose from. Developers can take on a range of leadership responsibilities depending on the track. For instance, there is the team lead track where senior engineers become lead developers that make some of the more challenging and difficult technical decisions for the team. They also help mentor their teammates but do not take on as many managerial duties as an engineering manager.
For developers who have no interest in taking on leadership duties, there is the option of becoming a software architect. These developers get to make technical decisions that usually impact the future of the company and are often trusted with the keys to the kingdom. These developers are the ones who understand how all the software fits together and have a mental model that includes every little nook and cranny of code.
The best part about having this three track system for promoting software engineers is that there is wiggle room to switch between tracks if a developer decides they want to try something different or if it turns out they are not well suited for the track they are on. It reduces the risk of creating terrible managers that end up causing other developers to quit or lose motivation. The personality and attitude of managers in an organization often influence the culture. It’s important for leadership to reach out to their direct reports and be able to identify and fix issues when they arise.
Unfortunately, even this three track system is not bulletproof. Favoritism, slowness in moving people to a different track, and poor promotion metrics can cause even the best system to fall apart. Start-ups can be especially vulnerable to developers that can suck up to the CEO and bypass formal processes. While large companies tend to have less of that problem, they often adopt ranking systems that may or may not be effective at identifying the best employees, depending on how easy it is to play the system and how many people fall between the cracks.
Muddying the waters even further is the fact that developers often switch jobs when they don’t see a path forward at their current company. My first official title when I broke into the field was “Software Engineer.” When I moved to DC it became “UI/UX Developer” and I negotiated a pretty hefty pay raise in light of the difference in cost of living from Missouri. The following job ended up giving me a senior title despite the fact that I had less than 2 years of experience in the industry. They gave developers seniority not purely based on years of experience, but based on that developer’s salary.
This led to a strange and somewhat uncomfortable situation for me when, two jobs later, I found myself back in a mid-level title. From an outsider’s perspective, it sort of looked like a demotion. I didn’t know whether to remove “senior” on my past positions on LinkedIn or whether that would end up hurting me more. It happens because there is no standard for rating a developer’s skill level across the industry, and certainly no standard for pay depending on that level.
A potential solution?
That is why some developers have been calling for the creation of an organization responsible for standardizing the requirements and skills that developers need across the United States in order to create a more level playing field and also a system that allows developers to advocate for themselves and figure out if they are being underpaid. Unlike these three track systems which still allow managers to make decisions based on their own opinion about a developer, a trade organization for developers would create a third party that holds managers accountable.
Certainly there are potential problems that could be introduced by a trade organization, but right now the software engineering industry is basically the wild west when it comes to promotions. You have developers with 10 years of experience being paid 45K alongside junior developers at start-ups making upwards of 100K.
Underrepresented folks in tech are still seeing a gap between their paychecks and those of their white male counterparts. Every time I got a new job part of me felt like I was back at square one again. As technology becomes more and more complex and humans rely on it on a daily basis, it seems the lack of a trade industry could not only be problematic but even catastrophic.
Technology industry standards impact millions
Having no coding standard for, say, a social media company, might seem inconsequential, but when you have software operating planes and cars and security there are lives at stake. It’s not just about making developers’ lives easier and fairer, it’s about creating a system where technology can actually be reliable and not subject to the whims of a company CEO that wants to save some money by telling developers to cut corners. Developers and frankly, the human race, deserves better.
Published July 5, 2020 — 17:00 UTC