DEV Community: Romina Suarez

Your manager can’t read your mind.

Romina Suarez — Wed, 07 Apr 2021 14:18:06 +0000

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

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

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

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

Why didn’t you tell me?

Oh, I thought you knew!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This post is part of my series for remote software developers. You can check it out and subscribe here https://rowasc.com/engineers-working-remotely/

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

Romina Suarez — Sat, 03 Apr 2021 18:39:35 +0000

Yes. Without a doubt.

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

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

There is no better teacher than shipping.

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

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

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

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

This post is part of my series for remote software developers. You can check it out and subscribe here https://rowasc.com/engineers-working-remotely/

Your team wants you to succeed, don't stay stuck!

Romina Suarez — Wed, 31 Mar 2021 23:27:01 +0000

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, 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.

This post is part of my series for remote software developers. You can check it out and subscribe here https://rowasc.com/engineers-working-remotely/

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

Romina Suarez — Mon, 29 Mar 2021 17:08:05 +0000

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.
junior dev

and...

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.
Helping them learn the basics of debugging

This post is part of my series on Remote Onboarding. You can check it out and subscribe here https://rowasc.com/onboarding/remote-onboarding-101-whenever-i-reach-out-i-feel-like-im-bothering-them/

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

Romina Suarez — Thu, 18 Mar 2021 22:30:43 +0000

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 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.

It gets better because you will stop relying solely on people who know too much to tell you what's missing, and start relying on the experts of "is this document any good?" which are new employees trying to learn about your organization.

For this to have a big impact, it matters to not just give them permission but to encourage contributions and explain that when they don’t understand something they should:

- Reach out to their peers
- Use their learnings to improve the documentation a little bit

This will result in more early opportunities to reach out to colleagues for clarifying questions, get their feedback, and ask for help. And getting comfortable asking questions and learning is part of successful onboarding, too, so it's a win-win-win.

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

Each onboarding is an opportunity to do better.

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.

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

I'm writing a series of Onboarding 101 posts, focused on all the little things that we take for granted (and shouldn't) when onboarding new remote workers.
If you want to get it directly in your inbox, you can subscribe by going to https://rowasc.com/onboarding/new-employees-should-be-able-to-edit-your-onboarding-docs/

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

Romina Suarez — Thu, 11 Mar 2021 19:55:40 +0000

“How do they know I started my day?”

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

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

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

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

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

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

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

Be explicit, avoid panic.

Write a welcome email that they can refer to from their personal email account to get started on their first day.

This isn’t the full onboarding documentation, it’s simply a set of guidelines and expectations that help them be confident as they get ready to start working together. The next few points cover what I expect to see in such an email.

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

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

Ensure someone will be online to welcome them to the team

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

Plan for things to fail at the worst possible time.

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

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

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

Ask for their feedback

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

Welcome e-mail template

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

# Start time

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

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

# Gear

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

# What to expect

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

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

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

Thank you, I hope you have a great day.  

$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.