My first time building a keyboard, I didn’t have a mental map of how a keyboard worked beyond “well it sends a signal and boom, things happen”.
I had been using a Corsair k60 mechanical keyboard for nearly decade, but for the most part I just enjoyed it and didn’t dig very deep into how things worked.
A corsair k60 with red, bumpy WASD and 123456 keys. The polished steel frame is beautiful and also very heavy and weapon-like.
Then, my beloved corsair stopped working. I was sad, but decided to take it as a sign that it was time to upgrade to something that wouldn’t make my wrists hurt every day.
I wanted an Ergodox-EZ. That didn’t work out, however: the total cost to bring it over to Uruguay would have been ~$800.
Ergodox-EZ -a split ergonomic keyboard. Picture from the Ergodox-EZ website.
I knew the Ergodox keyboard itself was open source, so I tried to figure out how to build one. I didn’t know the basic terminology and struggled to build a model of how it all fit together. I got stuck. Even trying to pick keycaps was a struggle; I didn’t know what type I needed, or which sites were reputable enough to buy from.
I gave up. I broke open the corsair and tried to repair it. For a week or so, it worked! Knowing its days were counted, I made a plan to get a custom keyboard.
My old corsair, showing the keyswitches (cherry mx red) after I opened it up to try to fix it.
Given that I was going to build a keyboard, I decided to explore. I almost got an Iris, but I got overwhelmed trying to choose between different plates and cases. To be honest I didn’t really get why it mattered which one I chose, and I didn’t know if one item was the full pack or just the individual piece. It was overwhelming, and I was feeling tired of looking around.
The Iris: a beautiful split keyboard from keeb.io
One day, as I browsed random reddit keyboard posts, I saw the Breeze. It was perfect.
I am really thankful to the afternoonlabs.com creator and to the community that formed around the Breeze. I didn’t need to know much because the site was designed with newbies in mind. For everything else, there was a small discord where everyone was lovely. I ordered all the components that same day, scared that they’d run out of PCBs.
The Breeze keyboard, from afternoonlabs.com. A stunning split keyboard that breaks the mold with arrow keys and the ability to get a macro-pad from the same PCB.
Two weeks later I had a soldering iron, solder, and some other bits and pieces. The keyboard components arrived from the USA through a courier service.
It was the start of a hobby that has given me many hours of peaceful soldering, practice, and less peaceful debugging.
I know the internet likes to explain things to women so HERE IT IS, YOUR OPPORTUNITY TO EXPLAIN THINGS
I want a soldering kit (mistakes were made), I want it to be cheap (I'm forget my hobbies every 3 months, don't judge), and I want it to sort of work.
Where/What do I get
— rowasc is building keyboards and stuff (@rowasc) March 13, 2021
My soldering iron, back in March 2021. I didn’t have much of a workspace for hobbies, so it’s placed in a random small table that I had. Behind it there is a lot of other stuff. A pretty dangerous setup, really. The left side of the Breeze PCB, with cherry blue mx switches, an Elite-C micro, and a TRRS socket soldered on.Coiled TRRS cable. I was shaping it and testing its resistance still.Bags and bags of keycaps and keyswitches. More keyswitches, cables (usb), and micros
After a couple of days of soldering, cursing, and feeling like I would never get it working, I had a functioning keyboard.
My beautiful breeze, on its very first day. Beach themed keycaps, coiled TRRS blue cable connecting each half, and a USB-C cable
The pretty unusual design of the Breeze, with one side having an extra 9 keys, made it a great first setup for someone who was trying a split keyboard for the first time.
By the end of my first build, I wondered why it had seemed so hard to get started.
All the pieces were really simple. It was just a matter of knowing what was what. I made mistakes, sure, but they were not a big deal. Everything worked.
Not having even a basic understanding of the hobbie’s ecosystem was also part of the issue. These days, I at least know what to search for.
Getting into the hobby made me a lot more aware of my own learning style and methods.
As simple of a build as it is, building the Breeze was hard because I didn’t know the community’s language, the MUST vs MAY rules of building a keyboard, what kind of mistakes you could get away with and which ones were fatal. It was hard because those were all just the very first steps towards being competent at something I had never done before.
The next keyboard would be handwired. A different way, a much more involved process, and yet… it was easier. I could learn more easily because I didn’t feel any anxiety. I didn’t wonder if I was going to fuck it up accidentally; I knew most everything could be fixed if I did fuck it up.
This isn’t a serious post. Just a personal story/recap of what I’m doing to teach my 11yo nephew the basics.
We started with Scratch last year, but both of us got tired of that environment pretty soon. We had a ton of fun making little games, but both of us are low on patience, so any time looking around trying to discover the tool’s weirdness just resulted in two very frustrated people :).
"ooooh, it's like we're sending DMs to the computer" – my nephew has the best takes on coding
— rowasc is so well adjusted and normal (@rowasc) August 9, 2021
A month ago he reached out to code again, so I decided to throw him into “real world” tools. I think using tools that felt useful and real was key to keeping me engaged as a young dev, so I decided to try that with him, too. Given that he asks for a new lesson every weekend now, I think my plan is working 🙂
So far, he’s been digging into HTML, CSS, and JavaScript. We spend most of the time in JavaScript, but I always have small snippets of CSS around for when I see his energy levels go down — the quick dopamine hit from coding a fun animation is a great way to cut a dense lesson on race conditions.
We have only covered the most basic concepts, but I’ve tried to make it fun. He’s learned about `const`, `let`, simple CSS transitions, how JavaScript’s `console`, `alert` and `prompt` work, and how to pull that together to make some interactive things happen.
As I write this, he’s building his first sum only calculator with a `prompt` and `alert` based UI. In between new concepts, I refresh old ones. “Do you remember why that happens?”, and “What will happen when this code runs?” are my go-to questions; I want him to build good instincts for debugging, so I never stop him if he’s heading towards a bug. I’d rather use the chance to teach him how to solve it.
We’ve dug around in the browser’s debugger, using breakpoints and inspect to learn what our code is doing. I think all new devs should be taught how to solve their own problems, and teaching him about debugging tools is part of that.
Back to teaching my nephew how to code, this time with JavaScript/HTML/CSS.
Teaching him JavaScript? not a problem!
… it's getting the kid to read a document/screen/warning without getting distracted that's gonna kill me.
— rowasc is so well adjusted and normal (@rowasc) August 16, 2021
I’ve made sure he learns how to read error messages, too. If you don’t know how to read an error message, debugging feels mysterious. So he has to learn, even if he doesn’t like reading.
As we write simple scripts, he learns about code readability, comments, and documentation. I try to avoid lectures by taking a page from my onboarding habits and meshing together lessons with hands on work. When I have validation that he’s getting the concepts, I introduce new levels of depth.
Today he asked for homework again. I count that as evidence that he’s hooked 🙂
If you’ve taught kids how to code and have any advice, please let me know!. I am sure the honeymoon is gonna be over real soon and I’ll need some actual plans to keep the momentum going.
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?”
or
“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 rowasc@hey.com
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.
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
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
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
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
What research did I do?
list anything you googled (exact keywords help a lot)
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.
“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.
TLDR:
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.
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.
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.
Uno de mis hacks favoritos de para mejorar procesos de inducción u onboarding es darle a todas las personas nuevas permiso para que editen o envíen sugerencias directamente en los documentos de inducción, y pedirles que mejoren el mismo mientras pasan por el proceso.
Cuando bajamos la barrera para contribuir y le damos a todas las personas nuevas del equipo el poder para mejorar la documentación que están usando, hacemos que el proceso de inducción se convierta en una actividad en la que todo el equipo está involucrado.
Da poder, no solo incentivos.
Los documentos de inducción van a ser actualizados más seguido, se van a hacer pequeñas mejoras con cada nueva contratación, y el proceso va a mejorar continuamente.
Depender solo de personas que saben demasiado sobre la organización lleva a que las partes poco claras o con errores no se noten hasta que alguien tiene el valor de decir “esto no me parece correcto” durante una inducción. En vez de esperar a que se animen, está en las personas en posición de liderazo dejar claro que no solo está bien dar sugerencias y hacer preguntas, sino que se espera que tengan sugerencias y mejoren la documentación mientras la procesan. Alguien nuevo tiene muy poco conocimientos de la empresa, lo cual les hace excelentes aliados para detectar si un documento no está cumpliendo la función esperada.
Enseñarle a otras personas solidifica lo que aprendemos: apliquemos esto al proceso de inducción.
Invita a contribuir en los documentos. Explica que mejorar el proceso es una parte important de completar su propia inducción. Mientras que las personas mas nuevas de un equipo no van a ser expertas en como enviar un reporte de gastos, o la cultura interna, tienden a ser excelentes revisando a medida que leen los documentos y verificando que los mismos no tienen errores por medio de preguntas y su propia experiencia de inducción. Están viendo todo por primera vez, paso a paso, y preguntándole al equipo cuando algo no es claro.
¿Qué debe hacer alguien nuevo cuando no sabe algo, o un documento no está claro?
Leer la documentación existente.
Preguntarle a otras personas en el equipo.
Verificar lo que aprende.
Mejorar la documentación para que la próxima persona que se una no tenga que preguntar lo mismo.
Seguir un ciclo como este va a ayudar a que las personas que entran al equipo ganen más confianza en sí mismas y en su habilidad de resolver los problemas que se encuentran en su nuevo rol.
Llegar a sentirse cómodo y con confianza haciendo preguntas al equipo es una parte importante de cualquier proceso de onboarding. Un proceso de inducción que invite a las personas a ser curiosas y proactivas va a resultar en más oportunidades para que conozcan a sus colegas, hagan preguntas, obtengan feedback, y pidan ayuda.
Cada proceso de inducción es una oportunidad para mejorar.
Con este pequeño cambio, las personas que se unen a nuestro equipo estarán en la posición de tener un gran impacto en la experiencia de quien venga después de ellas, y lo que es mejor: pueden empezar a hacerlo desde su primer día.
Una nota sobre la implementación: dependiendo del tamaño de la organización, es posible que se necesiten permisos más granulares en los documentos de inducción provistos. He visto organizaciones que le piden a todo nuevo empleado que se haga cargo de la documentación técnica de su equipo, por ejemplo, y otras empresas donde todas las personas tienen derecho a editar o sugerir cambios en todos los documentos. Cuando se trata de procesos de inducción, el contexto local importa y va a dictar los detalles de implementación.
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?
Read the existing documentation
Reach out to their peers and ask
Verify what they learned
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, newemployees 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.
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.
$hiringManager
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.
I seriously don’t have the energy to spam you, unsubscribe at any time.
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.
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.
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).
I wrote this as my answer to an application question for a remote company a few years back. It’s a bit outdated, but I thought I’d share it anyway.
In a broad sense, to me management is about people and the things that stop them from achieving what’s important at an individual, team and company level.
It’s about understanding and helping solve the issues stopping a team from being in their A-game, which starts with the individuals and ends with the company as a whole. If a team has issues because people are distracted thinking about how bad their CI solution is, or someone is blocked every morning because they aren’t getting the information they need from another department, it’s a manager’s job to find out and help the team come to a solution. The best solutions come from the people closest to the work, but the responsibility of finding and facilitating the resolution of those issues is on the manager; sometimes that means just supporting the team on a decision they made, and sometimes it means solving it yourself in one way or another.
I believe one of the best things you can do as a manager is becoming skilled and comfortable at delegation and facilitation, and always pushing yourself to delegate larger and more important work to the people who demonstrate they can do it. It means you are comfortable looking from outside, coaching people to excel at their assignments, and being accountable for work that you had very little to do with in the day to day.
It’s about delegating authority, rather than only tasks.
You have to be comfortable saying no often and explaining your rationale as needed, but you also have to be able to check yourself and reevaluate If someone comes to you with a concern about a decision you made.
Understanding and communicating the value of what we’re doing so that others have the context to make smart decisions is one of the most high value things you can do as a manager. People deserve to understand why their work actually matters, and they produce much better work when they do.
An effective manager should be comfortable switching between coach and the person being coached, being able to put yourself in a position to ask questions to get to the root of a problem without letting your ego get in the way.
Being a decent manager can mean being aware that you have very little control and still owning up to whatever the team is achieving or not. It’s finding the time to be connected to the work that the team is doing and being able to facilitate decisions, but not letting yourself hide from problems in the comfort of coding. It’s also remembering that your work touches real people with real lives.
When assigning technical leads, take care to put them in a situation where they will succeed easily, especially if this is their first time with a tech lead role. The tech lead role is one of the most challenging roles to go into because you live in a sort of limbo where you are still mostly doing IC work but have much more responsibility.
If it goes badly the first time, you might lose a high potential IC over a project that was doomed from the beginning. Try your best to set up all your new tech leads for success, and eventually you might just get lucky and find your replacement in one of them (you know, for when you’re hit by a bus or a bike or something).
The rewards come slowly compared to individual contributor work, but they tend to be more interesting to me because I can see the impact of my work on people and projects in a more global way. It can be someone finally getting that promotion they have been working hard to get, features shipping with a reasonable cadence when you were struggling to get things out before, or realizing the risk you took 3 months ago by firing someone had a large positive impact on your team’s productivity and happiness.
Engineering management is extremely rewarding, and even though you don’t see things changing on the day to day as much as you do when you’re an individual contributor, you can usually look back a month and find something you influenced that impacted your team and/or your company.
I tend to approach engineering management decisions as I do software development: small adjustments most of the time, big refactors only when the potential long term rewards are worth the risks and there’s no other viable solution.
Like in software engineering, the context in which we make decisions matters. The strategies that make sense in a small, 3 dev team don’t really scale for a larger group. The decisions we make to create an initial prototype to prove an idea are different from what we’d do for production applications, but it’s important to remember that doesn’t make them invalid, it makes them good decisions for the context in which they were made. The same goes for teams. The way you manage a 3-person team is not the same as with a 20-person team, and that’s ok.
[this is a short, not fully developed blog post – consider it “in development”] I’m getting into the habit of learning in the open, and I think part of letting go of the idea that I need to do everything right is allowing my incomplete ideas to be in the wild.
I think a lot about technical debt. What it means, what makes it happen, how we get rid of it. Mostly, I think a lot about the fact that no matter what you do, you always go and create it again.
Debt seems to be a poor analogy for something that occurs no matter what. It’s essentially impossible to not create technical debt, because time passes, and time itself creates it. Software becomes deprecated, packages stop being maintained, a new security patch is released, and you need to change your code.
Technical debt is a great analogy for the fact that you can incur technical debt to be able to get to market at some point. You take on some debt, you plan to repay it. It starts to generate interest. You pay a heavy amount in interest, and if you don’t, it snowballs, until it consumes all available resources. In that sense, technical debt is the perfect analogy. It’s easy enough to explain it to finance, who understand risk management and how to use debt responsibly; they know how to wield debt in ways that benefit the organization, much like engineers often use some tech debt to get ahead. It’s harder to explain to people who have never taken on debt on purpose, who don’t see it as a tool but only a burden; debt, both financial and technical, are tools to be deployed.
But isn’t debt always bad?
Not really. Some technical debt is almost inevitable. What’s not okay is to let it create a ball of debt that never gets repaid. What was a good decision yesterday can quickly become a bad one if nobody takes this resource consuming debt into consideration.
It’s a bad analogy if you think about the fact that if someone offered to take all your financial debt away, swipe it off entirely, you probably would jump at it.
If I offered a magic wand that takes your technical debt away, and you said yes, you would be throwing away a lot of money that you can never get back, rather than finding yourself with a lot more money to spend.
Your technical debt is where your product hides valuable lessons, and to take it away without rebuilding that knowledge is foolish; it’s why rewrites can be dangerous if not done with care and with a focus on enabling progress rather than eliminating all problems.
The fact that a lot of the important things in your product are hidden in layers of technical debt may be the reason that it’s hard to get rid of it; it contains important learnings, important rules of the business, things that you need to understand to be able to rebuild without that flavor of tech debt.
More than once, I’ve seen myself or others attempt to remove important business considerations when we rush to “clean things up” that don’t make sense. A gnarly bug-fix that wasn’t well documented. An edge case fix that took weeks to identify and solve at the time, with code that looks like crap but serves a percentage of your users well. As you refactor, the risk is that you may introduce different tech debt into your code. That’s not necessarily a bad thing. Some tech debt is dangerous, and some tech debt won’t be considered debt for months or years. But you know it’s going to appear. You may not see it now, or tomorrow, but 6 months from now, some new developer will surely point it out, and you’ll be dreaming to rewrite it again.
When I talk about technical debt being a feature, I know many engineers scoff at the concept.
If only management let us do it right the first time.
I’ve seen engineers spend weeks arguing for the correct interfaces, the perfect APIs, the amazing search system they would implement, if only they had the time. I’ve seen managers like myself give them that time. I’ve also found myself arguing fervently that baring a rewrite nothing could save us… and I’ve been wrong on both sides.
With all the time in the world you plan, you procrastinate, you argue with your peers and reach decisions that seem great, perfect even at the outset… solutions that 6, 12 months down the line are not quite good enough.
I advocate for a continuous improvement approach because it’s the only thing I’ve seen that works. Even then, I’ve never seen a team take it to the point where tech debt is swiftly addressed without guilt. I work to get my teams there.
When I think about the future of a tool, maybe 12 months from now, I think I want us to go “ah yea, this bit of tech debt is there because ….” and have a perfectly sane explanation for it. Not “we were in a rush” but “we needed to do X, this was the solution that made sense due to time constraints”. Even better, I want teams to be able to admit: “This was the best solution we could find at the time, but now we know more.”
I don’t want teams to ashamed of tech debt, I want teams owning it, being able to articulate why it exists, being able to articulate how they will address it, and solving it.
I want teams to proudly state that they refactored an old piece of code that caused trouble without the tingle of guilt that the code was there to begin with. I want product managers to ask what the impact of the debt is, and to make decisions as partners, with engineering, on how and when to address it.
I want teams to operate with safety and be rewarded for it.
The signals were there from day one. One of your direct reports asked a question, and Adrian answered with a mocking tone. You told yourself you’d have a chat with him before the day was over, but by the time your meeting is over, they are all cracking jokes together. You shrug it off, thinking it’s all in your head.
By the end of the first month, Adrian has built a new module that got the VPE’s attention. The VPE tells you how impressed she is with the new hire and congratulates you on your choice.
A week later, you notice that Adrian keeps derailing a discussion to shit on the team’s tech stack. He starts talking about migrating the back-end to a new language he started learning last month. You have a talk with him, and for the first time, you see it: he thinks this makes him look smart. You make sure he understands that this is having the opposite effect. He nods, but not even 24hs later, you get a lengthy rant from him in your email. The word “incompetent” is in there. You can’t believe you got yourself into this mess.
The complaint
It only takes 2 months for the first official complaint to reach you.
As soon as you get the message from Felipe, you get a knot in your stomach. He wants to meet today, and you have a feeling that you know what it’ll be about. By the end of your meeting, Felipe has told you that Adrian is not a good fit for the team. He looked disappointed as he told you that he didn’t understand how you let this go on for so long. Apparently, Adrian told Susan that she needs to stop wearing make-up if she wants to be taken seriously as an engineer.
Later that day, you’re sitting down with Adrian, who says it was a joke. He goes on a rant about the good old days, which you have to assume means “2019”, since he hasn’t been in the industry for more than 5 years. You shake your head and explain that’s not an appropriate joke. For starters, it wasn’t even funny. He nods and promises to apologize.
Knowing you can’t go back to your desk until you calm down, you stay in the conference room for a few minutes listening to music. It only takes 15 minutes for Susan to knock. It turns out that Adrian’s version of an apology is “I’m sorry you were offended”.
It’s 5pm, and things seem far from resolved. You bring Adrian back for a candid conversation. If this happens again, you will escalate it to HR. You know HR won’t help you unless they see Adrian as a risk to the company, but that seems to scare them into behaving for a while.
When you talk with your boss, she tells you that since Adrian ships more code than anyone else, the best thing to do is to figure out how to work with him. With a month to go before a big launch, you know arguing against it will put you at risk.
More likely than not, you have a jerk somewhere in your organization.
Most of us have worked with the so-called “brilliant” jerk. This is the person who speaks the loudest and cares about one perspective only: their own.
The jerk is always looking for something to criticize. If they can’t find anything, they will derail all conversations towards the things they want to discuss, like the fact that they really hate the technology choices made by a CTO 3 years ago, or their dislike of the code review process, which they assure you they don’t need to go through because they are very talented.
They don’t have time to help unless there’s an opportunity to bring someone down.
When a junior engineer asks a question, the rest of the team jumps at the chance to be helpful, while the jerk looks for a way to nitpick their word choices. When the junior engineer asks “How do I import a component in the React framework”, they answer “It’s not really a framework” with a snarky link, without even giving them the information they need.
We’ve all been inconsiderate at one point or another, but the jerk will find as many opportunities as possible to bring people down. Their intention is not to teach. They just want to look smart.
Fear is driving you to make bad decisions.
A more experienced leader would have fired Adrian that day, but this is your first time dealing with a so-called “brilliant jerk”. You think you can solve this. You think his contributions make up for the problems he caused. Furthermore, you’re scared your boss is going to think you don’t know how to hire good people. Your brain is spinning, and you feel like a failure.
A week later, Adrian yells in a meeting because someone else broke the build. He seems to have forgotten he caused a major production incident two days ago by ignoring the team’s processes. When that incident brought a client’s site down, everyone rallied to fix it. Not a single engineer pointed out who was to blame. They all worked the incident together, run an incident review, and created action items to lower the chances that this could happen again.
Trust is broken.
A while later, Susan leaves. You don’t have to ask. She’s leaving because you didn’t act.
It’s been almost a year since the first time you saw Adrian act inappropriately. You’ve lost count of the times you’ve had the same conversations with him. He knows he’s safe, under the protection of your own boss and your lack of courage to act. In all those days, weeks, months, your brain played a little mind trick. Once this person started acting like a jerk, you started valuing their technical contribution as if it was the most brilliant code you’d ever seen.
Your team got the message: none of you are as valuable as he is.
Nobody wants to work with a jerk.
When the jerk receives something broken, they broadcast it. But when they push something broken, they get direct, one-to-one feedback from the person trying to work with them. This is how they stay employed. This is how they keep a reputation for being brilliant.
You hear “not-jerk broke the build” from them all the time, but you rarely hear “jerk broke the build”.
Nobody wants to hire a jerk.
You would never hire an incompetent jerk. Every little annoyance becomes a reason to remember how many times they saved your ass in a tight deadline. In those moments, the jerk starts to become not just a jerk, but a brilliant one.
You tell yourself you’ll talk to them once that new feature is done. It can’t be that bad, right?
Is the brilliant jerk really brilliant?
I want to give you a moment to think back on your jerk. The one that’s still in your team, the one that your boss admits “is not that great with people, but is super smart!”. The one who works alone because their teammates gave up on pleasing them.
Think critically. Take your time. If you ignore the impact they have on your team’s morale and just focus on their technical capabilities, are they really that great? Do you need them, or are you just scared of what you need to do next?
I will make a wild bet: they probably aren’t as critical to the company as you want to believe. They seem great when they save you from a last-minute problem, sure. But did they also cause the problem? Think back. Did they really save you? I bet they caused the issues more often than not. That release they just saved? The deadline may have been met without heroics, if your team had not been busy dealing with a jerk’s bad attitude and going back and forth on decisions all month long trying to please him. The deadline may have been reached, if you had fired the jerk when he acted that way towards Susan. Susan may still be here, and Felipe wouldn’t be looking for work as you sit down to negotiate yet another deadline.
What about the really brilliant ones?
We generally want to believe that jerks are brilliant, because hiring and keeping someone who is both an average engineer and a jerk for a long period of time would make us look even worse than we already seem to be. The thing is, it’s very rare for someone who is a giant problem for your team to be performing at senior+ levels in their work, because engineering is a collaborative activity, and the highest performers are those who push their teams further rather than make them dependent on them or bring them down.
Sure, there are some who are truly competent if they can work alone. But realistically, all jerks cannot also be amazing engineers, despite the myths that we have been fed over the years. Even if you don’t account for the damage they do to their teams, it’s just not worth it.
In the end, it doesn’t matter how smart they may be.
It’s not worth it. Stop fighting a lost battle.
Next time you excuse the jerk in your organization, ask yourself if they are a net positive. What would happen if this person gave their notice tomorrow? Would someone in your team fight to keep them? Or would they be counting the days until they are gone?
Is keeping this person in the team so important that you are willing to lose your ability to hire and retain great people? Are you willing to continue to prioritize them over their team’s mental health?
If there’s a chance that you are just making excuses for the benefit of your own ego, it’s time to have a chat with your team.
Your team will respect you more for it. Given enough time, all of us will end up hiring a jerk at some point; what we do about it matters just as much as the fact that we did it. Mitigating the damage is the next best thing if you failed to prevent it. Stop making excuses, and work to rebuild the trust that’s been broken.You will respect yourself more for this, too.
TLDR: from my perspective as a CTO-doing-product-manager-stuff, the key part of building a roadmap is not what the document says, but what I learn and the connections I make through building it and maintaining it. If I just throw a bunch of features in a planner with no clear alignment to the org’s goals and user needs, that’s not a roadmap, that’s a wishlist. I get confidence in our roadmap when at any given point, I can direct people to it and explain how the future we imagine links to the things in the document. From an engineering perspective, I always appreciated roadmaps when it was clear why something was in there, because it told me there was a plan and not just a bunch of unconnected things in a Trello board.
Roadmaps can be intimidating, both to read and of course to create. If they are good, they can be useful in helping stakeholders and users understand where a product is going and gaining alignment as it gets updated with collected inputs, but they often deviate not into a tool for clarity but one of pressure.
With pressure to deliver on made up deadlines come stressful release cycles, and with stressful release cycles come low quality features that get shipped just to get it done before the made up deadline.
After a while, so many things deviate slightly from the plan that nothing makes any sense. It’s no longer a matter of pushing a schedule by 3 days but one where plans for an entire quarter are delayed and inconsistent. As a team grows, this becomes an ever bigger problem; executives expect results consistent with the growth of the team, and the teams are now demanding a cleanup of all the mess they had to create to reach the deadlines that someone else imposed.
Roadmaps should be a guideline that invites conversation. I am not even sure they should exist beyond a quarter, except in very loose terms.
Roadmaps aren’t a collection of deadlines. When we place a deadline, it should matter. It should mean that is the absolute latest date in which we can deliver safely, not just that someone in the C suite will have a tantrum if it’s not done.
Roadmaps should not every detail, but should bring clarity to how things connect to each other. Details are best left to the moment when the teams will work on implementation, since that’s when you have the most information available to make those decisions. Roadmaps, I believe, should not be detailed lists of tickets that someone will code as they are.
Roadmaps should enable creativity. Teams should be given the freedom to explore solutions to a problem rather than being presented with the complete solution; it’s the people closer to the work who are often able to draw the correct implementation and cut the scope to deliver as much value as possible within a constraint.
Roadmaps should be a tool for clarity, which in turns enables autonomy and better decision making.
Reasonable roadmaps cannot be built in 30 minutes meetings in a vacuum.
Analyzing customer usage, insights, feedback. Talking with users, with support, with stakeholders. Figuring out what the space looks like outside your org. Figuring out if the current state aligns with the organization’s vision for the future. Understanding in detail the why. Comparing what would not get done if this other thing gets scheduled. Understanding the trade-offs and being able to explain them. This is hard to do if your product manager doesn’t have time to think. Give product teams space to think deeply, rather than just react.
In the end, it’s not so much the formal roadmap that matters in a very small team, but the process and learning that got it done.
Roadmaps are not just the what, but the why, when, and for whom.
When you have offices, a lot of your communication happens face to face, and most of those interactions aren’t documented anywhere. Jeff said “paint the walls red”, and Anna’s team did exactly that. If this happened in a hallway chat, there is no documentation of why they decided to do it, or when. If there are no meeting notes, you can’t easily go back and say “this discussion happened on April 2nd, 2018, these 3 people were involved, this is how it was decided”.
Let’s think of your remote team now, and what the process looks like for them. Even the most bare-bones setup for a remote worker involves some kind of chat system with the ability to search, e-mail, and meetings scheduled through calendar invites or by calling through your chat system. If you aren’t taking meeting notes, it won’t be an easy-to-find path, but you may still make it back to the source if all comms happened digitally. This means you have a few ways in which you decide things, how you communicate casually, and how you show what your organization values.
Before we move on, lets do an overview of some methods used in each environment.
Where meetings happen
Where do meetings happen?
Who gets invited
This one is a little trickier. Remote environments often require that you are aware of multiple time-zones, which introduces an extra layer of complexity not found in offices. While there are ways to make it work, it’s still something to take into account. In both offices and remote environments, it’s good to be mindful of the vacation calendar and working hours, in any case. People sometimes go on vacation or take long weekends, for starters, and they may need to pick up kids, care for their parents, and a million other things outside the workplace.
How decisions & decision-making is documented:
What happens after a decision is made
How people’s achievements are made visible
What did we learn from this comparison?
I can see you going “But this doesn’t prove anything!”. And you’d be right. It doesn’t. What it does, however, is show you that in remote companies the main communication blocker is in casual settings, not formal decision-making such as communication of goals or onboarding people into your cultural values. You no longer get to just tap Jeff in the shoulder(**) to discuss an important issue, or find them in the hallway(**) you now need to DM them or email them. The inability to do things remote prevents you from doing? That is also culture.
In a remote company, you can’t try to hide your lack of healthy team culture and values with a ping pong table and a few after parties. You have to do the work. You should still do the work in an office, but that’s not the topic of this blog post.
Your team can gain alignment just as well, and it’s more likely that you will know at the very least who decidedwhat, and how it was decided. In most remote environments, it’s unlikely that something happened without at least a message in your internal messaging system (ie: slack), and if you follow some good practices like note-taking, sharing back decisions, and creating agendas for your meetings, you will have a detailed log of how something came to happen, plus more opportunities for people to give their thoughts in a structured or unstructured fashion.
Culture is not ping pong tables and beer. Culture is who gets promoted, who gets a raise, who gets hired. Culture is also firing that person who is being a jerk to all your support teammates. It’s how you treat your customers, and whether people get promoted for being excellent at their jobs. Culture is the behaviors you reward and punish, and you can do those things just as well in a remote team.
I’m not saying remote work is perfect or easy (it’s not!), all I’m saying is that we’re giving remote work too much credit for its ability to create more dysfunctional teams than offices create.
We can create dysfunctional teams with unclear culture in both environments, but we have arguably more hard data about our culture when communication is optimized for asynchronous communication.
(**): please don’t do this, even if you’re in an office. It’s an easy way to make sure decisions are made without involving everyone needed, and it distracts people.
PS: lots of people don’t do well in offices. Lots of people don’t do well remotely. For those groups, it’s obviously detrimental to do one or the other. What’s important to remember is that both groups exist and that some are in-between (need a balance, which can also be just fine).
Early in my career, I used to think process was something people introduced because they were bored and had nothing better to do apart from bothering us, the productive, bread winning devs that built the thing.
Years later I found myself working with a team that had all the elements of a process and none of the glue that holds it all together. There were strict rules for some things, zero rules for others, and no idea of why each rule was introduced or how. “Why do we do it this way?” was something I asked a lot… always coming back with little to show for, or a very unsatisfying answer like “that’s how the previous manager did it”.
Process and tools were all pain inducing, with little to no regards of what the team actually needed to succeed, what their own pains were, how they could solve those pains or mitigate them.
And so, I did exactly what anyone with no previous management experience tends to do: I made the team work exactly like we worked in a previous team I had been a part of… a team were things just got done and quality was always a concern… a team of senior engineers with almost zero things in common with this new team except for the fact that we were building something.
I was looking at process as a series of steps instead of a framework that helps us achieve what we need.
I was thinking of the process as a thing we would have some day in the future, not the thing we already had. It was messy and undocumented, but we had a process, and you can’t really push for something new without understanding what came before.
Somehow, the new process took. It became “how we work”, and we were vocal about it. We would argue with other teams when they looked down on us for doing code reviews. We would suggest using git and explain why we wanted every release to be tested and tagged. From time to time one of us would mess up, and we would try to adjust how things worked, and step by step things would get better.
Years later, that process had been tweaked by many others, and it was ours instead of mine. It had grown and learned, and it was no longer “Romina’s thing”, it was our thing. It was cause for many disagreements and valuable discussions, for many issues that could have been prevented if we had seen the error in our ways, but also of many moments of joy, many innovations, many attempts to make it better, shinier, more useful, and for that I’m grateful.
Your team having a process is a journey, not a goal. Your team already has a process. It may be messy, undocumented, and maybe they don’t know it exists, but it’s there.
To create a process, you need to first find the one that already exists. You can’t dismantle something you don’t understand. I mean, clearly you can, but believe me, it’s a lot harder.
Your shiny new product development process is not very useful until it’s collectively owned, and it’s definitely not useful until people who have been there a while stop needing to constantly go to documents to figure out how it works.
It should be simple, it should prevent errors, it should help you identify issues when they happen.
A good process makes your work feel easier, I almost want to say it should bring some joy.
PS: Imposing a process on that team worked, at a surface level, because people were genuinely scared of what would happen if we didn’t change things fast. It wasn’t successful, and it certainly wasn’t easy until we had gone through many iterations and collectively changed it for the better. While it was “my” process, it felt forced and awkward. When it finally became our process, things got increasingly better, and it no longer depended on me to make it happen.
Engineering management is a lot like debugging and bug-fixing at times.
Sometimes you don’t know much about a failure except that it happened. Sometimes the solution is clear but risky in some way, and sometimes you just know what needs to be done and wonder why you didn’t do it earlier.
More often than not, there’s a problem coming up that you didn’t expect and don’t fully understand. As with code, those bugs are hard to figure out, but when you do, it’s extremely rewarding.
I’m a huge fan of remote work. It’d be hard to convince me to take a role where I need to go to an office every day.
Even as a remote work believer, there are still days when I wish we could get everyone in the same room for an hour without it being a big deal and involving air travel.
Where you live still matters.
Since many companies opt to hire “Remote US”(or wherever they are from) your options will often be limited by location.
This is especially true if you don’t live in the USA. The competition for remote jobs is huge, so the stakes can be higher at the interview stage. In that case, chances are that you will work in “remote worldwide” companies (which are not the majority) and it’s likely you will be setup as a contractor or hired through a 3rd party “employer of record” service.
That first day in a remote team is weird.
Joining a remote team is great, but don’t expect the first day in a new company to be the same as joining a new team in an office.
I remember my first week as a fully remote worker, it was super weird and it took a little time to feel like I could even take a step away from the computer. I was notifying my coworkers of important events like “I’ll be out for the next 10 minutes” for no reason other than being worried they might think I was slacking off 🙂
If you can’t travel at all, you’ll miss out on really important opportunities to get to meet your team.
I found that going to team retreats and casual events helps improve personal relationships. There’s very little ways to replace the unstructured interactions that happen in a team retreat setting. Making coffee together in the morning, cooking for a group, walking around the block to go grab a drink or buy supplies, going on a fun day trip, solving unexpected issues that happen during the week…. these are all things that help you connect in different ways.
A team retreat feels like 6 months worth of interactions compressed in a single week or two. Instead of talking near the coffee machine for 30 seconds, you essentially live with these people for days, either in a big house or in a hotel. You don’t get that very often in offices, but I suspect some teams would benefit from this even if they have offices to go to every day.
The counterpart to “bonding in team retreats” is important, too: it can be done outside “in person” interactions, it works great, but in my opinion you need to also have some real world interactions, especially when someone first joins so that they can feel fully integrated.
Being the only team member who never met the team in person can be super weird, but after that first meetup, things get easier.
Sometimes I miss looking around the office and being able to see my coworkers excited about the same things as me.
The last time we got some great news that affected the team, I felt a little sad that I couldn’t be in the same room to congratulate the parties involved and hang out with the team after we got the announcement.
There’ll be one on ones, and GIFs in slack. There’ll be ad hoc chats and spur of the moment calls with folks.
But even then, it won’t be the same as being in the same room. It was just one of those weeks when I wished I could grab a cup of coffee or a beer after work, without needing a video call.
Any communication problem will seem to be related to being remote.
That one bugs me, but I’m guilty of this too. Some problems are clearly related to the remote aspect. John says “ok” in a DM and leaves, and now someone is left spinning for a day because they thought something was wrong. John is always so cheerful, why didn’t he add any emoji? WHY? Anyway, I’m not saying this happened to me… but yes, yes it did happen.
Some problems are more likely to be related to remote work.
Some problems would be even worse in an office.
There are things that would be more or less the same, but maybe they would present differently and have the same result, like John making a decision while chatting with Juan in the office and forgetting to document it and let the team know. Six months later, there’s confusion about how this happened, who made the decision and when. This is the type of thing that can happen in an office, but when something similar happens remotely, we tend to attribute it to remote work instead of just thinking “someone forgot to document a decision”.
What I’m saying is that remote workers are extremely aware of the fact that their work style may be problematic at times. This tends to be good, because we obsess over having every decision written down and sharing notes from meetings (and when we don’t, great people call us out, loudly).
Remote workers seem to be in a state of constant introspection about whether the remote thing is working out, and so we tend to think everything is a remote work issue.
Kanban board out of date? Must be the lack of whiteboards.
John forgot to mention a deadline before his vacation? Must be the remote thing, if we had seen John leave through the front door for the week maybe someone would have asked about it (in case you are wondering: people in offices also forget things sometimes).
You need to be explicit about keeping in touch.
Since you won’t run into people while you make your morning cup of tea/coffee/whatever, you need to be intentional about “running into” folks online.
If you don’t make an active effort to talk with your team, you may never actually have contact with them except for short messages in GitHub issues and other focused tools/activities.
This is fixable by setting up 1-1 calls, instant messaging, hanging out in the remote “water cooler” type channels and talking with people there, etc.
It’s just different, and you need to be more intentional about it, especially at first.
Time zones
Time zones in a remote team are one of the main friction points. If you wake up and half your team already finished their day, you’ll need to adjust how you work.
In my current job we try to adjust things to be as async as possible, and it mostly works. This includes most of the on-boarding activities, day to day communication, development, discussions about strategy, etc.
Just because we need to work in a more async way it doesn’t mean that everything is done asynchronously, just that we optimize for our situation instead of optimizing for synchronous work. Sometimes we have to make sacrifices and join a late or early meeting, but generally the team tries to avoid having the main discussion be synchronously and opt for google documents instead to give people a chance to write down their thoughts and give their input ahead of time.
I really miss whiteboards sometimes
This one is weird, but I liked having the ability to walk up to a whiteboard with a team when I needed to collaborate on a hard problem.
Digital whiteboards are okay, but they don’t necessarily replicate the experience of the analog ones.
Solving this “lack of whiteboards” issue to me comes down to unlearning some behaviors, sending drafts of how I think something should work, getting on a call and discussing it, and then iterate on shared documents with others. Sometimes even creating the diagrams right there in the call and adjusting them together as a pair or group.
“Remote isn’t for everyone.” is something I heard many times over the years. While Ibelieve that’s absolutely true, I also believe that shared offices are not for everyone. Even offices with doors that close aren’t for everyone.
Open offices are considered the “one size fits all” of work environments. They’re advertised as a good default, but they only suit a portion of the population. We all pretend it’s both normal and okay to assume that everyone at a company has the same needs when it comes to their workspace and daily workflow.
For many of us, open offices are actively harmful. I get a lot more done when I have granular control over my environment, my breaks, and how I work. I can’t get that kind of freedom in an office, with or without doors that close.
Working remotely is not inherently harder than working from an office. Saying so implies that offices are “ground zero,” the absolutely neutral choice for a workspace. They aren’t. Remote work is hard, and so are offices. For some of you, offices are the easy choice. For others, remote work feels like a haven from the noise and distractions of the modern office environment. It’s not a universal feeling or choice.
Our work is challenging, and no amount of in-office collaboration will change that.
Healthy team dynamics are hard to create and maintain. They take a lot of work, they don’t just happen.
Dealing with performance issues is hard. It’s hard as a remote manager, and it’s also hard as a manager who shares an office.
Hiring is hard. It’s hard remotely, and it’s hard in person. You are making a difficult decision with limited information in a short period of time.
I don’t believe the future goal is to not have offices at all, but to have options. The key is to make it easy and normal to go remote; to have more companies who align with remote work and offer that experience; to have companies who think about whom they want to be when they grow up and have decided remote is for them. I believe the future includes hybrid setups too, even if I’m always wary of the complexity of hybrid work environments. I believe the future also includes some companies with an “office culture,” and that’s okay.
Remote work, much like offices, isn’t for everyone.
There will always be offices. Physical spaces where humans meet to collaborate are natural and needed. I just hope there are more remote-oriented companies in the future because it means more of us will get to work in spaces that make sense for us. But this will only happen if we allow ourselves to really think about what spaces make us feel productive and happy and stop worrying about how it will look for investors and customers if our employees don’t go into HQ each day. I genuinely think this re-orienting of how we view the workspace will come true.
Whenever I sit down to write a JD, ask for the budget to hire a new person, or review applications, I keep a running list of hiring ideals nearby to ensure I can quickly check against them and validate them against the real world.
A process is too close to the implementation details, and those vary too much from company to company. These are my personal guidelines.
⚠️ I write for myself, this is my personal blog. I do not speak for my employer. ⚠️
Hiring well is hard to do when people are burned out. Hiring teams need to be excited about the work being done, they need to take care of themselves, and they need to understand the organization. This is impossible if the hiring team isn’t confident about the team they are hiring for.
If our process is no better than a coin flip, we’re wasting valuable time. Whenever I add a new set of questions to a process, I ask myself how I know that it works. Very often, I can’t know that it will work, but I can make an initial guess based on the people we have in the team.
Hiring is a team activity, and it can include everyone. In my last job, most of the organization’s hiring philosophy had been defined by the founders, but over time many of us got to add to it and adjust the old documentation to our new context. In another scenario, I had the opportunity to define it from scratch with my team, and over the years we adjusted it, experimented, and grew with it. Some of those experiments were terrible, like a white-boarding task that was so badly designed, it resulted in juniors doing better than seniors… but we did learn, and overall we hired really talented and kind engineers that performed well with our team.
Hiring is not our default action. We don’t hire if we don’t know why we need a new person, or if we can figure out a better alternative. We don’t place value in how many people someone is managing. Understanding why we hire, understanding the goal behind our hiring targets, and being clear on our expectations for each role are all basic but important parts of a fair process that serves candidates and the teams they will join.
We don’t hire ICs into unstable teams with bad dynamics. If the new hire’s entire workload is focused on fixing this, they are probably not an IC, and they are there because everything else has failed. Hint: when that’s the case, the problem may be one level above the team. Expect drama.
Creating inclusive and diverse teams is a requirement of any high quality hiring process. If the only people making it through our process are overrepresented people in tech, we stop and re-evaluate what we are doing. For an embarrassingly long time, I didn’t really understand the pipeline problem… or more accurately, I thought the pipeline problem 100% explained why we didn’t have as many women as I wanted us to have in our team. Our racial diversity was better than the industry average but still lower than I would have wanted it; our gender diversity was abysmal. As a majority of white, cis, heterosexual people, we had a lot to learn.
We center humans; we look for the unique combination of skills and experience they bring to the table to evaluate if they are a fit at this time.
We provide timely and kind feedback, structured guidelines on what’s going to happen next, and work on systems that tackle and limit biases.
We don’t lean into structural inequality by leading salary conversations with “What’s your salary range”, we establish the salary bands the company manages for that position.
We are creating a new team, not just adding an individual. We know teams with new hires may go back to forming for a little while, and we adjust expectations with this in mind.
We expect to create inclusive, diverse, high performing teams that help the organization reach their goals. How we do it may change, but the goal never moves too far from the above.
Most companies and teams know the benefits and the need to hire junior engineers; after all, that’s where seniors come from. While that’s true for many companies, for many remote leaders or folks who are considering a remote job, the idea of hiring early career engineers seems to trigger an automatic NO reaction. I’ve talked with people who have been managing remote teams for years, and they still feel like Junior folks won’t fit in, will not onboard correctly, will lack opportunities for growth or plainly hurt their company.
Is it hard? Yes, remote is always hard. Here’s the thing: open offices are hard too (for me, much much harder, for others, maybe not), but we still bring junior engineers into open offices, so we might as well bring them into remote environments and support them as they learn how to work.
I believe by saying we cannot hire juniors into remote environments we are doing our companies a disservice, and we are giving our teams the wrong message when we say only seniors can join our remote team.
We need to get better at this.
We can’t insist that remote is the future while sustaining that a new generation of engineers cannot join us for the next 5 to 10 years.
We’re telling senior developers and managers that it’s best for juniors this way.
We are assuming that junior folks don’t know what’s good for them when we disregard their interest in working remotely by saying things like “it’s best to learn in an office”.
Not everyone can go to an office and get a good job that will give them opportunities for growth. Many people function better in remote environments, and I don’t see how being a junior developer stuck in an office will be better if you can’t deal with open offices or noisy environments.
We are saying they will have too much of a hard time, that it’s better for them if the people in offices take them and grow them before they can join our teams. That’s not always the case, and that’s not always desirable.
When we say “only seniors can join a remote team”, we are giving juniors way less credit than necessary.
The real concern with hiring junior developers seems to be the amount of support they’ll need, not the fact that they’ll be bad engineers, so I have to ask: why do we act like we are hiring a kid that needs constant vigilance, instead of realizing we are supposed to be hiring a mostly grown, adult human being?
Remote employees don’t learn how to be remote from working in an office.
Most of us started out in offices, and we all had to unlearn some things to thrive in a remote environment.
Do you want to just drop junior engineers in a team and hope for the best? No, of course not. Do you want to start with junior engineers before you have figured out the very basics of remote work? Nope.
But many of us work in established remote companies. Companies that have been here for a while, companies with senior people who can mentor others.
Use that. Teach new people how to do remote well. They have no bad habits from 10 years of office work, so you have a really good chance at helping them learn how to be remote.
Creating a new generation of remote leaders starts by practicing remote leadership.
How will we create an excellent, empathetic, remote first leadership pipeline if we are preventing seniors to learn how to help everyone regardless of where they are located? Learning how to help other people grow remotely is a new skill for many senior developers.
How do we empower and create the next generation of remote leaders if we are actively stopping a huge part of the developer population from joining us in remote work?
If we only hire other seniors, we are preventing them from acquiring what should become an important part of their leadership toolkit: mentoring folks in all skills levels, remotely.
Hiring only seniors is putting the burden to grow engineers on other people.
Seniors don’t grow in trees. If you only hire seniors, you are also saying someone else is supposed to do the work of mentoring and helping those junior people improve.
It makes me think that maybe you won’t help me with my own professional development goals either.
Show us that you don’t just think on the short term.
Having a junior person in your team gives the message that you are investing in the future of your team, and you’re not just thinking in the short term.
Everyone in your team will have excellent opportunities to help others get over their mistakes, learn, iterate, and do better next time.
It will force you and your team to think even more often about how safe people feel to fail and experiment, and if you play it right, it would mean that people of all levels will feel safe to make mistakes, share them and learn from them, instead of hiding things under the rug when something goes wrong or being terrified of getting a stretch assignment because it could be risky if you need too much help or get something wrong.
Give your team the message that remote work does not mean it’s everyone for themselves.
People with less assumptions can help improve your workflows.
Here’s another reason why your team needs junior developers: the senior folks will have an invaluable opportunity to use the brains of new people who have fewer preconceptions about how things should work.
People with less preconceived notions on how things have always worked will help you improve workflows and tools in ways that benefit everyone, including very senior ICs. This can provide fresh opportunities for seniors to work on engineering-lead projects that will help them showcase their skills, both technical and leadership oriented.
For people who want to advance in both the IC-track and management track, having projects where they control the goals and can provide proof of what they achieved is really beneficial, and for their managers, it can be an easy way to boost morale.
What can you do to help remote junior developers succeed?
With all this, I guess what’s left to say is “what can you do to help your new, remote, junior team member succeed?” I don’t know if you’ll like the answer, but it’s almost the same things that you did in those shiny offices:
onboard them both in the technical aspects of the job and in the “this is how the company runs” aspects.
check in about onboarding in 1-1s. Regardless of level, I like to ask simple questions like “how do you think this decision was made” or “do you know who approves your vacation requests?” to understand how onboarding is going for them.
make sure they know that you care about what they produce and how they interact and help the team, not how many hours they worked.
on the previous note: also make sure they know overworking is not okay and that you expect them to ask for help.
pair programming: try to find the time to pair once a week with junior folks. Be explicit that you expect juniors to be pairing up with seniors and even managers (when the manager codes). Coding together is an easy path to bring down walls.
ensure they are participating in code reviews (if you have them) not just as the person whose code is being reviewed, but as the person reviewing code. Find tiny changes they can help review so they get used to both sides of this and integrate fast with the team.
provide opportunities for them to do interesting things at the level they are at.
give them feedback often. Once a week is okay. Once per month is too little.
ask for their feedback often. Once a week is okay. Once per month is not enough.
ensure they have a few seniors in their team so that they have people they can go to when they need help.
provide extensive coaching on onboarding and mentorship to your senior engineers. This will be like onboarding a new person in some ways. Check in often to ensure they understand what is expected of them and can adjust their approach if something isn’t going as planned.
There’s no special magic that makes it impossible for junior developers to succeed in a remote environment. Your company doesn’t need a 200-page guide on how to make it work for them before you consider hiring one.
If your seniors are doing great, if there is psychological safety, if you have a team of peers that are eager to help each other succeed, you have what it takes to mentor juniors.
You’ll set them up with a manager that does their 1-1s weekly, you’ll help setup 1-1s with senior developers, you’ll make sure they get to know their team, you’ll provide guidance on how the company operates… this is not that different from what you should do for new people regardless of level. It’s not even all that different from what you should be doing in a very large, probably very noisy open office.
As a little time goes by, you’ll notice their work patterns, how they want to be helped, what interests them and what seems to not be their strongest suit. You’d need to notice this stuff for senior folks too. If anything, seniors can sometimes be harder to get to their A game because you might not have walked the path to the next level yourself. Maybe before being a manager you made it to tech lead, but you were not a staff engineer, so you can’t guide them at a technical level as much as you can with a more JR engineer, and since you are not as skilled as an engineer as they are, your only recourse is to help them navigate the organization instead of the code…. this is way harder to do in a remote organization than sitting down with someone to pair for a few hours or reviewing code more often than you’d like (and to be clear: we still need to do that part, we still need to help senior folks navigate the organization)
Hire Juniors. Help them become mid-level. Keep them happy and growing.
If you do this well, you’ll eventually have a new group of seniors in your team: the ones that stayed with you from their junior and mid-level years, and the previous senior folks, the ones that developed their mentoring skills and are now leading others in whatever capacity they enjoy the most.
@rowasc! 