Pre-onboarding, remote pairing, and daily feedback 💡
Monday Ideas — Edition #82
Hey, Luca here! Welcome to the Monday Ideas 💡
Every Monday I send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
Paid members also receive a long-form, original essay on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider joining 1400+ engineers and get the paid membership!
p.s. learn more about the benefits of the paid plan here.
🔌 n8n (Sponsor)
With n8n, you can build LLM applications and seamlessly integrate them into your business processes through a low-code platform.
Deploy chatbots, personalized assistants, document summarization tools, and more.
Leverage AI and Automation for your datasets, external applications and APIs — n8n is a source-available platform with 35,000 GitHub stars, and is recognized as one of the top workflow automation platforms for technical users.
1) 🎒 Start onboarding before day-one
Your onboarding process should start right after the signing. Waiting until day one is not only inefficient — it is risky too. As Gergely points out:
Many companies are losing candidates after they sign the offer because the employer stops communicating with them. Then, as a cold shower, the candidate emails the firm, revealing that they’ve accepted another position and won’t be starting.
When the candidate signs it means you have built some momentum. Build up on it instead of wasting it.
Here are three things you can do before the new hire starts:
🗺️ Let them know about the onboarding plan — anticipate what the onboarding will look like. Get them excited about joining. Based on their availability, send some material in advance for them to look at.
💻 Ship hardware — as Andrea from the community points out: “make sure the equipment (computer, monitor, accessories, ...) is ready for day one. Especially now, due to the supply chain issues, let your IT department know the specifics of the computer asap so they can arrange that on time”.
🔑 Create all the accounts — having all of these ready on day one makes you save time and also makes for a great first impression.
Good onboarding makes an incredible difference in the impact of new hires — and their retention. I have written more about it here:
2) 👯 Pairing makes remote better
Many companies are reluctant to adopt pair programming because they believe it doesn't fit well with remote. Here are two typical arguments about it:
Async work — “remote is about async, so any practice that requires people to work at exactly the same time is bound to be inefficient”.
Physical interaction — “pair programming only works if you are sitting side by side. Otherwise it's just a long, uncomfortable call”.
Let's debunk both, starting by noting that some of the biggest proponents of pairing, like Thoughtworks, GitLab, and Github, are remote-first companies.
In a remote environment, pair programming is one of the best things you can use for two programmers — Jason Warner, ex CTO @ GitHub
This is not casual. Counterintuitively, pair programming makes remote work better in many meaningful ways:
1) Async work
A major fallacy about async work is that it implies you should never have meetings or sync collaboration. But these are still valuable. It just means you should be mindful of when using one mode or the other.
Pair programming, in particular, enforces accountability and helps you not get stuck when you face a challenge.
Ronald from GitLab says 👇
Working in isolation, without the distractions of the office, is great when you're in the zone. "It works until you run into a difficult problem to solve," says Ronald. "Spending three days on a problem, before getting to the single line of code that solves it, sucks." If you find yourself not making any progress on a challenge, it's probably time to pair.
2) Physical interaction
If the major drawback of remote work is the lack of human connection, pairing makes for a chance to get closer to each other. There aren’t many ways to build meaningful work relationships from remote — pairing is one of these.
Also, pair programming tools are now leaps and bounds better than what they used to be. This can make remote pairing even more effective than pairing on site, because it is easier to avoid distractions with headphones on.
I wrote a full article on how to do good pair programming a while back 👇
3) 💛 Give one piece of feedback every day
The best time to give feedback is on the spot.
The closer you are to the action that generates the feedback, the more context both you and the receiver retain, and the more clarity + alignment you create.
Giving (and receiving) feedback is a muscle: it is uncomfortable to train, but the more you do it, the stronger it becomes.
So, try to force yourself to give at least one specific piece of feedback every day. Developing this habit is incredibly powerful:
It makes you more attentive of other people’s behaviour.
It develops your own introspection, by making you reflect on your own judgement.
It creates a virtuous cycle where you create stronger relationships with your teammates and supercharge their growth.
Brendan, founder and product manager, shared his take on the community 👇
Give feedback frequently (i.e. multiple times a day — it should be a non-event), that is mostly positive (~70% is ideal) and actionable (specific and objective).
Formula is something like “Can I give you some feedback?” (And respect the answer), then “when you <objective and specific action>, <objective impact of that action>
An example might be “when you move a small bit of complex code into a method with a clear name, like you did here, it’s easy to understand what the code is doing and why.”
I wrote a full article about giving good feedback:
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. 1400+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
I redesigned the entire onboarding process for a substantive unit within a English police service. Of course it was totally ignored. No doubt itvwas pillaged by avertly ambitious career advantists and used to show how great / gpod they are. But i think most folks stumble along. Tripping over hurdles others build.