Don’t underestimate less-experienced software engineers
Business is going well, and your engineering team is not a one-person army anymore. Instead, you have a couple of mid- or senior level devs on board. Now you need to grow a team to make your product even better. There is no better time to start hiring some less-experienced people.
This, of course, doesn’t always have to be true. Juniors probably won’t help you much if you are in the first phase of building rocket ships or quantum mechanics algorithms to solve NP-complete problem. But the truth is that the majority of tech products are built on top of existing solutions, SDKs/libraries, APIs, or managed cloud platforms. And this is the perfect space for a dream-team of junior and senior software engineers collaborating.
Hiring juniors is a great strategic move — it doesn’t have anything with your budget, but with keeping your tech stack and engineering team a top-class.
What does it mean?
Bulletproofing your tech stack
There is a great book called “Antifragile” by Nassim Nicholas Taleb that starts with the prologue:
“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. According to Taleb, the opposite of fragile is antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.”
Is your platform antifragile? When less skilled engineers can blow it up with their rookie mistakes, you shouldn’t blame them. Maybe It’s because your QA process or deployment automation isn’t good enough to catch those things early. If you cannot hire junior software engineers because your system doesn’t tolerate any mistakes, that’s very bad. Are you sure that your seniors spend their time effectively — by delivering new value to the business, instead of fighting with fire or testing things manually?
Automate processes, hire juniors, and challenge the engineering team giving beginners more responsibilities. By breaking things early, they will help you to make your tech stack antifragile.
Decreasing the entry-level of your technology
At some point in a software engineering career, new language, another system or cloud platform become just tools. They all look and work very similarly. And your coding wizards will try them on every possible occasion — to learn something new or challenge themselves. Their senior teammates won’t mind that — It’s a piece of cake for everyone to understand everything (this is how we, devs flex our 🧠 muscles).
But there are not so many seniors on the market. Soon or later, you will need to scale up the team. You will need to hire people who are just okay. They do code in one language, and know one cloud platform — they have a great life beyond coding.
Now, how much time is needed for new-joiners until they will start contributing into your 10-different-languages tech stack? Is it one week or two months? Having juniors on board early days will make your seniors simplifying things. If their solutions aren’t easy to understand, they will need to spend their precious time, explaining them to less experienced teammates.
Let your seniors do the senior job
It’s also worth defining the expectations for each of the positions. In simplified terms — junior software engineer builds features with support and advisory, mid-level is independent with a delivery, and senior should scale things up. What does it mean exactly?
Scaling can be done with thoughtful and accurate decisions about code architecture, used platforms, etc. But scaling is also tightly connected with a proper knowledge transfer. It’s about making sure that senior inspires and leads less-skilled engineers so they can build things most efficiently. Seniors shouldn’t be just great coders. They should be effective problem solvers, where very often working with people is more important than working with code. Working with juniors is a great soft skills training.
Keep software engineering levels ladder healthy
What does it mean to be a senior or mid-level engineer in your company? If only seniors can deploy to production or add a new module to a mobile app, it seems that your expectations regarding this position aren’t very high. How then you name people who know and do more than that?
By hiring juniors, you have a great chance to diversify your expectations. Let juniors do new modules or push code to production. Make sure that full ownership over product feature is one of their goals. Does it look unrealistic at the moment? That’s even better! Train juniors to achieve their goals, and work with seniors to simplify tech stack, so impossible becomes simple.
You need no heroes
In the early days of product existence, every week is full of heroic acts. Your code magicians fix things in the middle of the night, work 12 hours per day, and answer phone calls 24/7. They need to deliver ASAP. But at some point, fast delivery becomes equally important to stabilization. And later, they both are replaced by a new requirement — scalability. When you have to handle user base growth and scale the engineering team at the same time, there is no more space for heroes. You should start thinking proactively, not just fighting with fire all the time. The company cannot hold breath whenever you deploy things on production. You cannot spend half a year looking for coding rockstars who will spend another month or two in your on-boarding process.
You need juniors, well-motivated, hungry for knowledge, ready for challenges that very often relieve your tired heroes. They will make your team healthy and antifragile. You will find and hire them in weeks.
If you can onboard them in days, you are already there. If not, work hard to make it happen. It will pay off surely.
This blog post was written base on my experience in working with people on different levels in their career ladder. A couple of years ago it was only senior software engineers who could publish apps on App Store or Play Store. Only the most skilled people could build new product features independently.
Today, one of our KPI says — “1-week onboarding for an intern” (our new-joiners pushed code to production within the first four days). Our deployment is fully automated, so it is expected from juniors to take release captain role in turns with any other engineer.
The same with product features delivery — becoming a mid-level software engineer to have ownership of features is too late for us. All of those aren’t just because we have high expectations for software engineers. It’s because thanks to feedback from juniors, we could simplify processes and decrease the entry-level for our tech stack.