The Intermediate Engineer Syndrome

Graduating with a Computer Science degree from Duke University, Wen followed some of his friends into a well respected tech company.

Wen worked hard, consistently hit his goals at work, and gained a great deal of technical competency in the first 18 months. A timely promotion to Software Engineer II came just in time for a confidence booster.

Another year in, after settling into a steady rhythm of some meaningful coding and a fair amount of maintenance work, Wen is starting to get bored and is ready to make a bigger impact elsewhere. Perhaps a start-up? Surely with 2.5 years at a well respected company and seeing some highly sophisticated systems at work on a large scale, he’d be able to make a difference at an earlier stage start-up.

Many companies think so too. After comparing a few offers and a round of friendly negotiation, Wen is now excited to join a series A start-up as a Senior Software Engineer. He had to take a pay cut on the base, but with the Senior in the title and the equity options, Wen has convinced himself that he’s made the right decision.

However, the honeymoon period didn’t last for long. Just a couple weeks in, Wen is starting to get really worried.

To start with, there are so many problems that people don’t even seem to see! The code is pretty messy, none of the Javascript is typed, tickets have almost no description, deployment takes hours, and where’s the documentation anyway? Don’t even get me started on the big monolith, this is almost 2022!

And these are not even the worst part. What really got to Wen was when he put together his thoughts into an architecture proposal and shared with his manager. “We appreciate your effort”, said the manager, but somehow, someway, all of the suggestions were deemed as either “irrelevant” or “too much effort, we don’t have time for this”.

Wen is upset, angry, and a little confused. “I’ve seen how these things should work, I’m trying to help, why wouldn’t they listen??”.

This is what I call the Intermediate Engineer Syndrome. And Wen is not alone.

See this doesn’t happen to entry level engineers because they don’t have much expectations on how things are supposed to work, and this doesn’t happen to true senior engineers because they’ve seen a variety of ways of doing things and can empathize with wherever the company is at in their life cycle.

The danger is with somewhat experienced (i.e. intermediate) engineers joining a new company. Onboarding them smoothly can truly be a challenge, and a massively important one.

The first 3 months of a new Intermediate Engineer’s time at a new company is a special period of time that requires extra tender loving care. This is the time that they have the freshest ideas and are most enthusiastic to make a difference and establish themselves, but this is also the time that they have the least amount of context on why everything is the way they are. Without enough encouragement, they’ll feel not heard and not valued just like Wen. Without enough guidance, they can really rock the boat and drag the team, as well as themselves into a big hole and hurt the team’s productivity.

What should we do?

Set clear expectations early on

During the initial onboarding process, or even as early as during the hiring process, be earnest about where the team is in terms of processes, tooling, and everything else, so when new members join, they can already have a good sense of what strengths and weaknesses the team has.

Share context as much as possible

Ideally, there is a trail of record on when certain important decisions were made, and why. Lack of that, try to share as much context with the new joiner as possible, either in a verbal or written form, to help them understand the rationale behind prior decisions. Every team has a historian. Find them, and let them tell the tales.

Encourage ideas, but don’t guarantee immediate action

Related to setting clear expectations, we need to vigorously encourage new ideas from new joiners, but be clear about the fact they might not all be implemented right away. Talk through them with the person if time allows. Ask them to elaborate. This shows curiosity and respect. And sometimes, they’d reach the same conclusions as what’s already there!

Write them down, and play back later

What I found has worked wonders, is to simply write all these new ideas down, without filtering. In a few months time, play them back to the person and ask them if they still think they should be implemented. With a few months of more context, chances are that they can already see that many of these ideas are not necessarily the best fit. Letting them say no to themselves, and potentially inspire them to come up with new, better ideas.