Remote Engineers

Are junior devs supposed to contribute to production in their first weeks or month?

Yes. Without a doubt.

Junior developers cannot learn by being isolated from the team, and the most infuriating way in which they get to be isolated is by not being included in day to day team activities. You may be thinking watercooler. I am thinking pushing code and having someone use it.

If we don’t include junior developers in the entire software development lifecycle, we aren’t training them to succeed.

There is no better teacher than shipping.

So if you are a junior developer wondering if pushing code that makes it into production is a reasonable expectation, let me reassure you that it is, and that you should be wary of environments where the code you write isn’t being used.

The company should have enough safety rails to protect junior developers from making terrible mistakes or recovering from them, but other than that, writing code is something we do to achieve a goal, and we cannot achieve the goal of serving users if users don’t get to have the features a junior developer writes, or the bugs they solve.

I advocate for getting a tiny commit into production as early as Day ONE of your new job, but if that isn’t feasible, Week ONE is good enough as a goal.

Learning how code goes from your precious code editor and into users lives is a critical skill for engineers At All Levels while they onboard into a new job.

Managing while Remote

Hybrid is coming – how do I make meetings inclusive for remote workers in hybrid setups?

As COVID19 vaccines start to be rolled out, more teams are wondering what it means for them, and more leaders are preparing for a life of hybrid office and remote work setups.

Some teams will be going back to an office for the first time in a year. Other teams will stay working remotely, often with hybrid setups where some of the team is going to the office, and others are staying home.

Before we move on, let’s face the elephant in the zoom call: hybrid setups are like playing in the hardest mode. They are harder to keep running smoothly than a remote-first setup, and they are harder than office-first setups, too.

To do Hybrid Remote work in a way that doesn’t completely obliterate your culture, you need to prepare. You may not like this, but the way hybrid works, or the way I and many others I’ve talked to have seen it work, is that you operate as if everyone was remote when it comes to communications, meetings, and decision making processes.

The good news is that in the last year, you developed some mechanisms to make remote work feasible even if you had no experience with it before. The other good news is that this time you have the luxury of preparing for the changes ahead of time.

The bad news is that just like it happened in 2020 for office/not-remote workers around the world, you will be thrown in the deep end, and you’ll feel like you have to learn a new skill every day to keep your team engaged and operations running smoothly.

Joining hybrid meetings.

Everyone joining from the office should join with their own laptops, their own camera, and their own microphone. This will seem terrible. You will probably not like it. It’s still necessary, because the minute you allow a meeting to prioritize office workers talking over each other and as if everyone were in the same room, you will alienate remote workers who will end up missing half of what is said and unable to get a word in.

Why can’t I just buy an Owl and be done with it.

The temptation to buy an Owl or other similarly cool gadgets for your conference room will be sky high. Unfortunately, once you buy it, people will pressure you to use it. There is a non-financial cost with buying great gear that costs a lot of money; the sunk cost fallacy will hit you and your bosses, and you’ll “experiment” with that gadget until you decide to kick it into the sun or leave it for client meetings only (I have less opinions about client meetings and owl-like devices, in that I don’t care).

If you want the least confusing and more reliable setup for hybrid meetings, you will have to pretend you are all working remotely.

A hand drawn (badly done) picture. It has 4 houses and an office building. All the homes are also offices and are noted as such.
If you manage a hybrid team, you should be switching between home and office based work periodically to test the process out.

But having everyone join with their own laptop/mic/camera seems annoying!

Yes! I know. Been there, done that. I used to run some confidential team meetings with a central microphone while having some well positioned cameras for video streams, because we wanted the privacy of being in the conference room… while it’s a workable compromise, it was still really frustrating for the remote workers on the other side.

I’ve also been on the other side of every hybrid setup I can come up with. I promise you, it’s a lot more frustrating to be the sole person working from home and having to listen to a conversation where you only catch about 50%, can’t see anyone despite them seeing each other, and have to wait for 30minutes to say a word because nobody is paying attention to you at all (if everyone in the office is sharing a microphone, the remote worker will end up forgotten).

Mute by default.

Seriously. I am guessing your team is already used to having to mute themselves, but now it’ll be more important than ever to be good at this.

Have everyone practice their meeting etiquette, and set up agreements to ensure that this doesn’t end up as a forgotten “Hybrid meetings” process that nobody actually uses. Muting by default, and only unmuting to speak, is the way you avoid your remote colleagues from having to listen to a bunch of background noise, getting confused by side conversations, and having the people in the office become even more confused by echo issues.

Avoid bad meetings by test-driving your meeting habits.

Practice. Practice the setup. Remind yourself and others about muting when not speaking. Ensure everyone knows how the meeting will be ran.

You know how remote teams often have meeting guidelines for how to raise your hand, if you should be unmuted or not, and who’s taking notes? You will have to do that for your hybrid setup, too.

Nothing can change the fact that having a distributed meeting feels awkward at first, and doubly so if half the team is next to you and the other half are in their home offices. Despite this, testing the setup makes it less likely that you will fail.

So, do a few practice rounds and adjust. It’s better to get good at hybrid meetings early on. Attempting to use your new setup for the first time when an important topic has to be discussed is a recipe for bad meetings and low morale.

Managers who work primarily from the office need to practice working from home.

If you are primarily working from the office, you will need to find a way to practice being remote, too. It’s important that you don’t just listen (but of course, please do listen) to what remote workers in your team have to say, and what it’s like for them, but that you try to experience it first hand to understand what you are missing, and what you would like to ask people about.

Imagine this scenario. You have been working from the office for a month, and you think it’s going well. Remote workers aren’t complaining too much or at all , so you are feeling confident. You decide to take a week to work from home. When you come back, you find that you missed a critical discussion your team had about the product, because they all had an adhoc, undocumented meeting about it. Now, instead of guessing, you know that the team is struggling to keep their habits, and you can try to fix it.

If you had not taken that week, maybe you would have heard about it a month later, and bad habits would continue expanding, or remote workers would feel increasingly isolated from the decision making processes. Because you did, you can test out the processes as you go.

A word of caution: if you don’t find any issues, this doesn’t mean you’re in the clear. When the manager of a team is remote, people may be adjusting to ensure they include you specifically because of the power imbalances instead of because it’s the default. Be careful of becoming overconfident, and always check with remote workers.

You are still on the hook for note taking.

If you don’t already have a note-taking habit in your team’s meetings, this is the time to get good at it. You can use a rotation to ensure nobody ends up being the unofficial note taker forever, of course. Meeting notes bring more clarity to what was discussed, enable people who were not there to catch up, and help eliminate useless meetings by making it painfully obvious when a meeting could have been a simple 10 minute conversation over Slack/whatever IM tool you use or an Email, or a comment on a ticket somewhere else. If your meeting notes are a literal status update, you will notice. If nobody can agree, the notes will make that obvious. If nobody thinks the notes matter, that may be a sign that the meeting could have been avoided.

If one of us is working from home, everyone is remote.

Get your team aligned on how things will work as you move to a hybrid setup. Don’t wait until the first sign of trouble starts to arise before you have the team about remote-hybrid setups with your team. It’s better to have set clear expectations and involve people in the process. By bringing everyone into the design of this process, you and your team will be better prepared to adjust your meeting etiquette and habits as you go.

For hybrid to work, you need to break old habits. Team wide decisions cannot be made by running into someone near the coffee machine, and decisions need to be documented so that there’s a record to refer back to. Everyone who is working from home will be unable to participate unless you explicitly call them, so keep that in mind before you call for an ad-hoc meeting with 3 out of 5 of your direct reports who just happened to be around.

Fewer meetings. More asynchronous conversations. You are all tired of meetings by now. Try more asynchronous communication as the default. Ensure you aren’t doing status update calls that make everyone feel like they are wasting their time.

If one of is us remote, everyone is remote. Remote hybrid setups will be hard to pull off. You will need to run retrospectives on the setup itself, and to keep an eye on how both remote and office folks are feeling.

You will be tempted to prioritize the people who come to your office. Please don’t. This isn’t “Remote vs people who come to the office”. This is you and your team working out the problems that come up and being open about trying new ways to make your time at work better.

Write down a plan.

It will change. That’s okay. You still need to write down your basic processes and a plan for operating in a hybrid setup. Do that right after you close this tab, if you can, and involve your team in the discussion as soon as possible so that they can help find solutions and bring up problems you didn’t think about yet.

Good luck

Hopefully, this article prevents you from running into some of the mistakes I’ve seen and made myself.

Good luck. 🙂

Onboarding engineering teams

Remote Onboarding 101: tell them Where, When, and How to show up.

  1. Remote Onboarding 101: tell them Where, When, and How to show up.
  2. Remote Onboarding 101: give new employees the power to improve your onboarding documents.
  3. Remote onboarding 101 – “Whenever I reach out, I feel like I’m bothering them”

“How do they know I started my day?”

Your new employee at 9AM, wondering if you already fired them.

Why aren’t they here yet? It’s 10AM!

You, because you assumed someone else told them how to login to Slack.

A while back a friend was about to start a job in a remote organization, and they sent me a panicked message: “It’s 10 AM, I don’t even have the credentials to login to anything… what am I supposed to do?” followed by their brain running wild, thinking that maybe their offer had been rescinded. Unfortunately, that was the first but not the last time I would hear a similar story from a new remote worker.

You went through so much trouble to find a great person to join your team. You sold them on the mission, you evaluated a lot of people, and they evaluated you. They met some of their new teammates. Everyone was excited when you extended an offer, and you were relieved when they signed. But now it’s finally their first day, and instead of excitement about meeting their new team, they are worried because of a problem that could have been prevented with a short e-mail. That’s no way to start a new relationship. You know where I’m going with this…

You can stop this from happening by setting clear expectations ahead of time.

Ensure no new employee has to wonder “Do I still have a job?” on their first day.

Be explicit, avoid panic.

Write a welcome email that they can refer to from their personal email account to get started on their first day. This isn’t the full onboarding documentation, it’s simply a set of guidelines and expectations that help them be confident as they get ready to start working together. The next few points cover what I expect to see in such an email.

Tell them when and where they are expected to “show up” on their first day.

Many remote organizations don’t have a “start time” or specific work hours that they expect employees to respect, so they forget that new people may need clear guidelines. A new employee being told “you can set your own hours” may be happy to hear that in the interview, but the first day shouldn’t allow for that much uncertainty. They don’t really know you, and they don’t know what’s going on unless you tell them. Even if you really don’t have a daily schedule, make sure they have a “check in” time that’s been agreed upon ahead of time. You can do this with a calendar invite very easily.

Ensure someone will be online to welcome them to the team

Someone from their team (it can be the manager, but it doesn’t have to be) should be around to greet them, ensure they are in all the right channels and have access to every critical tool. They should be someone who can offer to answer any questions they may have and help them as they go through the initial onboarding tasks. The way I like to do this is combining the calendar invite for their “initial check-in time” with a 1:1 meeting, so their first hour or two is really about showing up for a call and getting to know each other, instead of trying to read through docs on their own.

Plan for things to fail at the worst possible time.

Let them know what to do if for any reason they cannot log-in to a critical system that they require to start their day. I’ve had situations where someone’s power went off unexpectedly, and it’s really stressful if you don’t know what’s going on.

The solution? Share a phone number that they can call if something is preventing them from coming online.

Tell them what their first day is supposed to look like

I will go over the details in another post, but I wanted to mention the importance of letting people know what to expect on their first day. If you know that X, Y, Z things will be happening, it’s good to let them know too.

Ask for their feedback

The welcome email is a good opportunity to ask for their feedback about the interview process. If you can, add it in the welcome email, and then ask again in your first 1:1. A new employee remembers details and how things made them feel. While they may not be ready to be fully transparent yet, it sets a good expectation, and some people actually share their thoughts once asked.

Welcome e-mail template

Dear $name, 
welcome to $company. We are all looking forward to working with you! 
As your first day approaches, we wanted to send a few important details about your first day to ensure everything goes as smoothly as possible.
Of course, if you have any questions about the process, or run into any problems, do not hesitate to ask.  

# Start time

While we don't have official, company-wide working hours, we recognize that the first day in any company requires more structure. I would like to invite you to join me for a 1:1 at $time on $day, where we will be going over your onboarding plan, getting to know each other, and ensuring you have access to all the critical systems and tools you will need. Please confirm your attendance in this $link, or suggest a different time if you have any conflicts. 

# In case of emergency
If you run into any problems on your first day, please email or call me at $number.

# Gear

You will be receiving your company issued laptop and a welcome package in the mail by $date. Please verify you received everything in good shape, and let me know if you run into any issues. 

# What to expect

We want to ensure you are set-up for success in your career at $company. You will be meeting with me during the first 2 hours, and after our meeting you will have a couple of hours to work on getting your environment set-up and say hi to your colleagues. At $team, we believe in build strong relationships with everyone, not just the people in our immediate group. I encourage you to set up a few 1:1s with peers in other areas to learn more about the organization (don't worry, we can arrange this during our first call). 
Our team has their weekly staff meeting at $time, please join us. You will have an invitation for this meeting in the $company calendar.
I will walk you through the plan for the week, and we will be setting up your onboarding task list together, so there's no need to worry about that yet. 

We know starting a new job can be stressful, so please do let me know if there's anything else you would like to know. 

I would love to hear about your experience interviewing at $company, so please bring your comments to our first meeting (or e-mail me). We want every new employee to have a great experience, and new employees who just went through the hiring and onboarding processes often provide creative and important fixes and feedback that the rest of us missed. 

Thank you, I hope you have a great day.  


Do the little things right.

After the candidate signs the offer and has a confirmed start date, you can use a template similar to the above, include all the relevant information, and send it via email.

You don’t want your new teammate to start their day worried because they can’t manage to log into Slack or get to their Email account… and while onboarding often takes months, even the little things we do have an impact in how people experience the process.

There is more to do before the end of their first day.

I will be covering Onboarding Checklists, Feedback, preparing for infrastructure failures, and other initial tasks in other posts. Subscribe to get more remote onboarding tips in the comfort of your inbox.

Remote Engineers

Your manager can’t read your mind.

As a developer, something that always frustrated me was the fact that my managers didn’t seem to realize the disruption they caused. I would be working on a ticket, and someone would switch me to something else on short notice.

Here we go again. Stash my work. Create new branch. Understand what has to be done. Do it all over again once this one is done. Get asked why the ticket I had to drop isn’t finished yet. Well, because you gave me a different task, that’s why!

So when I started managing people, I’d tell them to let me know if there was any problem, and to raise their concerns early if something wasn’t going to be finished on time.

Time after time, I would be disappointed to hear that someone was delayed on a critical task because they were assigned a second task and dropped the first one.

Why didn’t you tell me?

Oh, I thought you knew!

Ah. The mythical mind reading manager. If you never lead a team, you probably assume information always gets to your manager first, including information about how you will proceed if given an ambiguous instruction like “hey, please fix this ticket” without any other specifications on when it is due, what the priority is, and if you should drop your tasks or not to attend to it.

You may think they know that when they tell you that, you will drop everything and do it.

Unfortunately, very often, they don’t. This is especially true of newbie managers. Maybe because they assume there is enough trust that you would simply push back if you had a problem. Maybe because a PM or other member of the team sent you a ticket and told you to work on it without your manager being made aware. Maybe because they think you will work on it as soon as possible and nothing bad will happen.

They should know better. We should know better. But sometimes, we don’t.

I could write a blog for managers (and I might) about being specific when it comes to assigning work and what our expectations are… but I decided to write it for engineers because nobody ever tells us what we can do to make up for mistakes our managers make, or how to push them to improve, or even how we as developers can be better at asking the right questions to help us be more productive and less overwhelmed all the time.

So. The next time you get a ticket assigned that would interfere with your work in progress, go ahead and ask

“Should I stop working on #this and get started on #newThing right away, or should I finish #this first?”


“If I drop #this, we may not make it to #that deadline, since I have to context switch 3x to work on #newThing and it takes some effort, is that okay with you?”

…or any other question that helps you figure out the best path forward.

It may feel weird, but communicating your constraints is a good thing. Your manager may not have realized the problem that a new task would cause. Thanks to you, they may find a problem they had missed before around workflows, or they will learn how to plan better.

They may tell you that YES, you need to drop your task. Or they may reconsider and reprioritize. But at least you will know, and they wont be able to ask you “why isn’t this other task done” 1 hour after they told you to context switch 😉

They may even learn a thing or two about remote communications. As you do this, you may want to bring it up on a 1:1, and explain how you managed to stop context switching, or why context switching is problematic if it happens too often. I would expect any engineering manager to know this, but if they have forgotten how bad it can get… at least this will remind them to be careful when they assign work.

On your end, by asking this questions you will know for sure when your task is urgent enough to drop everything and when it is only urgent because someone higher up the chain wants it ASAP. This is important, because it lets you make better decisions, too.

Being the person who knows how to dig up important signal even in casual communications is a skill that will be incredibly useful as you progress in your career. You will understand how work flows from X to Y a lot better, and you will learn how to ask better, more insightful questions that help your team make better choices and be more productive.

Let me know if you have had this problem, and how you approached it. I’d love to hear from you at

Remote Engineers

Your team wants you to succeed. Don’t stay stuck.

It was Monday morning, and I’d been thinking about it through my weekend. A developer in my team wasn’t making any progress and now a ticket was delayed.

They weren’t asking for help, and our offers to help them were not being received as we hoped. Instead of accepting the team’s help, they kept saying they were almost done with the task.

All I wanted to do was help get the tickets out, and help them get unstuck.

While I worried about not coming off as a micro manager, and drafted my questions to them in the best way I could to avoid stressing them out while they were delayed, they were worried that they had waited too long to ask for help. “How do I even ask for help?” “Is it too late to ask?” “I wish I had asked earlier”.

It doesn’t have to be this way.

Your team wants you to succeed.

Think about the last time you were stuck and waited for more than an hour to ask for help.

What stopped you? What was your decision making process like?

If you aren’t sure why, and you don’t know how to avoid this in the future, you can use this list to help you decide how to ask for help.

Open a blank document and write down

  1. What am I trying to achieve?
    • Good: send a POST request to the server at /card to create a new card
    • Less good: create a card
    • Bad: finish my ticket
  2. What is happening? (vs what you want to achieve)
    • Good: I am able to submit the card to the /card endpoint, but the server responds with a 422 error despite the fact that I sent all the required fields. The error message says “Validation failed”
    • Less good: I get an error
    • Bad: I can’t create the card
  3. What did I try?
    • Good: I read the documentation on the /card endpoint, and verified that I’m sending all the required fields (name, description, tags). Here’s an example payload: {name: “hello”, description: “Hello I am debugging”, tags: “hello, I, am, a tag”}
    • Less good: I verified the payload I’m sending, it seems correct.
    • Bad: I tried submitting through JavaScript
  4. What research did I do?
    1. list anything you googled (exact keywords help a lot)
    2. list anything you used as reference (docs, notes)

Why does this work?

  • Because it helps you find the problem yourself. It’s similar to rubber ducking, in that by forcing yourself to explain the problem in detail to another person and showing them your work, you often find the solution on your own, or a useful clue.
  • Because if you don’t find the problem, you know for sure there’s not time to waste. You need to go and ask for help.
  • Because when you do ask for help, you can send this same debugging list to your team, and they’ll be able to help you a lot better than if you said “the validation isn’t working for me”.

Your team will be delighted to find out you did your research before asking. They will be better at helping you because of all the detail provided, too.

You won’t have to wait for hours, and stay stuck on a problem for no good reason. If going through the list doesn’t help, then You will know that you need help.

What if I don’t know how to answer the questions on the list?

Then, you absolutely need help. Don’t waste more time. Start by writing down what you can, share it, and explain that you don’t know where to start debugging or what to try. Your team will be happy to teach you, and you will learn more debugging techniques, too.

Onboarding engineering teams

Remote onboarding 101 – “Whenever I reach out, I feel like I’m bothering them”

  1. Remote Onboarding 101: tell them Where, When, and How to show up.
  2. Remote Onboarding 101: give new employees the power to improve your onboarding documents.
  3. Remote onboarding 101 – “Whenever I reach out, I feel like I’m bothering them”

“It’s really hard to get mentorship, I don’t have the support I need.”

new remote developers

Remote or not, one of the first skills we need to teach junior developers is how to ask for help.

Junior devs often fear that reaching out will make them look bad. To help them get over this problem, their team needs to demonstrate they are eager to help.

One the other side of this, we also have to teach new devs how to google concepts, or how to debug a problem before asking for help from a senior engineer. In other words, we have to teach them the skills they need so they can begin to fix the small problems they run into, and we have to give them frameworks or guidelines that make the decision to ask for help feel obvious and like it’s “the right thing to do”.

While trying to teach new engineers how to google their problems, we also need to avoid making them feel like they are a bother if they reach out.

I feel so stupid. I never know when I should ask for help, or where.

– junior dev

Be explicit about expectations

If you want them to ask as soon as they have a question, say so. If you want them to batch questions every couple of hours, say it.

Encourage questions, and set a simple decision making framework for new developers.

“What if I’m bothering them ? I don’t want to interrupt them all the time”

junior dev

It’s common for new employees to feel like they are bothering you… while you are actively waiting for them to please open up and ask for what they need. If they aren’t asking for help nearly as much as you expect them to, and they seem to be getting stuck or taking too long on tasks, make sure you continue re-setting this expectation to ask for help, and repeat yourself until you’re bored of saying it.

If a junior developer isn’t making progress because they are scared of you, that’s a problem waiting to explode in your face. Act quickly, and ensure they never wait for hours just to ask for help that would have taken you 30 seconds to provide.

Give them a framework they can use to ask for help.

I feel stupid. I take up so much of their time. I don’t have the right experience to work on a project on my own.

– a junior dev

Why isn’t the task done? I gave them a really easy bug to fix.

a senior dev, not realizing the junior dev has been stuck for the last 6 hours because their environment isn’t loading.

It helps to give new remote developers (especially junior!) a framework for how to decide they need your/someone else’s help. A simple bullet list can be incredibly helpful to feel confident that you did all you could and you really, absolutely need help to get unstuck.

The goal is to provide the tools for debugging and fixing their own problems, while preventing them from waiting far too long to ask for help.

I have used lists similar to this one, with a bit of context around them. If you don’t have one yet, I recommend copying it or writing your own, then sharing it with the new people in your team as they onboard.

“You will run into problems. We all do. When I have an issue, I have a short mental checklist that reminds me of problem-solving steps, and if I can’t figure it out, I know I need to ask someone for a hand. It goes like this, and I encourage you to have a similar list for yourself and to send answers to the questions when you ask for help, too.

  • Did you google your problem? What did you google?
  • What do you know about the problem? What’s going wrong?
  • What have you already tried?
  • What do you think is happening?

If googling your problem and writing down the answers to these questions doesn’t help, please don’t wait any longer and ask the team to assist you.”

There’s a lot of technical details you can add, but I’ve found that this pretend rubber-ducking on Slack is a good way to get rid of google-able questions while ensuring new team members have the help they need and don’t wait for hours just to ask someone about it.

Remember to mention that Not asking for help is a much more common failure mode than asking for help, and that you will let them know if there’s any problem with their approach, so there’s no need to worry about it otherwise.

If you aren’t explicit about your expectations, you’re creating anxiety that could have been avoided with a simple, quick chat.


In three bullets, this is what helps us get individual contributors more productive, faster:

  • Giving them a framework to decide when and how to ask for help.
  • Being explicit about the fact that you need them to communicate when they need help.
  • Helping them learn the basics of debugging
Mistakes to avoid Onboarding engineering teams

Onboarding 101: learn how people in your organization get paid.

Similar to “Tell them When, Where and How to show up” this is another “simple” mistake with a big impact. It seems so simple to avoid… but if it happens it makes your company or team look incompetent, or simply like you don’t care enough about the new person in your team.

Here it goes. A mistake to avoid:

Not paying the first month’s salary on time.

It’s obvious, right? Someone works for you, you pay their salary. I’d never think this happens until it happened to me.

I was working with a great team, having a great month… and when pay day came, my salary wasn’t there. The first day, I didn’t think much of it. After all, delays may have been the fault of the bank. By the fourth day, I was pretty sure something awful had happened.

It turns out, the outsourced company that handled our monthly salary payments didn’t have my information on file from the first day, and that caused delays on the process later on.

“I haven’t been paid… do you know what’s going on?”

If you do your homework, even if/when this happens, you will have an answer to help them

One day, you’re happily working with your team. The next day your pay isn’t there, and you’re left to wonder if this place is being managed correctly. Who are these people, after all? You only just met most of them.

When you don’t already have a high trust relationship and something like this happen, it can be a big blip on the company’s record. It may not matter right away if nothing bad happened due to the delay, but it won’t be forgotten instantly, either.

Get familiar with the process used to get people paid for the first time.

I don’t work in Finance. I’ve never worked in an HR department. But because of early experiences I had, I’ve often been the person nagging other departments to ensure pay would be sent on time to my direct reports, that their contracts were sent in a timely fashion, and that all the basic things were covered on their day-1 onboarding.

I know how it feels when money is not in your account on the day you expect it. I know what it’s like when your contract hasn’t been signed by your managers, and you’re not sure what that means for you. It’s little things, in that they can be fixed in 5 minutes… but it’s hugely important to get them right, or we are risking breaking people’s trust.

If you’re a people manager and don’t know what the process is to get someone paid on time, make sure you become familiar with it. It can be as simple as asking Finance “Is all the information for Jane up to date in the system? I’m just going through my checklist.” or as involved as asking for a demo on how this is handled. A simple “I’m curious about this part of onboarding a new employee, can you tell me more about the process?” can help you understand the parts of the process that can go wrong, and if you ask “How can I be helpful?” they may even let you know of a simple thing you can do to avoid silly, completely avoidable, but ultimately bad mistakes.

Isn’t this micromanaging another team?

Maybe! That’s an excellent point. And to that, what I will say is that it’s your job to learn how your organization works. If you are fully confident that this could never happen, and you understand how the paperwork moves through the organization? Go right ahead and ignore it.

If you’re not quite sure why and how you get paid? Please, ask someone in HR or Finance to do you the favor of teaching you how these things work so that you can sleep soundly at night. Would you look down on someone from another department if they ask you to explain tech debt? Probably not. I know I love it when I can collaborate across disciplines to improve the organization. This isn’t that different. When I’ve done it, I’ve always been wiser about our org after the fact. You don’t have to be a jerk about it. You can just ask a few questions. The key here is that you’re ultimately going to be responsible for this person’s onboarding and their performance, and it’s going to be on you to keep things running smoothly.

Not paying someone on time is the kind of mistake that looks bad on everyone, not just the person writing the checks.

Humans make mistakes, it’s not a big deal.

I agree. I make mistakes too. Big or small, we all mess up something at some point (sometimes, a lot… I’ve been there!)

It’s unreasonable to expect that nothing will go wrong, ever. But the truth is that paying people on time is a baseline expectation that must be met. As managers, we can be helpful in ensuring things get done on time for our directs.

If it ever happens, and it’s the result of human error, and you understand the process well enough to explain it to your direct report? You’ll be in much more solid ground than if you’re just as confused as they are.

Onboarding engineering teams

Remote Onboarding 101: give new employees the power to improve your onboarding documents.

  1. Remote Onboarding 101: tell them Where, When, and How to show up.
  2. Remote Onboarding 101: give new employees the power to improve your onboarding documents.
  3. Remote onboarding 101 – “Whenever I reach out, I feel like I’m bothering them”

One of my favorite low-effort onboarding hacks is giving every new employee suggest/edit permissions on all onboarding docs, and asking them to improve the document as they go through it.

By lowering the barrier to contribution and giving all new hires the power and encouragement to improve the documentation they are using, you make onboarding a team activity.

Onboarding documents will get updated more often, small fixes will get shipped with each new hire, and your onboarding process will get better every time.

Why does this work?

It works for several reasons. The first and most important one is that you stop relying solely on people who know too much to tell you what’s missing, and instead you start relying on the experts of “is this document any good?” which are new employees trying to learn about your organization.

Teaching others solidifies learning: apply it to onboarding.

Another reason to encourage contributions, and why this works out to generate better onboarding processes, is that making an impact on others is an important part of onboarding and feeling like a fully fledged member of the team.

While the newest member of a team is not going to be an expert in submitting expense reports or the team’s internal culture, they are often a great reviewer and editor for pre-existing documentation, because they are seeing it for the first time, going through each step themselves, and asking their peers and manager for help when needed.

What should a new employee do when they don’t know something?

  1. Read the existing documentation
  2. Reach out to their peers and ask
  3. Verify what they learned
  4. Improve the documentation so the next person doesn’t need to ask

Following a cycle like the one above will help new employees gain more confidence in themselves and their ability to solve problems on their own.

Onboarding that encourages new team members to be curious and proactive about improvements to documentation will result in more early opportunities to reach out to colleagues for clarifying questions, get their feedback, and ask for help.

Getting comfortable asking questions and learning is part of successful onboarding, so it’s a win-win-win.

Each onboarding is an opportunity to do better.

With this small change, new employees are put in a position to have an impact on the experience of the people that will come after them, and they get to do so from day zero.

A note on implementation: depending on the size of your organization, you may be able to (and want to) get more granular with the permissions you provide. I’ve heard from organizations that ask all new engineers to “own the technical docs” for their team, and others where we simply give everyone the ability to suggest changes in Google Docs + permission to send pull requests to technology-related docs in GitHub; with everything in onboarding, local context will dictate how you do some parts of it.


Leaving a job – reflections & timelines

I gave my notice, we agreed on 3 months, and we set to work.

The first month was about setting things in motion, and creating the right environment for a transition. We made an offer to someone on the team to take over my role as CTO, answered all questions that came up, and worked together as an executive team to make sure the next CTO was confident about taking over.

The second month was about letting my team know, and working to ensure that all the basics were covered. We talked a lot about their careers and our time working together, polished brag docs, and ensured everyone had a written performance review and “next year goals” that could be consumed by the new CTO and used fairly. We also discussed how the goals they had could change as they transitioned to a new CTO, and how to keep pushing for the things they care about. I knew there were things people in my team had wanted to do that they never got a chance to really focus on, and maybe this was a new chance for them to figure it out. We also talked about management; how I go about it, the things they don’t notice, the things they do notice. I talked a fair bit about the things I wished I had done better, too.

The third month was where I started to realize the timeline we set-up for me to leave had been perfect to ensure our goal of a peaceful transition. I was hesitant at first, because I dislike long periods where people are feeling uncertain, but it turned out to be a good idea. Having a 3 month transition period enabled me to leave the organization with confidence that I had done all I could, and that the new CTO was more than ready to pick up where I left. It also gave him time to reflect on what he was going to change and how, and which areas are important to him and which aren’t. It gave them all time to prepare as a new team, let off steam, and let themselves imagine how things could be better. I knew change was coming, and I told folks to expect things to change too. Even when the changes are good, (and I believe many of the things that are likely to change fast were good), it’s important to emphasize that this is to be expected, and to give people space to find joy and pride in the changes, and to allow themselves to be part of the change.

It can be hard as a leader to let go, and I did what I could to make it safe and good to align with the new boss, QUICKLY, without guilt or fear or weirdness.

When I took on the role, I spent a lot of time thinking about the things I wanted to achieve, and understanding what the cut-off would be where I’d feel I could leave without guilt.

By the time I was leaving, I was able to tick most of the boxes, even if (of course) I didn’t achieve or did great in many areas I hoped I would.

It’s Wednesday. My last day was last Friday. It still feels weird. I woke up in panic yesterday thinking I had missed my first 1:1 of the day.

Regardless of how weird and new it is to be out of an organization I loved working for, I’m confident I made the right call, and that I did a lot of the things I had wanted to make progress on: shifting the organization’s management style somewhat, making more decisions based on direct user feedback, making support a central piece, giving people more power to enact change, and giving my team a chance to own their areas entirely.

I wanted to add a small checklist of the things I did as I prepared to leave, in case it helps others who are planning a similar transition in a small team.

Comms & finding a replacement

  • Work with your boss on an appropriate notice period: set expectations on how/why this may change. For us, the basics were that if we couldn’t hire from inside the org, our timeline would probably need to change.
  • Agree on communications: decide right away how and when you will communicate your departure to your team. This may change, but it’s good to set a plan right away. In my case I:
    • notified exec team
    • meet with exec team to decide on next steps / how we would replace me
    • asked the (potential, at that point) new CTO about taking over
    • did a context & learning session with exec team + new CTO, then 1:1s and time for him to reflect and accept/reject the offer (he accepted, thankfully)
  • Once that was done, we notified the team. I told everyone who reported directly to me in our 1:1s, and the rest of the team via DMs. This worked out well. I also offered and did some extra 1:1s with folks who didn’t report to me but had things to discuss and wanted to chat. This was good because by the time people found out it was already clear there was a transition plan in place and there was no uncertainty on who would be the next CTO.

Working with direct reports on next steps

  • Ensured everyone had their brag docs up to date
  • Worked with everyone who directly reported to me on perf reviews (it was right at formal review season so this fit the timeline, but I would have done “final” reviews regardless since it helps the new leader know where people stand, and it helps lower the anxiety of the change)
  • Ensured we reviewed all salaries (it was, after all, salary review season too) and adjusted accordingly. This was important because I didn’t want to leave before ensuring we had confirmed salary adjustments. Salary is complicated, and it takes some context to understand how to deal with this, so I didn’t want a new leader to have to do it right away.
  • Everyone had goals for 2021 and things they wished they had done more/less of, and we set those up too in the transition documentation I sent to the new CTO.
  • Encouraged folks to go straight to the new CTO and ask about plans, goals, and changes. I knew it was coming, might as well help folks be comfortable with it.
  • We had (have) an intern from Outreachy, so beyond comms, it was important to also establish ways to contact me as her internship would continue well after I left.

Working with my replacement during the transition

  • I don’t have access to my calendar from work to verify but from memory, the new CTO and I had about 16 meetings, each between 1.5hs and 3hs, during the last 7 weeks of my transition. These were working meetings. We would pick a topic, and go deep into it. Some were technical things I knew more about due to my own context. Some were management things. Others were organizational context on its own that he may not have had.
  • Hiring: we dedicated a lot of time to discuss hiring, and presented a plan to the exec team.
  • Ensured we had discussions about inclusion, diversity, sexism, racism, and how they impact people. This matter to me greatly, as I worked pretty hard to fix issues that still affected my team, and I didn’t want to risk these efforts being ignored later on.
  • Set the tone for the new role and what it entails, explain where things get messy for me, and give him time to reflect on how it would look like for him.

Wrapping projects up

  • I had two important projects to wrap up during my transition that unfortunately had gone mostly to me as the only backend engineer. I worked to ensure I finished the key components, released them, and then transitioned it. While it wasn’t as smooth as I wanted it to be, at least we felt ready for me to not be involved by the time I left.
  • Pair programming on things that were ongoing: we did some pairing on areas of the codebase that the new CTO needed to understand. This was meant for him to be able to  onboard new backend engineers later on, and take care of emergencies as needed.
  • We had a contractor working with us whose contract ended right around the time I was leaving, so I had contact details sent over in case it was necessary.
  • For most of the other projects, because they were owned entirely by people in my team, we didn’t have a lot to do. It was just a matter of ensuring there was awareness that they existed and where to go for help.

External comms

  • I wrote a blog post about my transition, and we used it to announce my departure to external partners.
  • My boss (ED) managed the comms to our board.
  • My boss managed the Twitter comms

This is the concentrated version of 3 very intense months. When my last day came around, everything was ready for me to leave, and it was just a matter of sending goodbye messages and preparing LinkedIn recommendations for everyone I had worked with there.

I’m now taking a little break to reflect and decide what’s next.






FunEmployment log #1 – Gather Town

Gather provides virtual spaces where people can hang out. Similar to the old Guild houses in MMORPGs, Gather provides a customizable virtual world for you and your friends, teams, or any other group you can think to meet online. They provide a limited HTTP API, and are planning to add Web Sockets at some point. While I need Web Sockets for most of the things I’m interested in doing with it, I’ve started playing with the current APIs to learn more about generated map making scenarios.

I did a very small project demo where I get a list of JSON endpoints and generate them into a map (name, tooltip). When you hit X while standing on top, it highlights the related endpoints for you automatically. Ideally, this would happen without any need for user interaction or website embeds (the hack I found for this), but at the moment it’s interesting enough to stand there and think about what else could be done. Broadcasting demos ? A walkable tour of a company’s API? Sitting down with friends to explore technical docs while showing each other the work? Who knows. I’m eager to find out if there’s something here that would help teams learn together.

The SDK Repo is here, please don’t use it for anything serious, I’m just playing around with ideas, it doesn’t even have tests, and I’m not sure if I’ll keep at it or wait for Web Sockets since IDK if this API is going away entirely or not (this point re deprecation, while very obvious, just occurred to me now).

Alt text: I do a walking tour of endpoints, then show the highlight functionality and some code decisions so far (it’s all prototype-y, of course)