Two Other Possible Reasons Juniors are Having it Tough on the job Market

 · 

It has recently become a hot topic that junior developers are having difficulties finding a job, even though the market is very hot at the moment. Market for senior talent is, yes, but for juniors - not so much. As a matter of fact it has been flagged that it is harder than ever for a beginner to start a career in software. Multiple causes have been outlined:

I would like to raise two extra topics though, which I haven’t seen mentioned. I might be a minority voice here, but I feel they are relevant and we are not giving them due attention.

Hands-on work with authority is considered malpractice

We made hands-on teaching a career dead-end by idolizing non-coding engineering management.

Software development is, at this stage, a near-blue-collar activity. It is a craft, just like many others - even creative ones - are. Like writing. Like design. Like filmmaking. Craft professions have a fairly standard setup for career growth - you start low, for example in an assistant role, and then “grow through the ranks” as you learn the ins and outs of the profession. This is what mentorship is about. Mentorship, however, has a few interesting prerequisites. You can try to do without them, but you are not likely to succeed.

The modern setup, however, is that the only way to obtain authority in software engineering teams is to go into engineering management. We explicitly have decided that the setup we want in our teams is not the creative company or crafts one, but a factory floor one. When you need to teach a junior, you must have both authority and responsibility and be doing hands-on work. It is of no use to a junior when their manager asks them “where do you want to be in 5 years” but does not show how to google for errors efficiently.

And we have a structural issue with our “factory floor” desiderata. For growing juniors well you need to be set up for apprenticeship. Not mentoring, not coaching - apprenticeship - and to do that in a structured way a senior needs to be a tech lead manager. The article I’m linking to explicitly tells you not to do this to your career and not to become one. This advice is not unique: we are spending countless bytes of tweets to convince each other that if you do both code and leadership you will invariably suck at both.

You will be skipping one-on-ones as a manager and you will be forcing your inferior solutions upon your peers as an engineer. You will be doing technical interviews while you ought to be doing culture-fit interviews. You will be figuring how this god-awful framework found its way into your new product instead of getting a seat at the table. The people who found great success in leadership bash you for requiring your engineering leadership to do hands on work. Asking engineering managers to code in interviews or to show code is considered bad manners for employers. Phew doing code? Do you need to hire me for that? Am I supposed to be able to do work of my entire team? I thought I am supposed to lead them instead…

The end result is that being good at hands-on work and teaching with authority becomes a hot potato. Nobody wants to do it, it is not glamorous, it is not appreciated and it can be…spicy. Every situation where someone who is not the engineering manager has authority is considered “mistrust” and “opportunity for abuse”.

We ended up in a curious situation where the only way to step off the tech treadmill (changing stacks, frameworks, team reshuffles…) is to go into pure people management. And it works! It does push folks who are successful in management further up in management. The problem with that is, however, that purely people managing a junior likely won’t be enough.

Then we come to the other side of the coin: imagine that you are a successful mid-career developer and you already did lose your shot at people management (either it’s not your thing, or you were labeled “difficult” and not aligned with authority or you simply had other commitments like having a family at the moment where career aggression was called for). Doesn’t matter - the fact is that you are this person who people are likely to come to for advice, and receive a kind, helpful response. People come to you for solving problems. You have opinions, and you are prepared to share them if listened to. Apparently, some of those opinions are valuable – as people keep listening.

Now you get an opportunity to teach a junior. But beware! You may not decide what the scope of the work is going to be - for that is the purview of the product manager. You may not decide what work to assign - that is the purview of the scrum master or of your engineering manager. You may not dictate solutions either - that is no longer the purview of anybody, because we don’t do authority here, only influencing. Here is what you might potentially get instead:

Now, these are the upfront “bad” scenarios. Imagine none of this happens, and you successfully help a human grow through the ranks and become better. You do get a chance of having this noted on your reviews, and it is wonderful. That’s it. No - really - that’s it. All the other things, seen from the corporate career perspective, are tarpits of doom - and more than a couple of them carry the extra danger of labeling you “difficult”. If you already have that label, you are getting the second - and you know what a third could mean.

What do we do if we want to survive in a workforce - especially in one where situation can be very precarious due to the pandemic, remote work, shifting economic landscapes etc.? Where you, as a mid-career developer, likely already have a family and children - and hell the daycares close again ffs? Will you take all those extra risks for all that reward of seeing another person shine? Just one other person?

Maybe you will. If you are just crazy enough. But most people won’t. Teaching craft has become not only unfashionable but can also be dangerous (a lot of grief and frustration in people management that should be directed way higher up into the chain of command ends up shot as flak at the people who can be accused more easily - peers).

Once it becomes unfashionable and risky for their careers, are we really that surprised that mediors and seniors prefer to stay away from mentorship? Are we really? Just look at these stats - “engineering manager” openings outnumber the “tech lead” openings 4 to 1.

Let me recap: we have made “hands-on leadership” frowned upon. “Hands-on leadership” is a requirement for teaching. We might have made a mistake.

Too many reorgs

Mentor/mentee relationships take months to establish. Our reorg fetish (“change is the only constant”) and the like destroys them.

A relationship not only takes long to form – it implies that a great deal of trust has to exist on both ends - the mentee must trust that when their mentor makes certain choices, these choices are to their common benefit. The mentor must trust that the mentee does not want to filibuster them and is not using them as a stepping stone to something they did not manage to obtain - like a position in engineering management with a full bypass of hands-on work, that the mentee is not going to shit on them in front of customers or stakeholders, and the like. This trust does not magically appear by virtue of having a meeting with your mutual engineering manager and shaking hands. It gets forged over months of serving together, under the same flag and on the same team. One of the most valuable things that comes out from craft relationships like this are the intangibles, the ungooglables. Who is the crazy exec in the room? Who is likely to give deadlines which are compressed by a factor of 3, and for what reason? How do we approach unreasonable requirements? How do we debate solutions?

The reality is that modern software teams often reshuffle once a quarter. The cadence I have last been in was once every 6 months for the entire organisation, and at least just as often for the team. Every reorg would bring hire-above into the picture, destroying any reasonable relationships of influence-without-authority that could have been there to begin with. Some teams existed for a few weeks, getting disbanded right after their project got completed. No stable pairs of mentor-mentee could form, the only constant would be the managers who would go ever higher in reach and headcount.

A lot of those reorgs do not hold the interests of the mentor or the mentee in their sights - they are often done instead to accomodate newly hired upper management layers, or to achieve other political goals which do not have anything to do with output.

In this situation, for a junior, placing their trust in a mentor is also incredibly risky! What point is there in confiding in someone if by next month you are in completely different departments, working on completely divergent projects? Is it really conductive to one’s career examining the work style of all those 6 different seniors you are going to work with throughout the year, especially if half of them quit by year’s end?

If we wanted to put an end to this: for the first year of a junior’s journey, if they bond with their mentor, only reorganize them in pairs. Will the modern school of software reorgs ascend to that principle? Unlikely.

Let me recap: with our fetish of “I must change so I can stay the same” we have relegated structured hands-on teaching to organisations who can run their own vocational schools. Our insatiable lust for promotions (and thus reorgs!) makes it impossible for proper bonds between mentors and mentees to form. We might have made a mistake.

All of this is pretty sad

In my previous line of work most of my mentors were working on the same projects I was working on. They would hand down tasks, split tasks, discuss work - but also they would shoulder in time of need. They would have the guts to say “we have to do this thing together, it is absolutely bollocks but this is what the client wants and we cannot play around it. The shortest path to spend the least possible time on the bollocks thing is to…” With the best ones I’ve had I knew, always, that they would be able to do the task I had to accomplish if I were to fail - and this was clearly communicated. At all times. It is an incredibly empowering feeling.

Afterwards came the time when a most gratifying thing in the world is seeing how someone you teach becomes better than you were. Seeing people achieve something. Seeing them “get it”.

By arranging the setup against newcomers in the profession we rob folks of the success of growing into capable professionals. We are settling nicely into our big tree, and pulling the ladder up with us.

I doubt we, as a community of practitioners, are going to benefit from this in the long run.

How this manifests

You need an extra person for your team, and when you go “maybe we should consider less senior talent and maybe we could provide them some support?..” and your most senior folks all go like “it might be difficult with the current workload”, “we have so much going on at the moment”, “it might be difficult with teams being so volatile”. Ask yourself: are they saying what they are really saying? Or are they aware that the organisation has clearly indicated that making other humans progress is not getting them promoted? What are the dangers they are trying to avoid by saying “no”? What are they afraid of? And how is your leadership responsible for this situation? How can you help this situation change? Will you give them actual responsibilities – but also opportunities if they say “yes”? Will you provide them extra comp? Extra training (on how to mentor: yes that is a thing)? Will we give them some latitude in defining the project scope to work together with their mentee?

What is there to do?

Well, some things. Some of these things are right against the mainstream line of thinking these days, some are just my personal positions. I have debated many of them with many folks, and lots of good (and bad) conversations were had. If I could summarise to just a handful:

The current mainstream approach to managing engineering teams steals authority from engineers, and thus destroys apprenticeship – which is required to bring new folks into the profession. We should reconsider.

I hope this was interesting, and – despite all of the above – let’s hope a great number of amazing, talented junior people will join us in the joy of crafting beautiful things together in 2022. 🥂