6 ms·

Good article. Having a lot of experience managing remote teams, I wanted to expand on this point: > Try to focus on the employees who thrive in such environmen

Good article. Having a lot of experience managing remote teams, I wanted to expand on this point: > Try to focus on the employees who thrive in such environments rather than those few bad apples. You can’t let the bad apples define the work experience for everyone, but you do need to identify them and remove them as fast as possible so they don’t poison the well. One thing I didn’t realize at first was that remote work attracts bad apples at a much higher rate than in-person work. There’s an idea that remote jobs are an easy way to get away with doing less work, so you’ll be flooded with applicants who read books like “The Four Hour Workweek” and think your remote job is their ticket to traveling the world while they answer occasional emails from their phones. Or more commonly, a ticket to working a few hours (or less!) per day while they try to convince their boss that the task is just harder than it looks. Good performance management is important in any job, but it’s even more critical in remote work. If you let remote slackers thrive at your company, the good employees will notice. They’ll quickly burn out after working normal amounts plus also picking up the tasks that aren’t being done by the remote slackers. Resentment grows quickly and the good employees will be leaving quickly if let the remote slackers coast without consequences. I actually favor engineers-turned-managers for remote management positions over managers with non-engineer backgrounds for this reason. Former engineers are much better at spotting when someone is lying about the complexity of coding tasks.

pengwing 5y ago
Let me expand on that point: "Don't accidentally throw out good apples with the bad ones because you are looking at the wrong metrics." What I mean is: Bad apples are real, but don't ever do time-tracking or fast response testing in an effort to identify them. There are some excellent apples who will get your 8h-day deliverables done in 2-4h. Don't ever establish any system to find them. If you have a problem with them, you are the problem. Kick people based on repeatedly violating the deadline for deliverables.
- codegeek 5y ago
  Work is not all about deadlines. It also requires discipline to be present for meetings (no matter how much you hate them), be available to solve problems (sometimes immediately), collaborate with other team members and many other things. It is called "Team work" for a reason. Good developers can get away with a lot of things for sure especially if they produce code but as someone who runs teams, it is not enough. I would rather work with someone who cares about how their work impacts the overall team vs just them working in silo and happy enough coz they hit their deadlines.
  - zerocount 5y ago
    Yes, it is about the deadlines. That's what keeps me getting a paycheck, which is the reason I'm working. What you describe as teamwork is just every day development activity. There is no discipline to attending a meeting when the meeting is mandatory. I can always spot someone who 'runs teams' by the way they prioritize the company and piss on the workers in the name of the customer and 'teamwork.' This is why you can't trust a manager. You can't seperate their nose from the company's ass.
    - codegeek 5y ago
      "piss on the workers". I made no such remark anywhere in my comment. You can prioritize the company and still take care of the employees. It is not a zero sum game but hating on managers is obviously a cool thing to do.
    - marcinzm 5y ago
      I've never been at a company where deadlines are what keeps people getting a paycheck. Overall output is what kept the paychecks flowing. Deadlines are an artificial construct in most cases and in most of the remaining they're just a way to synchronize work. If a feature comes out today or in a week or a month has little difference in the vast majority of cases. If you get 1 or 5 or 10 features out this month has a difference.
- marcinzm 5y ago
  Deadlines are also the wrong metric to measure people with unless you're a contracting/consulting shop.
  - codegeek 5y ago
    Seriously. This talk of "deadlines are everything" is such bullshit. In my company, I am looking for people who care about their work, first and foremost. They enjoy what they do. Sometimes, deadlines are needed, sure. But it is mostly about growing as an individual and learning how to work in collaboration. What good are deadlines if you churn out crap output ?
- PragmaticPulp 5y ago
  The thing is: Some of the worst remote workers are actually the best at appearing always online. They’ll go out of their way to remind everyone that they were “working” at 8PM or on a weekend because they need to compensate for the lack of actual work done. One of the worst remote work offenders I ever dealt with had a routine of doing things every Saturday morning that would ping the team: Lots of Slack “@channel” questions. Lots of name tags in Slack to generate pings. Some e-mails with unnecessarily huge recipient lists. If someone had only measured time online or number of Slack messages sent, this guy would have been at the top of the list. But it was all a show. It was all low-effort, high-volume content designed to give the impression of working hard, and it only came in short bursts. Anyone paying attention knew he wasn’t delivering much but he was generating huge fanfare over tiny things he did. So yes, focusing too much on perceived hours worked or activity in Slack or e-mail is one of the worst ways to do performance management. > Kick people based on repeatedly violating the deadline for deliverables. This is the other game they play: Come sprint planning time, they’ll invest huge effort in exaggerating how long a task will take. Then they’ll go to great lengths to find ways to be “blocked and waiting on so and so” during the week. Eventually they’ll push their deadline back so far that hitting it is trivially easy. Which is why it’s important to have managers who can spot these exaggerations and investigate the actual code and deliverables when they arrive. Engineers are good at spotting when someone has been lying about effort, but managers without engineering backgrounds can often (but not always) be fooled by charismatic remote workers.
  - zerocount 5y ago
    - code_biologist 5y ago
      Are you and I reading the same comment? PragmaticPulp talked about measuring people by their true deliverables — not on whether they act like cogs or "give it their all".
    - dang 5y ago
      Whoa, you can't attack other users like this on HN. We ban accounts that do this sort of thing. You've unfortunately been breaking the site guidelines in other places too. I don't want to ban you, so if you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
- zerocount 5y ago
  This actually makes sense. No need for the big survellance net.
- andrei_says_ 5y ago
  As someone who is involved in both engineering and management - in my experience 8h days do not exist. Are there just isn’t an environment allowing for eight hours of deep work without interruptions, emails, meetings, chats etc. And even if eight hours of deep work were possible, the cognitive load the programming tends to lead to exhaustion within 4 to 6 hours max. I don’t expect more from myself or others.
codegeek 5y ago
Well said. There also are websites that are openly encouraging working 2 full time remote jobs concurrently/at the same time. I don't want to name those here but wow.
- afandian 5y ago
  Not sure if I missed the joke here but a recent thread here had a fair amount of discussion about working two jobs, putting in minimum hours, and calling that 'full time'.
- ipaddr 5y ago
  If you read the posts in that blog the guy is barely holding in to positions for a few weeks. You are better off going for the best paying position rather than trying to manage two poorly paid positions.
snicker7 5y ago
For software engineering, four hours of actual work per day is probably average even on-site.
- DrammBA 5y ago
  I'm always amazed when people claim they work more than that a day. Between meetings, context switching, and social interactions, I pat myself on the back if I manage to work a total of 4 hours.
  - idiocratic 5y ago
    I don't understand how you don't count meetings and context switching as part of work hours. You're helping others, making decisions, etc. It's not that what's not coding is not work.
- MattGaiser 5y ago
  For office workers in general, 3 is typical. https://www.inc.com/melanie-curtin/in-an-8-hour-day-the-average-worker-is-productive-for-this-many-hours.html https://www.inc.com/melanie-curtin/in-an-8-hour-day-the-aver... Has held true at all 7 jobs I have ever had.
- PragmaticPulp 5y ago
  Yes, but communications, meetings, and being available to answer questions are also part of the job description. The more someone becomes unavailable for communications, knowledge sharing, and meetings, the more work they create for their teammates and managers who have to compensate by tracking everything down, re-hashing missed meetings, re-communicating things that should have been covered the first time and so on. It’s not enough to just write four hours of code every day and then disconnect, even if the average coder is also only writing four hours of code.
  - nanidin 5y ago
    It sounds like you are describing a work culture that relies heavily on synchronous communication to make progress. These don’t work well for companies that want to have remote workers and treat them as first class citizens. The solution is to find ways to knowledgeshare that don’t require everyone’s attention at the same time - like a well maintained wiki, or recorded knowledge sharing sessions. Consensus building may well require synchronous communication, and it should be made clear to remote workers which meetings are cruft and which are important. This can be accomplished by publishing meeting agendas and goals prior to the actual meeting. I think at the end of the day it is important to recognize that different people work differently and accommodations have to be made for all sides to contribute effectively. By that I mean some people need to sit in a meeting with a person that is presenting slides to learn, but someone else might pick up the same material via one paragraph and a diagram + access to the code, and someone else might work better with a whiteboard presentation. I prefer async written communication (email) because it leaves behind an easily searchable record to reference in the future.
kache_ 5y ago
>managers who weren't former engineers woah, those exist?
- PragmaticPulp 5y ago
  Yep! There’s an entire school of thought that management and engineering are so entirely different that managers don’t need to have an engineering background. I personally disagree, but I have a friend who insists that the best engineering managers are those who come from professional management backgrounds (project management, then people management usually) instead of engineering backgrounds.
  - zerocount 5y ago
    There's also a school of thought that managers are not necessary. I'm a big fan of it.
    - paranorman 5y ago
      Google was a fan of it, too. You should look into project oxygen.
    - code_biologist 5y ago
      That only scales up to a certain degree. There are some really good examples of holacracy failing to live up to hype in the software world: • HN discussion of holacracy at Valve: https://news.ycombinator.com/item?id=9512866 https://news.ycombinator.com/item?id=9512866 • Holacracy and the mirage of the boss-less workplace: Lessons from the failures at Github, Medium & Buffer: https://medium.com/battle-room/holacracy-and-the-mirage-of-the-boss-less-workplace-lessons-from-the-failures-at-github-medium-4355993926d4 https://medium.com/battle-room/holacracy-and-the-mirage-of-t... There's also a classic essay, "The Tyranny of Structurelessness", that is about parts of the feminist movement but directly applies to holacracy at companies. If you're anti-manager, a small or single person company or consultancy can be great.
    - PragmaticPulp 5y ago
yowlingcat 5y ago
Obligatory question here: how are you tuning how you screen for bad apples in your technical interview pre-hire to make sure that over time you have less and less bad apples? Also, what level of scale is your remote eng organization operating at? Having also had a lot of experience managing remote teams (and to be a little bit hyperbolic for the sake of making a point), saying that remote work attracts "bad apples" at a much higher rate than in-person work seems like a cop out to excuse poor screening hygiene.
- sokoloff 5y ago
  I think the applicant pool has a higher concentration of <any given negative> than the employee pool. I posit that people with negative factors tend to apply/interview more per job start and probably have shorter average tenures [due to getting fired/managed out or quitting because they’re not getting their needs met]. We just experienced a 20-month disruption that caused certain previously latent negatives to be newly and massively amplified. Life’s also been harder than usual on many(most?) people. I’d be somewhat shocked if those negatives didn’t get concentrated into the applicant pool as well. To a hiring manager, that would be nearly indistinguishable from “remote work attracts bad apples at a higher rate”. I’m quite pro-remote and think it’s going to end up overall wonderful that the tech world was forced into this massive, synchronized pre/post test. I also see employees who did well in the in-office structure struggle in the higher-discipline required remote model. Those employees are probably best served to return to in-office work.
drewcoo 5y ago
This raises the issue of management measures of effort or time spent versus results; being busy versus getting it done. That has always been a problem in physical offices (otherwise Office Space wouldn't be funny). It is an even more exaggerated management problem when people's appearances can't be casually monitored and/or micromanaged. One thing that most engineer-turned-managers don't have is any training in management whatsoever. In fact, many of them have only been managed by uneducated managers themselves. This situation, compounded by remote work, is not pretty. Thankfully, the article was a set of checklists of easy-to-measure items. And it recommended focus on employee results. It is refreshing to see this kind of article on management education!

pengwing 5y ago

Let me expand on that point: "Don't accidentally throw out good apples with the bad ones because you are looking at the wrong metrics." What I mean is: Bad apples are real, but don't ever do time-tracking or fast response testing in an effort to identify them. There are some excellent apples who will get your 8h-day deliverables done in 2-4h. Don't ever establish any system to find them. If you have a problem with them, you are the problem. Kick people based on repeatedly violating the deadline for deliverables.

codegeek 5y ago
Work is not all about deadlines. It also requires discipline to be present for meetings (no matter how much you hate them), be available to solve problems (sometimes immediately), collaborate with other team members and many other things. It is called "Team work" for a reason. Good developers can get away with a lot of things for sure especially if they produce code but as someone who runs teams, it is not enough. I would rather work with someone who cares about how their work impacts the overall team vs just them working in silo and happy enough coz they hit their deadlines.
- zerocount 5y ago
  Yes, it is about the deadlines. That's what keeps me getting a paycheck, which is the reason I'm working. What you describe as teamwork is just every day development activity. There is no discipline to attending a meeting when the meeting is mandatory. I can always spot someone who 'runs teams' by the way they prioritize the company and piss on the workers in the name of the customer and 'teamwork.' This is why you can't trust a manager. You can't seperate their nose from the company's ass.
  - codegeek 5y ago
    "piss on the workers". I made no such remark anywhere in my comment. You can prioritize the company and still take care of the employees. It is not a zero sum game but hating on managers is obviously a cool thing to do.
  - marcinzm 5y ago
    I've never been at a company where deadlines are what keeps people getting a paycheck. Overall output is what kept the paychecks flowing. Deadlines are an artificial construct in most cases and in most of the remaining they're just a way to synchronize work. If a feature comes out today or in a week or a month has little difference in the vast majority of cases. If you get 1 or 5 or 10 features out this month has a difference.
marcinzm 5y ago
Deadlines are also the wrong metric to measure people with unless you're a contracting/consulting shop.
- codegeek 5y ago
  Seriously. This talk of "deadlines are everything" is such bullshit. In my company, I am looking for people who care about their work, first and foremost. They enjoy what they do. Sometimes, deadlines are needed, sure. But it is mostly about growing as an individual and learning how to work in collaboration. What good are deadlines if you churn out crap output ?
PragmaticPulp 5y ago
The thing is: Some of the worst remote workers are actually the best at appearing always online. They’ll go out of their way to remind everyone that they were “working” at 8PM or on a weekend because they need to compensate for the lack of actual work done. One of the worst remote work offenders I ever dealt with had a routine of doing things every Saturday morning that would ping the team: Lots of Slack “@channel” questions. Lots of name tags in Slack to generate pings. Some e-mails with unnecessarily huge recipient lists. If someone had only measured time online or number of Slack messages sent, this guy would have been at the top of the list. But it was all a show. It was all low-effort, high-volume content designed to give the impression of working hard, and it only came in short bursts. Anyone paying attention knew he wasn’t delivering much but he was generating huge fanfare over tiny things he did. So yes, focusing too much on perceived hours worked or activity in Slack or e-mail is one of the worst ways to do performance management. > Kick people based on repeatedly violating the deadline for deliverables. This is the other game they play: Come sprint planning time, they’ll invest huge effort in exaggerating how long a task will take. Then they’ll go to great lengths to find ways to be “blocked and waiting on so and so” during the week. Eventually they’ll push their deadline back so far that hitting it is trivially easy. Which is why it’s important to have managers who can spot these exaggerations and investigate the actual code and deliverables when they arrive. Engineers are good at spotting when someone has been lying about effort, but managers without engineering backgrounds can often (but not always) be fooled by charismatic remote workers.
- zerocount 5y ago
  - code_biologist 5y ago
    Are you and I reading the same comment? PragmaticPulp talked about measuring people by their true deliverables — not on whether they act like cogs or "give it their all".
  - dang 5y ago
    Whoa, you can't attack other users like this on HN. We ban accounts that do this sort of thing. You've unfortunately been breaking the site guidelines in other places too. I don't want to ban you, so if you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
zerocount 5y ago
This actually makes sense. No need for the big survellance net.
andrei_says_ 5y ago
As someone who is involved in both engineering and management - in my experience 8h days do not exist. Are there just isn’t an environment allowing for eight hours of deep work without interruptions, emails, meetings, chats etc. And even if eight hours of deep work were possible, the cognitive load the programming tends to lead to exhaustion within 4 to 6 hours max. I don’t expect more from myself or others.

codegeek 5y ago

Well said. There also are websites that are openly encouraging working 2 full time remote jobs concurrently/at the same time. I don't want to name those here but wow.

afandian 5y ago
Not sure if I missed the joke here but a recent thread here had a fair amount of discussion about working two jobs, putting in minimum hours, and calling that 'full time'.
ipaddr 5y ago
If you read the posts in that blog the guy is barely holding in to positions for a few weeks. You are better off going for the best paying position rather than trying to manage two poorly paid positions.

snicker7 5y ago

For software engineering, four hours of actual work per day is probably average even on-site.

DrammBA 5y ago
I'm always amazed when people claim they work more than that a day. Between meetings, context switching, and social interactions, I pat myself on the back if I manage to work a total of 4 hours.
- idiocratic 5y ago
  I don't understand how you don't count meetings and context switching as part of work hours. You're helping others, making decisions, etc. It's not that what's not coding is not work.
MattGaiser 5y ago
For office workers in general, 3 is typical. https://www.inc.com/melanie-curtin/in-an-8-hour-day-the-average-worker-is-productive-for-this-many-hours.html https://www.inc.com/melanie-curtin/in-an-8-hour-day-the-aver... Has held true at all 7 jobs I have ever had.
PragmaticPulp 5y ago
Yes, but communications, meetings, and being available to answer questions are also part of the job description. The more someone becomes unavailable for communications, knowledge sharing, and meetings, the more work they create for their teammates and managers who have to compensate by tracking everything down, re-hashing missed meetings, re-communicating things that should have been covered the first time and so on. It’s not enough to just write four hours of code every day and then disconnect, even if the average coder is also only writing four hours of code.
- nanidin 5y ago
  It sounds like you are describing a work culture that relies heavily on synchronous communication to make progress. These don’t work well for companies that want to have remote workers and treat them as first class citizens. The solution is to find ways to knowledgeshare that don’t require everyone’s attention at the same time - like a well maintained wiki, or recorded knowledge sharing sessions. Consensus building may well require synchronous communication, and it should be made clear to remote workers which meetings are cruft and which are important. This can be accomplished by publishing meeting agendas and goals prior to the actual meeting. I think at the end of the day it is important to recognize that different people work differently and accommodations have to be made for all sides to contribute effectively. By that I mean some people need to sit in a meeting with a person that is presenting slides to learn, but someone else might pick up the same material via one paragraph and a diagram + access to the code, and someone else might work better with a whiteboard presentation. I prefer async written communication (email) because it leaves behind an easily searchable record to reference in the future.

kache_ 5y ago

>managers who weren't former engineers woah, those exist?

PragmaticPulp 5y ago
Yep! There’s an entire school of thought that management and engineering are so entirely different that managers don’t need to have an engineering background. I personally disagree, but I have a friend who insists that the best engineering managers are those who come from professional management backgrounds (project management, then people management usually) instead of engineering backgrounds.
- zerocount 5y ago
  There's also a school of thought that managers are not necessary. I'm a big fan of it.
  - paranorman 5y ago
    Google was a fan of it, too. You should look into project oxygen.
  - code_biologist 5y ago
    That only scales up to a certain degree. There are some really good examples of holacracy failing to live up to hype in the software world: • HN discussion of holacracy at Valve: https://news.ycombinator.com/item?id=9512866 https://news.ycombinator.com/item?id=9512866 • Holacracy and the mirage of the boss-less workplace: Lessons from the failures at Github, Medium & Buffer: https://medium.com/battle-room/holacracy-and-the-mirage-of-the-boss-less-workplace-lessons-from-the-failures-at-github-medium-4355993926d4 https://medium.com/battle-room/holacracy-and-the-mirage-of-t... There's also a classic essay, "The Tyranny of Structurelessness", that is about parts of the feminist movement but directly applies to holacracy at companies. If you're anti-manager, a small or single person company or consultancy can be great.
  - PragmaticPulp 5y ago

yowlingcat 5y ago

Obligatory question here: how are you tuning how you screen for bad apples in your technical interview pre-hire to make sure that over time you have less and less bad apples? Also, what level of scale is your remote eng organization operating at? Having also had a lot of experience managing remote teams (and to be a little bit hyperbolic for the sake of making a point), saying that remote work attracts "bad apples" at a much higher rate than in-person work seems like a cop out to excuse poor screening hygiene.

sokoloff 5y ago
I think the applicant pool has a higher concentration of <any given negative> than the employee pool. I posit that people with negative factors tend to apply/interview more per job start and probably have shorter average tenures [due to getting fired/managed out or quitting because they’re not getting their needs met]. We just experienced a 20-month disruption that caused certain previously latent negatives to be newly and massively amplified. Life’s also been harder than usual on many(most?) people. I’d be somewhat shocked if those negatives didn’t get concentrated into the applicant pool as well. To a hiring manager, that would be nearly indistinguishable from “remote work attracts bad apples at a higher rate”. I’m quite pro-remote and think it’s going to end up overall wonderful that the tech world was forced into this massive, synchronized pre/post test. I also see employees who did well in the in-office structure struggle in the higher-discipline required remote model. Those employees are probably best served to return to in-office work.

drewcoo 5y ago

This raises the issue of management measures of effort or time spent versus results; being busy versus getting it done. That has always been a problem in physical offices (otherwise Office Space wouldn't be funny). It is an even more exaggerated management problem when people's appearances can't be casually monitored and/or micromanaged. One thing that most engineer-turned-managers don't have is any training in management whatsoever. In fact, many of them have only been managed by uneducated managers themselves. This situation, compounded by remote work, is not pretty. Thankfully, the article was a set of checklists of easy-to-measure items. And it recommended focus on employee results. It is refreshing to see this kind of article on management education!