What happened to Entry-Level jobs?
The Plight of Junior Developers
My first real job as a coder came in the Summer of 2000. I was still in college at Georgia Tech at the time and I worked some odd jobs to pay bills.
One night, I was simultaneously working the door at a nightclub in Atlanta and reading a math textbook — if there was a break in the line I would pick the book up and read right there.
A woman came up, saw the textbook and recognized it. She was also a student of Computer Science at Tech. She told me that she had just gotten a summer job at Turner Broadcasting as a developer and they were looking for more people so I should apply. We would end up working together for the next 15 or so years.
A month after starting in this internship, I was offered a permanent role. I accepted, choosing to work full time and do school part time. This extended my school years out a bit but ultimately I was able to get real world experience and work on some great projects.
This was the beginning of my Intern to VP story
I want to hone in on one part of that intro. The hiring.
I joined the company as a junior developer. The woman I met also joined as a junior and we had yet another junior role open. All on the same team.
Between she and I, we would bring in at least another four classmates as entry-level roles.
It was a good time to be involved from an opportunity stand-point. Teams were hiring and training. I was thrown into the deep end and given a ton of responsibility and exposure to customers and the process of software development.
Fast Forward 10 years.
By this point, I had progressed through the developer ranks from Junior -> Mid-Level -> Senior -> Tech Manager. I had my own team now and I was making some team structure and hiring decisions. Having come up through the developer ranks myself, I found myself aligned with junior developers and interested in career progression.
Not only do I want to make sure teams have a good mix of various level roles, including entry-level. But I also want to make sure if we are going to add a Senior role or higher to the team that we’re giving opportunity to the lower level team members to step up.
However, I was running a new team doing payment processing and the work required heavy regulatory processes so we purposely stacked the team a little higher on the experience scale. I didn’t have an entry level roles. That’s when this observation happened:
I wanted to fill a Mid-Level position and there was no one to step up.
There were basically zero junior developers in our organization. I don’t mean just my team, I mean all around me. I asked peers if they had any junior devs that I should consider for the role and the response was that they didn’t have any people at entry levels.
In the 10 or so years since I joined the company, the stance toward entry level roles had completely changed. I recall working with at least 8 other junior developers on just our team in that span of time, but I’m sure there were many more. Now as a manager, as I looked around for a junior developer to give an opportunity of advancement and we did not have any left in the organization.
What happened?
I know of a couple of factors that lead to this transition.
Wage Increases. Increasing demand drove the salaries of developers up drastically over these years. In this excellent review by CodeSubmit, we see the average salary of Computer Systems Engineers increased by 35% from 2001 to 2011. This sounds great on the surface but almost by definition this meant that a company’s expected wages would not keeping pace with the fast changing market rates (especially note these were recession years). If companies didn’t keep pace there were two major impacts:
1 — Existing junior developers would leave companies to go to other companies to get a re-evaluated market rate (and probably a better title).
2 — Hiring managers could not find people at the previous rates. The market rates had gone up, but the company’s expected wages for a certain role did not.
Therefore, hiring managers had to start bringing in people for essentially entry level roles but calling them mid-level because you could not find people who would accept junior salaries.
Experience Demands. Just as it happened with my team, as complexity goes up managers think they require more experienced developers. I personally don’t believe this is true and I’ve seen some amazing work from junior and mid-level developers. I even think that a lop-sided team of only seniors and above is another organizational smell.
But what often happens is a team is doing great, building some amazing stuff and so their responsibility grows too. They are getting traction, more customers, more usage and now people are working way too much to keep up with demand. People may be working nights and weekends, maybe customers are getting upset, maybe quality is going down — the situation is getting untenable and there is a need to hire. Hiring decisions require approval, sign-off, budget, planning, and more approval. By the time all of this happens, the workload situation is even more dire.
Who do you target for a hire? A junior developer that is going to require training (from the already burdened team) and time to help with the workload — or are you looking for a senior that you believe will come into the team and be more effective immediately? Unfortunately, managers opt for the latter.
Technical Managers. There is another dynamic at play here. Technical managers are generally developers turned managers. I am one. I believe all of my managers were also. It’s a badge of honor in software development and generally developers only accept a manager who at least “used to” code. I don’t think there is anything fundamentally wrong with this, in fact, I think that part is a good thing. The fact that an individual was a developer will make them a better manager of developers. However, we need to whole-heartedly acknowledge that management and development are completely different skills. Just because someone is a great developer it does not mean they know how to manage people.
The fundamental problem above is about building a pipeline of talent in an organization. It’s sacrificing long term success and career planning for short term gain with a stronger team right now to deliver the current workload that is on the team. I don’t know if having more training in management would have helped me identify these problems and solutions sooner, but I know this: all the time I spent learning programming languages and algorithms definitely did not help.
I am fortunate that I did receive training when I became a manager and there was a strong culture of sharing guidance as I made this transition. I know that not all developers-turned-managers were as fortunate.
What can Leadership do?
Balance your team. If you don’t have a good mixture of experience on the team you must work to fix this over time. When you have a role open, consider if you could make it a more junior level. You must invest in the future. Know that hiring for the most senior person you can afford right now is a short term solution.
Invest time in onboarding. Among Eric Ries’ many gems in The Lean Startup, he advocates investing time to build a strong onboarding process. He goes so far as to explain that their processes were so efficient that they had new hires making production commits on day one! I don’t know if you need to get that efficient but I do know that if you have a good onboarding process then you remove one of the main drawbacks to hiring entry-level engineers — drain on the existing team.
Act before it is too late. As in the example above, if you wait until the team is pulling all-nighters to realize you have a problem and try to address then you will have compounded the issues. This will make taking a short-cut too attractive and deter you from doing the right thing. Act now as if this is already a dire situation — because it is. (Note too: in a situation like this your existing rockstar team members are liable to leave and make things much, much worse.)
Give real challenges. My experience is that the best way to learn is to jump in. People need real challenges to grow. Daniel Coyle notes in The Little Book of Talent that in order to grow skill you need to find the sweet spot between hard enough so that you don’t always succeed but not so hard that you never succeed. I’ll add that with good management, you can still make sure projects succeed — individuals might just need some help to get there.
I once interviewed a person for a senior developer position. They had 10 years of experience listed on their resume but looking more closely I was surprised by the lack of depth. I asked what they did in their first year on the job and they explained they mostly maintained unit tests and fixed any issues that appeared. I asked what they did their second year and the answer was the same, and so on each year after that. I concluded (as Stephen Covey once did) that they did not, in fact, have 10 years of experience but instead had 1 year of experience 10 times. The developer certainly had a hand in this situation but their manager also should be faulted for never presenting more opportunities and challenges to keep this developer growing skills and experiences.
Internships. Sponsor a program of internships. Pull people from diverse backgrounds. However for this to make a real difference to levels and balance of the team there has to be a path presented from the internship into a permanent role.
Manager Training. Make sure all new managers receive training immediately. You need to set them up for success and this will make sure their team members are setup for success too. Don’t forget ongoing training and guidance as well. Remember — just because someone was a great engineer it does not mean they are a great manager. They likely have the drive that you want to see but they will need new skills and coaching.
We need to do more about this. We need to actively work to create the space for new coders. We all know there is a demand problem with not enough developers. We all want to see more diversity of thought, race, background, and gender in the developer community.
We need to solve this problem.
I’m planning a follow-up to this article with suggestions for the person who is looking for an entry-level position. If you have comments, suggestions, anecdotes to include, please leave a comment or send a message.
Be sure to follow my Medium page here for more articles like this and sign up to receive emails when I post so you never miss out.
