To find great remote employees, prioritize candidates with strong writing skills

Post by valcker » Sat, Nov 21, 2020, 6:23 PM UTC

hodgesrm wrote: post #11

I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote…

While I agree that the key to success is _a lot_ of communication, there is much more to the management of remote teams than that: you should treat them like the on-site teams; communicate a lot but prefer video conferencing; try to give your remote teams the overall context; stick to as few means of communication as possible (if it's email, then stick to email).

Post by maerF0x0 » Tue, Nov 24, 2020, 3:01 AM UTC

jakuboboza wrote: post #125

hodgesrm wrote: post #11

I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote…

Exactly this. Assume nobody knows anything and explain everything 500 times. Also quick 5 minute call on Slack can save 4 hours to 4 days of sending emails. So prioritize fast issue solving rather than "process". Imho key things are: * Communication. * Biz + Technical PoV from devs. * Ownership / ability to make decisions. Full remote is not for control freaks. It is for people who wants to get shit done. If you can'…

>This means no 5000 esseys.

I generally tell people looking for my advice, engineering is a reading job. Until humanity figures out how to transfer ideas with something other than characters, you're going to have to read. A lot.

For example, one quick tip I give is just read the entirety of anything you encounter. The whole error message + stack trace. The whole document (page) about the package that contains the function you're after... the whole type and its functions.

It's also how I often mark people a "No" for interview -- when they obviously are not reading the error (with line number!) of their non-compiling code...

Re: To find great remote employees, prioritize candidates with strong writing skills

Re: To find great remote employees, prioritize candidates with strong writing skills