> For junior engineers it's really easy to fall into the trap of trying to solve everything themselves instead of asking for help when they are remote

Senior folks do this. All the time.

Despite having 10+ years of experience and leading engineers at AWS, my default is to "spin my wheels". Now that I understand myself a little better, anytime I find myself laser focused on a problem, but making 0% progress, then I either:

1) distance myself from the problem or 2) ask for help 3) both

Junior or not. Asking for help can be difficult

One thing I started as a team lead is telling all my Jr and Mid level engineers to reach out to me for help if they need it, and that I would always be happy to get on a call with them. I had a pretty small team so this was easily manageable. At first I wouldn't get any folks reaching out for help, but eventually they all got comfortable with calling/messaging me if they had an issue.

I think a bit part of this is how you see yourself on the team. I gave myself the personal title: "Specialist and Support Person". On any given day I really only have two tasks:

* Work on "specialist" stuff within the app, stuff that is way over the heads of any of the Jr's or Mid level devs.

* Provide Support on everything else. Since my engineers are the ones pumping out most of the code, the biggest part is making sure they are supported in every way imaginable.

There are other responsibilities obviously, but within the context of "day to day" on the team, I found aligning myself with those responsibilities really helped my team.

That trap also exists in the office, though. Even in the office, you need to give juniors active guidance. It's just that the way you give that guidance is different online and in the office.

It's a lot easier for me to observe a junior struggling, spinning their wheels, and give corrective feedback in the office. I don't know the remote equivalent of glancing at their screen and body language while I get up for a bathroom break.

Listen to what they say during the daily team meeting, and occasionally ask by chat how they're doing. It's true that it has to be a bit more explicit, and it may be a bit slower, but it's far from impossible.

That's one point of contact per day. I was able to continuously be aware of anyone struggling before. I can't continuously ping them throughout the day. Even 4 times a day seems much too high contact to not be patronizing, and that still leaves them to stew for up to two hours at a time

It's really this simple. Junior employees need to be more actively managed than senior employees. They literally do not know what they're doing, that's what makes them junior. Remote or local, they need more oversight to help them learn and become productive.

Can you give me advice on how to provide oversight in a way that's not demoralizing, infuriating, patronizing?

I found working with juniors _fun_ and rewarding in person. Remote i have hated it and don't think I've been good at it

One thing that has worked for me in the past is to do some regularly scheduled pair programming. When I'm driving I narrate my thought process and encourage questions. They get to see things and when I make a little typo and they can catch it, not only does it save me a few seconds but it makes them feel GREAT that they helped the senior dev. Making this highly interactive and the senior driving FIRST makes it still "fun" when the junior is in the driver's seat.

One of the biggest skills you're helping a junior to learn is how to break apart a big task into small, workable components. Maybe they are assigned a user story, but that user story is going to need multiple functions written, or something like that. So you might start with pseudo-coding or creating the interfaces together, talk high level about how a particular method should work, and then let them do that part by themself. "Let me know if you get stuck or done with that and then let's do a little informal code review."

Beyond that it's the normal management stuff of compliment sandwich on negative feedback, etc. The normal things you do to build and maintain rapport with coworkers.

Oh, another thing I find helpful is to make it clear up front what I'm doing and why. I don't just narrate what I'm literally doing in the programming, I narrate why we're doing this at the meta level and what the expectations are. I also make it clear that as they get more comfortable there will be less oversight.

The difference is it in the office you can just actively see that somebody is anxious and you can ask them what’s up.

True, but there have been plenty of cases where juniors languishing in an office with little guidance. And remote you can still ask them how they're doing by chat.

It's true that the barrier is a bit higher remote, but it's not unsurpassable.

In office, there's watercooler chat that can lead to debugging session. In remote there isn't.

That being said, with the former culture, it's harder to ask question online and asynchronously, since usually they prefer and wait to have in face session instead.

The equivalent in remote is a chat/thread turn into a call with a screen share. Managers and seniors encourage juniors to ask questions or just “speak” their minds. There are multiple touchpoints for that to happen, dailies, 1:1’s, spontaneous check-ins b/c people care. In a culture where remote work habits are good, these will be imparted on new-joiners, especially less experienced ones.

I think successful remote work has to take the position that asking for help 1:1 is bad, actually.

* If you go through the process of figuring it out, you gain a durable understanding of the subject matter which you can use to solve other problems.

* If either you (after your investigation) or the subject matter expert (on request) produces documentation of the subject, other people in the future can use this artifact to unblock themselves.

* If you ask in a public Slack channel, at least those who are channel-surfing or searching during the retention period might see it and learn something.

Getting an answer 1:1 is empty calories. It gives quick satisfaction in the moment, but only leads to more and more communication down the line. Communication kills productivity.

But there's gotta be a balance.

It's totally conceivable for a new/junior employee to spend hours or days solving a problem that's already been solved in your codebase, and someone with experience could fix the issue in literally 5 minutes or less.

Yes, it's good to learn things on your own. But especially in a small environment, sometimes you gotta move faster than that.

Sometimes getting an answer 1:1 is "empty calories", and you're not learning how to solve the problem.

But that might be because the problem doesn't need to be solved, and you were wasting hours or days trying to solve it.

> position that asking for help 1:1 is bad, actually.

Which is fine for some things. But also really really bad for virtually everything else. It's exceedingly hostile, especially for places where there is no written documentation, and lots of old timers who have tribal knowledge and are "far too productive" to answer messages.

I don't know what universe you're from. Communication kills productivity? The opposite is true. Getting feedback early and often is a productivity booster. Sure, sometimes it's better to ask in a public channel instead of 1:1, but to state that it is actually bad is absolutely false.

“Work is work” [0]. As an organization scales, an increasing fraction of employee time is spent on communication instead of work, leading at best to diminishing returns on headcount and sometimes to total gridlock. To the extent that an organization wants to derive marginal productivity from marginal headcount, it needs to find ways to get employees to talk to each other less.

[0] https://codahale.com/work-is-work/

People can't go into the process of figuring it out if they have no direction of what to figure out, what they are expected to accomplish, where the documentation is, how it's organized, who are they expected to report to, and a lot of other things.

Juniors aren't born knowing any of those things.

Yeah that makes sense to me too, you also tend to be a lot more insecure and want to prove yourself when you're a junior, so you may be a lot more self-conscious asking for help thinking that it may be perceived as incompetence. I've definitely experienced that when I started working. Being remote probably means that it's even harder to push through this insecurity and it could also mean that others may not see that you're struggling and come help help you spontaneously.

That being said I think it can probably be improved while still remaining WFH, for instance by more actively chaperoning newbies.

One problem with being a new employee, junior or not, is that it's hard to know who to ask or has worked on something similar before when you don't really even know your coworkers. The thing I miss most when WFH is overhearing relevant information. Teams dailies do not really solve that problem.

Not just junior engineers, unfortunately

Common advise is to ask for help but like how? Everyone is busy around me!