Your manager can’t read your mind.

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

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

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

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

Why didn’t you tell me?

Oh, I thought you knew!

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

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

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

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

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

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

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

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

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

Yes. Without any 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.

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

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

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

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

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

It doesn’t have to be this way.

Your team wants you to succeed.

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

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

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

Open a blank document and write down

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

Why does this work?

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

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

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

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

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

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

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

new remote developers

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

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

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

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

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

– junior dev

Be explicit about expectations

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

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

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

junior dev

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

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

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

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

– a junior dev

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

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

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

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

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

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

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

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

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

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

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


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

Open offices are not for everyone.

“Remote isn’t for everyone.” is something I heard many times over the years. While I believe 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.

Remote developers need to grow in remote organizations

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.