DEV Community

Susanne Schmidt
Susanne Schmidt

Posted on

Onboarding - how to make it a really good one

I recently started a new job at a German company and experienced on of THE single best onboardings I ever had in my 25 years working as a developer/administrator.

After I applied (simple email, no silly forms), got hired (timely and NO whiteboard interview silliness) and signed my (completely normal, unsurprising) contract, I got an email from HR, welcoming me and telling when and where to arrive for my first day.

When I arrived on my first day, everything was ready and prepared for me. I found my desk, my display, my gear and some company swag at my place, making it look like a little pile of birthday presents waiting for me.

Me and another (non-technical) hire went to get our first session with the HR department handing us a nicely looking lesson plan for our first couple of days, a pen and a notebook (such a simple gesture so that you can actually take notes), a list of important accounts, our keys and a bunch of paperwork (it's a German company afterall ;), welcoming us and showing us around to each and every department, introducing us to everybody.

After we were done, we wisely got the barista lesson for the industrial strength coffee maker. ;)

The real quality of the onboarding reveiled itself over the course of the next days when I and the other hire went through all the necessary tools, procedures, dos and donts of the company and company-specific legal issues. We went through three days of lessons, lectures, presentations and show and tells.

We got handed our laptops and installed the most important stuff under supervision and with a basic lecture of our security procedures. Under watchful eyes of the security department we created all the accounts necessary for all inhouse tools and applications. As a technical hire you might think "meh boring, I know this!" but I value highly if a company actually bothers to make "security" transparent for non-technical people and not just assumes that everybody can just deal with GPG. We left with lots of assurances that the security department is always there for questions and help.

We went on with lessons of all kinds of tools the company is using - ranging from the usal calendar tool, to emails (more security lessons here), to bugtrackers and ticketing systems - the whole range of "stuff" every technical company is having. Everything got explained to us in its basic use, how it fits in our procedures and who is using it what for exactly. During an introduction to Jenkins I realized that each and every company I worked before simply assumed (or even expected) that people just "know" how to work these kinds of tools and nobody ever bothered to actually do a basic show and tell. Yes, developers should know "tools" - but are they really supposed to know all YOUR tools exactly? Almost everybody (almost..) is using versioning these days - but not everybody is actually using Git, for example. So what if the company is using Bzr? Or Mercurial? So you give people a 15 minute overview and bring them up to speed and it's done, they can move on and don't have to sit down for two hours of googling "how to do this git thing in bzr".

Over the next couple of weeks I've realized that this is really the first company who acts on the - rightful - assumption that nobody knows anything and therefore they teach everything. There is so much "OF COURSE people KNOW that!" going around in technology and tech companies and startups that many of them make their first week feel like a semi-hazing initiation rite where you get thrown into the Jira-pit and have to "somehow" find out where all the repositories are, who is doing what and what tools are in use - set aside how to deal with the pile of code you're usally faced with.

The general onboarding ends always with a visit to the data center (more security procedures) - unless you flatout refuse it's mandatory for non-technical employees as well and it is very well received because it makes the rather abstract ISP-like business "tangible" when you actually get to see the machines.

Part of the onboarding is that one of the bosses sits down with you for an hour and explains the business and some ideas to you and gets to know you a bit more. Part of the onboarding is ALSO how the project managers work and how we deal with customers and what we really do for them and who they are - so you get some more "corporate" lessons as well.

As I'm part of a central department as a more devopsy developer I got passed around through all technical departments for half a day to get introduced to their work - I've never gotten such a dense overview of internet networking, managed hosting, cloud computing, automation, deployment, architecture and "normal" software development on a rather large scale and I went home every day completely (happily) exhausted by the sheer amount of (pretty cool) tech to digest.

In the end, all that was left was a small introduction of how my team does their procedures and such - how should a ticket look like, what's the commit policy, how do we work and such - really just a list of details "how we do it".

I dealt with little to no onboarding before and usally found a way to actually get to work "somehow" - but the sheer efficiency of this onboarding and of course the resulting sensation of being properly introduced into a pretty huge business makes it quite clear that companies should really bother to do an onboarding and do it WELL.

How are people supposed to know "how you do things" if you don't tell them? How are people supposed to be productive fast when you let them poke around on their own until they (often even accidentally) find out what to do and where to do it? How are people supposed to do "the right thing" - whatever that means to your company - if you don't TELL them?

Efficiency and professionalism and productivity aside - everybody always claims that employees are oh so important and then you realize that your new company doesn't even bother on a small scale of simple, basic politeness and some good old-fashioned hospitality - making people feel welcome and making sure they have everything. Another company I worked for had a CEO who really LOVED chocolate and as a result everybody got a half a KILO of chocolate in their company goodie bag - that is certainly SOME pillow mint I got to make my arrival welcoming.

Some companies basically let their employees just stand in the hallway with their dripping coats still on, expecting that they somehow find the wardrobe and the way to the dining room where they just grab a seat after realizing that they need to fetch the fork from the kitchen and search for the knife in the drawer with the silverware and oh spoons we totally forgot and dinner isn't ready yet anyways.

And really.. "Oh dear, I got a too good introduction now I know too much! - no new hire ever. ;)

Latest comments (3)

Collapse
 
guitarkat profile image
Kat

Well, I just learned a bit because I know that feeling all too well... or when things are haphazard... where do I even start and be effective with the team, am I right? Where do I fit in exactly? Role helps, but doesn't cover everything either. Can't assume a certain process in one company to another either as different ones have different needs, etc.

I like the idea of being friendly and not trash talking the new person behind their back, too. It is difficult to fit in for anyone in the first place, I'm sure trash talking the new person doesn't help. It feels crummy and you can feel the "odd one out" vibe. Even in a team of devs somehow. It's bad and devs should be held accountable for anything like that.

So essentially to counter act any "newness" feels (that can feel horrible at times), I'm determined.

Thanks for the post! Super helpful!

Collapse
 
aggieben profile image
Ben Collins

Thanks for the writeup - this is really a very good outline.

Collapse
 
jess profile image
Jess Lee

Such an important task that always gets overlooked!

With every new job I walk into, the onboarding has gotten better and better, but it's still never great. I recently left my position as a PM and did my best to provide all the info I wish I had when I first started - things that would have made me actually 'get to work' way faster.

Little things like...which slack channels to join, what reminders to set, common questions you'll get asked, specific documentation to read over before you dive in, etc...