47 lines
6.4 KiB
JavaScript
47 lines
6.4 KiB
JavaScript
var __defProp = Object.defineProperty;
|
|
var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
|
|
var __getOwnPropNames = Object.getOwnPropertyNames;
|
|
var __hasOwnProp = Object.prototype.hasOwnProperty;
|
|
var __export = (target, all) => {
|
|
for (var name in all)
|
|
__defProp(target, name, { get: all[name], enumerable: true });
|
|
};
|
|
var __copyProps = (to, from, except, desc) => {
|
|
if (from && typeof from === "object" || typeof from === "function") {
|
|
for (let key of __getOwnPropNames(from))
|
|
if (!__hasOwnProp.call(to, key) && key !== except)
|
|
__defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable });
|
|
}
|
|
return to;
|
|
};
|
|
var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
|
|
var stdin_exports = {};
|
|
__export(stdin_exports, {
|
|
default: () => _2021_10_28_how_to_onboard_new_software_engineers,
|
|
metadata: () => metadata
|
|
});
|
|
module.exports = __toCommonJS(stdin_exports);
|
|
var import_index_10ac95e2 = require("./index-10ac95e2.js");
|
|
const metadata = {
|
|
"title": "How to onboard new software engineers without paying high interest",
|
|
"author": "Thomas Wilson",
|
|
"date": "2021-10-28T16:03:00.000Z",
|
|
"slug": "2021-10-28-how-to-onboard-new-software-engineers",
|
|
"draft": false
|
|
};
|
|
const _2021_10_28_how_to_onboard_new_software_engineers = (0, import_index_10ac95e2.c)(($$result, $$props, $$bindings, slots) => {
|
|
return `<p>In the past four months I\u2019ve hired about five software engineers (including interns). So I\u2019ve been thinking about how we onboard new engineers to the team. This has been especially important because over half the engineers have never had an engineering job before, or even a job as a university graduate. </p>
|
|
<p>This means that onboarding isn\u2019t <em>just</em> about introducing someone to the company or the engineering team, it\u2019s about bringing people into both their first \u201Cproper\u201D job.</p>
|
|
<p>It feels awesome that I can make someone\u2019s first experience as a software engineer so good. Or at least have the <em>potential</em> to do so. </p>
|
|
<p>Tell you what doesn\u2019t feel super: the onboarding process. It takes a lot to introduce anyone to the way that professional software engineers plan, do, and think about work. It means that my time is spent teaching, not doing. And while teaching <em>is</em> doing, I definitely notice a loss of momentum and bandwidth in the (already quite small) team.</p>
|
|
<p>A new engineer will land in your team anywhere between 0-90% ready to start contributing code to production. The goal of an onboarding process is to get that slider to 100%. </p>
|
|
<p>I argue that slider is tending towards 0% unless you\u2019re effectively onboarding them. That is, if you bring someone onboard and then make cursory efforts to keep them get them up to speed, they\u2019ll slowly grind down to 25-50%. </p>
|
|
<p>I also suspect it gets harder to move this slides close to 100% over time. Onboarding is like a high interest debt: if you\u2019re going to pay it, you\u2019ll pay less if you pay it quicker. </p>
|
|
<p>In thinking about onboarding in our team, and in our company, there are a handful of insights that I think are worth sharing explicitly.</p>
|
|
<p><strong>Cook from chilled not frozen</strong>: If someone comes into a new job knowing the bare bones of the job (anything that\u2019s in their contract, who their manager is, and where they\u2019ll be working) ten they\u2019re coming in frozen. There\u2019s been no progression between the end of the interview process, and the start of the working process. I (very purposefully) run a pretty high-touch interview process, and by the time a candidate receives an offer, there\u2019s been some good rapport built between us and them. Making sure that the candidate knows exactly when and where they\u2019re expected in on their first day is table-stakes. Defrost it even further by setting clearer expectations and timeframes. Bonus points if you can CC their colleagues into these emails. </p>
|
|
<p><strong>Do it in person</strong>: we\u2019re a remote-by-default hybrid engineering team. Honestly I think that works great for us[^That\u2019s not to say it\u2019s easy. Remove work comes with its own challenges which are real and can slowly strangle a company or team] but onboarding should be done in-person, or as close to synchronously as possible. There are just so many little things, like using new Browser, using Slack not Teams, MacOS not Windows, that can make \u201Csimple\u201D things deceptively hard. If you\u2019re doing something in person, or synchronously, you can put a real early stop to some rabbit-hole chasing. You also get the best feedback possible for improving your onboarding process.</p>
|
|
<p><strong>Read from a script</strong>: Despite doing it in person, have a really clear (ideally ordered) checklist of things that need to be done on the very first day of onboarding (accounts to create, software to download). New starters should have access to the checklist, but the checklist is not the interface. You, a human being, are the interface. Allow someone to synchronously ask questions, send emails and messages on the new starter\u2019s behalf.</p>
|
|
<p><strong>Have many checklists</strong>: I\u2019ve written three lists for onboarding new engineers: accounts and software, a list of people they need to arrange meetings with, and the code deployment pipeline. Each of these have different time frames and purposes. Break things up, instead of having one big old long list. </p>
|
|
<p><strong>Complete the checklist ASAP</strong>: Focus should be on getting a new starter to the end of all the lists ASAP. Accounts and software should be as as close to complete by the end of the first day. We aim to have an engineer go through the deployment of a bugfix/quickfix ticket in the first two days (sometimes three days), and by the end of their first week I want them to have events in their calendar to meet everyone they need to.</p>
|
|
<p><strong>Force one-ones with the entire business</strong>: We\u2019re an engineering team in a highly ops-focused startup, and we\u2019re hybrid remote as a team, but distributed across three cities as a company. This means that the chance of water cooler chat is pretty low. I think there\u2019s incredible value in having engineers meet as many members of the team as possible, across as many functions as possible. This is especially important where internal staff are also users of the software you\u2019re building.</p>`;
|
|
});
|