A guide for the discerning CTO or Engineering Director who knows the value of a 6-month employee turnover rate.
Many people in the software industry believe the onboarding process for new engineers takes at least 30 days. Balderdash! We can’t have people wasting time learning how to relate to one another or -- worse -- figuring out how their skills might make them uniquely useful.
What you need are employees with a proper fear of being fired at any time, who think of themselves as interchangeable cogs in a productivity machine. To get there, you need to make sure your new recruits never learn how others in your company are motivated or what the company's big picture needs really are. That's YOUR job!
Many tyrants underestimate the value of a quick onboarding process for achieving that key level of existential dread in their employees.
In this guide, you'll learn how to shorten that onboarding process to 2 weeks (or less!) and inspire a healthy respect for authority by picking up a few of these easy tips we’ve sourced from various real employers over the years.
Never change your onboarding expectations with the number of people and lines of code in your repositories. Assume that onboarding is going to be just the same for employee 100 as it was for engineers #1, #23, and #99.
Demand they be producing important new features within 2 weeks, setting standards of productivity that haven’t been reevaluated since the company began and all of the projects were greenfield projects.
Copy your onboarding process verbatim from whatever company you were a director of before you were hired here. Make sure all the managers under you feel like idiots for not being magically already socialized to your previous company's culture, so they can efficiently pass that frustration right along to their direct reports!
When people can’t find the documentation you linked to a year ago due to the natural forces of entropy, send them on a days-long odyssey to track it down for themselves. Make sure you don’t account for that time when you consider how long it’s taking them to become productive.
Ignore all turbulence being experienced in your department due to personnel changes. People getting fired or changing responsibilities is no reason why things shouldn’t continue exactly as they did before. Institutional memory is a myth.
Make semi-oblique reference to their salary and/or job title as an indication of their worth as a human being vis-a-vis how long it’s taking for them to implement their first real feature. Teamwork is a zero-sum game, so go ahead and set up implicit competitions between new and existing engineers as a means of motivating people to work harder.
Send all critical feedback or do-ocratic attempts at improving the process directly to /dev/null. We don’t have time to update onboarding when there’s real work to do.
Remember: all of your decisions have always been perfect. When multiple people trip over the same pieces of company shrapnel, that’s a good sign that everyone is less smart than you.
Your newest hires need plenty of pointless challenges and bewildering antagonism to remind them of their commitment to the company based on how bad it would look to quit now.
For months to come, they’ll be bonding over onboarding with their coworkers over the 20 minutes you allow them to walk out of the office to get lunch and bring it back to their desks.
Because, hey: it’s not your fault you promised 200% more than you can reasonably deliver this quarter!
Top comments (3)
If you’re hiring DevOps or infrastructure engineers, be sure to not articulate or provide any of the credentials you need to do any work.
When they ask, assign them the task of finding out what credentials they need and whom they need to ask to get them. Tell them it’s a great way for the new hire to “get to know our systems”.
Make sure that you have at least five critical authentication systems, and take care that at least two of them are guarded by the pettiest napoleons in your org.
Brutal, wish it were a dystopian future scenario 😕
Low key brilliant. 👌🏻