With the market being so hot right now for senior developers and experienced applicants, it’s undoubtedly a hard time to be an early-career developer in search of a new job. So, it makes it especially important for the rest of us to ensure that early-career engineers can be set up for success so that they can thrive and pass on what they’ve learned to the next generation of developers, keeping up the nice cycle of knowledge sharing embedding in it the new technologies and best practices that inevitably will arise.

The world through their point of view

Everybody was once a junior, but, many of us barely remember exactly how it all started. Every person’s path is different and times change very rapidly when it comes to software engineering: what was great 5 or 10 years ago might not be so applicable anymore, so, as a result, being an early-career engineer today will feel very different from being one 5 or 10 years ago. As a person with limited experience, it can be daunting to start a new job due to lack of exposure and also a feel for what you can accomplish technically. Without a baseline to measure yourself against (your past self will be the best one, but, that requires some bootstrapping first), you will inevitably end up looking around your new team and gauge its dynamics and see exactly where you fit in the middle of it. This will only be reasonable to you because, it’s your first job, you don’t really have a baseline of things to look out for, so you hold on to the few datapoints you have - your new colleagues.

They will likely have been involved longer than you with the company, the product, the people and with programming itself, so it will seem like you’re falling behind before even getting started, but, the truth is, you just lack some practical experience, and, this is the time where being set up for success can make or break your career both in your current company and even in general, in case things really go wrong. So, what can more experienced developers do to help with this?

How to set up early-career people for success in your company? Let’s see a few things we can do.

Setting up for success: an ongoing process

Success for an early-career dev or anyone starting at a new company, can be easy to measure: did this person manage to complete the onboarding successfully and be a productive member of the team in a relatively short amount of time? Is this person happy by the end of this process? Does this person have a clear understanding of their role within their direct team and, additionally, in the organization in general?

These questions are easy enough to answer after a few months by both managers and developers, and, simultaneously, they’re also a good way for evaluating, as a company, what can be improved in your process to make sure that people really are being set up for success as soon as they join a team. It’s important to clarify that this should not be measured discretly and it should feel more like a continuous process that can grow and change over time as people come and go.

As developers, we value technical expertise and formal processes that can be followed to help us reach our goals but we also need the time and space to explore, learn and foster our creativity within the tasks given to us.

Combining both of these worlds and wrapping it all with good and updated onboarding documentation is almost an art: it’s different everywhere, it’s opinionated, it depends on the size of the team and the company and it’s pretty hard to get right from the get go. So, let’s look at a list of points that can help streamlining this process, or, at least, guide people into trying out new things.

Onboarding documentation

Having an onboarding process in place is very important: in the midst of all the chaos and everythinng being new, having a central process that new people can follow can really make a big difference in how they adapt and adjust in their first few weeks, which in turn, will dictate (or not) their success over a few months.
This doesn’t even need to be very well-defined: pointers to relevant internal wiki links over Slack and having a more technical set of markdown documents in the repo, next to the code, can be a huge force multiplier for someone just starting out. If possible, also detail a little bit how things work in terms of testing, deploying and code reviews, and, when put all together, you will have a nice, complete package that new joiners can follow.

In addition, also ensure that new people document any additional questions that they have and have them completing and extending the documentation, improving your onboarding process while simultaneously giving them some simple tasks to build up familiarity with the codebase. Everybody wins.

Psychological safety

Psychological safety could be a topic on its own, and, there are endless papers, blog posts and videos looking into its roots, what it is, how it can be applied at scale in large organizations, etc, etc. I will just take a much more practical stance here and put it in practical terms: anyone in your team, and especially new comers, need to feel free to ask questions and raise concerns without fear of being frowned upon or cancelled. It is a natural part of an onboarding process as well as the process of joining a new team to ask questions and raise concerns. People will join with “fresh eyes” and will always bring a new perspective to the table, so, allowing them to expose it and raise it in a safe environment is a critical part of ensuring that new people feel safe and heard in the new environment they are joining to.

Fostering it can be as easy as having informal knowledge sharing events within the team or company, have and promote ad-hoc meetings to discuss specific issues and encourage experimentation and testing of different approaches to do the same thing. It’s sometimes the unwritten rules and small details that can real “show” to new people if psychological safety is applied in practice or just on paper.

Integrated devOps inside development team

This will be prevalent practice and almost a necessity in smaller companies or start-ups: there’s simply not enough people to have and build a dedicated full-on platform team or devOps team, so, as a result, this means that the few devOps experts within the company will eventually end up delegating some tasks and sharing some knowledge with the development team, and, as a result, this will knit together a lot of the operations and the development, which means that a new person joining will have immediately a much broader view of how everything works while staying within the scope of a single team which can be very valuable. Again, this may not be applicable to all companies and all teams, but, where possible, is a great way to help people growing into the entire stack in a more comfortable fashion.

Product context

In a vast majority of companies which provide a product to customers, developers will need to work and develop features to support that product: fix bugs, extend it, adapt to client’s changing requirements, sunset features if needed and much more, but, the common factor is that it’s all about the product. There will be product owners to align with and, in general, the expectations within the company will be that the development team will always be working towards improving the product.

However, it’s very common for developers to just jump in head-first into the more technical work, before getting to know their own role and position in terms of product context, i.e., they need to know exactly why they are doing this technical work in particular instead of that one. This understanding can be gained by having product people, during the onboarding period, giving developers context about the product in terms of the clients, the use-cases and how it works. Equipped with this knowledge, people will be in a much better position to judge and contribute in a meaningful way towards the development of the product, because they will be taking or refuting opinions with much more information. This matters.

Pair programming

Pair programming can be useful to have in place during the onboarding period for new people, especially if they play the role of the more passive person: they can watch and support their new, more experienced colleagues with simple suggestions and ideas, which allows the new people to get a feel for what is acceptable or not, what’s considered important or optional, what’s acceptable or not. In a sense, it’s a simple way of sifting through some hoops in a more passive fashion than when compared for example, with going through those same hoops in a code review where things can feel a bit more personal.

By pairing, a new person will immediately spot some flows, some ways of working, what needs to be tweaked and where to run tests locally for example, how to trigger a pipeline, etc. When this is combined with having good documentation, it makes it very easy to make a person feel comfortable around a codebase.

Stretch tasks

By the end of the first months, and, after a certain knowledge and familiarity has been gained, it’s a nice idea to have what I like to call “stretch tasks” or maybe an “onboarding ticket” in place. I define this as being a task that can be just slightly out of reach for a person who is fully new to the team and the company, but, one that is still doable with some help from the right people and with some uninterrupted time stretch to spend on it. It can be a large ticket, or a ticket that requires digging into that new library that nobody had time to look at yet, or a variation of these.

The advantage of this is that when the new person will be working on it, there will inevitably be findings that can be relevant to the whole team or maybe it will provide a chance to improve documentation or even better, foster cross-team collaboration and everybody will benefit from it. These tasks are hard to find, but, it can be a nice investement when readily available to make a new person grow quickly into the team and the company.

Time to let it sink in

Finally, the last point: after all of the above, any person would feel overwhelmed after a few weeks, and, especially on teams where the pace tends to be high, it’s important to have days in the week where a new person can kind of relax and let all the new knowledge that has been acquired crystallize a bit so that a better mental model can start forming. This is quite important especially because that mental model will shape the way the person will work and interact with other stakeholders and also will decide the “areas” where the person will more naturally gravitate towards due to previous familiarity or expertise. So, making offload time so that a mental model can be formed is very important.

Conclusion

This was a short list with some ideas on how engineers can help their early-career peers and new colleagues level up their skills and knowledge in the context of their company in a sustained and focused way that combines product, development and time to get to know the processes, the people and the team. Essentially, a small guide to allow a new person to cover the most ground in the least amount of time while ensuring that nobody will trip over during the journey. As always, comments and feedback welcome.