Live data from Hacker News

How to set junior employees up for success in remote

slite.com

251–260 of 370 posts

Re: How to set junior employees up for success in remote

#251
post #207

Earlier quoted context omitted.

I'll add to that, the motivation to mentor someone really goes away the third or fourth time you see them hit the inflection point of the usefulness curve... just to be hired by someone else because $current_employer can't find an extra few grand to keep them. I don't like training and mentoring people. I'm pretty good at it, but I try my damnest to avoid it now.

You should still do it. Those people leaving and going to other companies is good for you individually as it builds your network.

Not everyone likes the mentoring and pedagogy aspects as much, and that's fine IMHO. I do like it despite turnover and "wasting" resources on some people, but I'm coming from an education/instruction background. I can see how some profiles would not be really interested in doing that.

Re: How to set junior employees up for success in remote

#252
post #7

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. I say this as somebody who has spent the last five years working remote team-based gigs.

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.

Re: How to set junior employees up for success in remote

#253

Earlier quoted context omitted.

I think anyone who can’t work well remote, on average, will not be your top performers anyway. What I mean by that — as a manager and one of the senior engineers, I had insight across our organization to projects and employee performance. Those who thrived being remote were those who already were the top performers. Those who were followers; who lacked discipline, failed faster and more obviously. Most software engin…

Utterly nonsense. How about children learning from home via a laptop? Doesn't work. Same for people who need to be trained in a new work environment. You want real interaction. You need to experience more than only sound and video in order to learn efficient. It's extremely wrong to think that good performers can always do these things from home. Not right.

Nope. Personally I could not disagree more.

I studied CS pre pandemic at a regular university. The whole curriculum was designed around lectures and in-person classes. But I skipped most of them due to social anxiety and laziness. Because every class had a digital script and I could practice with old exams, I did fairly well. Even better than most of those guys that visited every lecture. I guess that part of the problem is that some students tend to think, that just visiting the lecture is enough. They forget to practice the stuff on their own. Which you do automatically if you work through the script all by yourself.

After university I dropped right into my first job. Because of the pandemic it was 100% remote. Again, this worked perfectly. I could not have been any better. I even was able to take additional responsibility due to my performance "which exceeds expectations".

So calling this nonsense is nonesense ;-)

Re: How to set junior employees up for success in remote

#254

Earlier quoted context omitted.

I think the main concern is theft of the laptop. They do trust you. They don't want someone to have your drive with proprietary source, even if the drive is encrypted.

Sounds like they should fix this with better laptop encryption. There’s many cheap methods to make source code on a stolen laptop useless. Using this as an excuse may mean that the org is stupid or lies to employees. Since this is Google, I think this just means that they don’t trust employees. And that’s a bad situation. If you can’t trust employees to not do bad things with the tools required for their jobs, then i…

> Since this is Google, I think this just means that they don’t trust employees

Since this is google, the repo is hundreds of terabytes.

Not only that, having lots of copies hanging around on laptops is a big risk, even with encryption. Considering that google's likely threat model involves state actors, not having code on laptops is a reasonable mitigation.

But I suspect the biggest issue is that most of the tooling is design to run on whatever version of linux Google runs, not OSX/Windows/ubuntu.

Re: How to set junior employees up for success in remote

#255
post #139

Earlier quoted context omitted.

I think anyone who can’t work well remote, on average, will not be your top performers anyway. What I mean by that — as a manager and one of the senior engineers, I had insight across our organization to projects and employee performance. Those who thrived being remote were those who already were the top performers. Those who were followers; who lacked discipline, failed faster and more obviously. Most software engin…

> an always open video chat What.

It's a way to just be together, It's kinda just a way to share space and breakup the loneliness of covid and you can just ask questions to the team.

I've not done it as an established thing, but had standups where we pivoted to working on issues and as the issue got sorted everyone just chatted and enjoyed each other's company whilst moving onto other work. 3 hours later it's lunch and you end a mega video chat.

Re: How to set junior employees up for success in remote

#256
post #84

Earlier quoted context omitted.

IMHO it's turnover that's the problem. Companies get engineers for an average of like 24 months and it might be even less for junior employees. Taking the time to train someone up doesn't make as much sense when you're not going to get return on your investment.

I'll add to that, the motivation to mentor someone really goes away the third or fourth time you see them hit the inflection point of the usefulness curve... just to be hired by someone else because $current_employer can't find an extra few grand to keep them. I don't like training and mentoring people. I'm pretty good at it, but I try my damnest to avoid it now.

Yep, and why becoming one of the more senior members of a team is a reason I would leave a team. I wouldn't want to deal with on boarding people endlessly while still keeping up with my own work.

Re: How to set junior employees up for success in remote

#257

(quoting book) Amanda Nock, a tech leader and devops expert who posts frequently to Twitter, offered this in response when I posted on Twitter about how to hire good people remotely, “When I hire remotely, I ask about their online friends.” Nock doesn’t need the details of anyone’s online friendships, but she needs to know that the person has developed a serious friendship online; otherwise that person probably doesn…

and that quote is a brilliant example of cognitive bias.

"Only people who have online friends can communicate in the written form."

which can then be extrapolated to:

"I have online only friends, therefore this is the thing to look for"

Which is remote-ese for "we can't hire them because they don't look/sound/act like us and won't like the same things as us, therefore is a bad cultural fit."

Re: How to set junior employees up for success in remote

#258
post #61

Earlier quoted context omitted.

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.

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

Re: How to set junior employees up for success in remote

#259
post #165
post #84

Earlier quoted context omitted.

IMHO it's turnover that's the problem. Companies get engineers for an average of like 24 months and it might be even less for junior employees. Taking the time to train someone up doesn't make as much sense when you're not going to get return on your investment.

> IMHO it's turnover that's the problem. In software I've seen this to be a huge problem. In other disciplines my observations are that it's not as bad. The turnover issues is something that could use a lot more exploration. Nothing is going to change until it impacts those who are distant from the front line engineers. The managers of the engineers know about the problems. The executives over them are distant from t…

> The turnover issues is something that could use a lot more exploration.

It is about pay. If you switched jobs in the past year, you got a massive raise. If you stuck around, you got peanuts, if anything.

Re: How to set junior employees up for success in remote

#260
post #7

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. I say this as somebody who has spent the last five years working remote team-based gigs.

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 artifac…

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

Post reply on HN