Software Engineering Onboarding: Getting Up And Running Within 1 Day.
I’ve talked to so many software engineers who have shared their horrible stories on how they started new jobs in different places. When I heard about some of them, I thought they surely must be exceptions, but after digging a little bit more, I noticed that these stories have patterns and there seems to be a lot of negative ones. Fortunately, there are positives too!
As a software engineer, I have always valued and judged the entire company during my first days by looking at how the onboarding process looks like. If you are like me, you want to be useful from day one, without waiting another 89 days to contribute positively to the organisation. Since my role is no longer about executing but leading, I am in a position where I want to give such a possibility to people who are starting to work within my team. What is most important is that there is no “one size fits all” approach, and different people will need slightly different things. I mean, the process cannot be rigid, but as long as it fits within the general framework and allows people to decide what they need to be successful in the new position, they can do things at their own pace. These early steps also give me the best insight into how well a person fits into their current role, and with the rest of the team.
So let’s dig a little bit more into what the bad developer onboarding process might look like…
How getting it wrong usually looks like
Policies, legal stuff and other useless paperwork.
The biggest offenders in this space seem to be (almost as always) large corporations, where the first week is often spent on “just getting comfortable,” which translates to doing nothing because they have no time for you right now. You won’t have time either, as all you should do is spend the next 40 hours reading 200 policies about things that you don’t care about or that won’t apply to you, but they cover corporate butts in case something goes wrong. You end up watching random tutorials, introductory videos, reading documents, guessing answers in quizzes, signing paperwork, and hoping for this nightmare to end as soon as possible.
Starting a new job and hearing that you can’t write production code until you finish your probation period.
How the hell is such a company going to evaluate you, your engagement, and skills if you can’t write any meaningful code? This approach is not acceptable, even if the company is one of the biggest and most regulated banks in the world. It’s just ridiculous.
It takes week, or even two to just setup local development stack.
Developer experience is extremely important for team satisfaction, efficiency, and happiness. Everybody should want you to start contributing as soon as possible and not end up frustrated and annoyed. I’ve been there myself once, and as soon as I finished setting up the machine, I spent another month rewriting the local stack so that next time it only takes 2 days, not two weeks, to get it running.
Your probation period = fixing bugs.
It feels like new starters often end up with all the tasks nobody wanted to work on — all the bugs and mess that have been created in the past are now thrown at you, and you have no idea how, what, where, or even why. This is another way of creating frustration, although in certain situations it might be a good idea. A lot depends on your skills and experience. As long as this period doesn’t last more than a few weeks, it should be OK, I guess.
Being forgotten.
You won’t believe how often I’ve heard stories about joining a company and doing absolutely nothing for days or even weeks. A senior engineer gets assigned one small task to complete in two weeks, asks for more work, and is bounced around between different people, making no progress. If someone experiences that and leaves after two months, I would only ask, “why did they stay so long?”
I’m sure there are more things you could think of, but these are the most common and familiar things to most people. Whatever they’re called and in whatever form they come, the outcome is mostly similar: a waste of time, lack of engagement, boredom, and missed opportunities for both sides.
The Rules of Fun
A little while ago, I wrote an article covering “The Rules of Fun,” which are not only part of a good onboarding process but also an important guideline about values everyone should become familiar with when they start.
Check it out!
Working with new team members purpesfully from the day one.
For years, I’ve been bringing new team members into companies with already planned work. It helps them to tackle problems right away and learn something meaningful from the moment they set everything up. These are small projects that bring value to the team and help us move forward. Let’s say something that can probably be done within 2–4 weeks, although I had a situation when a new joiner worked on a significant API implementation that required setting up new architecture and writing a whole new application, taking 5 months in total (but that was quite an exception from the rule).
A specific example how that worked recently
Back in December 2022, we had a new backend engineer join our team, and his first task was to write functionality to log major events across the application. These logs were supposed to be saved with some extra data when specific things happened, such as creating a new business, adding collaborators, buying products, etc. It was a great wayfor him to get an overview of the whole application, create something useful, and become familiar with almost every API endpoint in our stack. A month later, a junior frontend developer joined our team. His first task was to write the frontend for all these logs (exposed via API) and display them in the customer’s account as Activity Logs. In both cases, the initial changes to the code were written within the first week, PR’ed, and went live the week after. The rest followed shortly.
Why it is important to me?
People are smart and will figure things out faster than we think. Having them work on a project allows to take control over how things will be done, creating an opportunity to interact with everyone around and learn from them. Although the probation period is 3 months, usually after the first month, I’m pretty certain whether I want to work with someone or not. That’s powerful, as the first performance review is supported by real-life examples, a lot of feedback from other team members, and meaningful work done.
Writting code is not the only thing
Their first and most important job is to suggest changes to the onboarding process, fix any inconsistencies, and propose improvements that will make life easier for the people who come after them. It’s a typical “boy-scout” approach of leaving the playground cleaner than they found it. I’ve written about it a bit more in my previous articles, so I won’t go into too much detail here.
Good onboarding process is:
- Start should be short, hopefully not more than a day.
- Contains little amount of boring legal stuff.
- Supported by one of company’s seniors engineers as their prioritiy to help and guide.
- Meanifgful projects from the day one to create value and accelerate learning.
- Clarity in expectations for the next week, month and three months.
At the end, send a short survey and ask for feedback. What was good, what sucked and how things can be improved in the future.
