6 ms·

I happen to agree. As an employer however, we've found it hard to always keep our developers motivated and executing on time. Any advice?

TeamMCS 11y ago
Isn't that just a pacing issue. If there's enough discrete work going through the pipe line then burn-downs (or if you're not traditionally agile, targets) should be pretty reflective of your output. You have to be careful, but I wonder if giving a developer access to their own progress/burndown would be an encouragement for those who arn't quite so self motivated.
fweespeech 11y ago
> As an employer however, we've found it hard to always keep our developers motivated and executing on time. The only time I've seen this to be a "problem" is when one of the following is true: A) Non-technical people are responsible for the estimates and/or have the ability to make changes to the requirements without understanding the complexity of the new requirements. B) They are stuck fixing bugs instead of doing new feature development due to technical debt. C) There is a serious communication problem. D) People want fixed, written in stone deadlines before the prototyping is done when things are still too fluid for anything resembling a good time estimate is possible. For instance, the only deadline I've majorly missed at my present workplace is the one project I told my boss was impractical, a terrible idea, and to please give it to someone else because I don't have the temperament to handle such requests. I'm sure some "business" person responsible for it considers it a "motivation and executing on time" problem despite the fact I basically said this was a terrible idea in front of the entire IT department in an official meeting with minutes being taken. Are you completely certain none of these 4 exist as an employer?
- georgehotelling 11y ago
  A, B and D would be affecting on-site developers just as much as the remotes, but C (communication) is the thing that requires unique abilities for a remote worker. If either the worker or the company is not good at communicating, that will cause serious problems. Poor communication from the managers can easily cause poor motivation and execution problems from the workers. If a worker is not communicating blocks or reaching out for the help they need, that can also lead to those problems.
  - fweespeech 11y ago
    Yes but I don't agree "C" is a "unique" ability for remotes. Our operations/IT stuff always has someone who is technically remote due to business travel. I have a side project with volunteers working on it remotely as well. I don't see it as a separate problem. People either can communicate effectively via text/phone....or they can't. In an office environment, you still need that. About 50% of my stakeholders are "remote" as they work in other companies many miles away.
allochthon 11y ago
> As an employer however, we've found it hard to always keep our developers ... executing on time. There's something off about this -- it has the whiff of micromanagement or waterfall; perhaps I'm misreading your point. Far better than micromanagement is hiring good, trustworthy people and collaborating with them together on incrementally building something out.
- 49531 11y ago
  I would echo this point, our remote team has hired good and bad and it's a lot more about the people and less about being remote. It does seem that remote works shines light on the core of a team members work ethic and productivity.
- noarchy 11y ago
  It could also have the whiff of an "Agile" team that has a crisis every 2 or 3 weeks, due to routinely setting unrealistic sprint goals. No, this isn't supposed to happen, but I've seen it at more than one shop, that's for sure.
  - allochthon 11y ago
    Yes, indeed. "Agile" can have its share of manufactured crises, too.
  - jacques_chester 11y ago
    Scrum is not bijective with Agile.
- curun1r 11y ago
  The motivational aspect is, in my experience, a consequence of working 100% from home. Spending that much time at home can make it hard for me to get stuff done. I'm perfectly capable of being productive when I work from home occasionally...possibly even more productive than I am when I'm in the office since I'm less distracted, but find that my productivity drops off considerably when I work predominantly from home. There's easy fixes for this--headphones, coffee shop Wi-Fi and a VPN connection work well for me--but I have to do something or I go stir crazy and can't get much done.
tdumitrescu 11y ago
Probably the answer is to have a non-technical manager _literally_ breathe down their necks, rather than over digital communication channels. /s i.e. I fail to see how this is a problem specific to remote work.
stephengillie 11y ago
How tight are your schedules? How much do you overcommit developer resources? How much do your salespeople promise that you can't realistically do? I just left a position where remote was impossible because of the workload. The office culture had strict hours, and developers were expected to work on new projects AND bug fix tickets at the same time. (They would tell the architect "You can use these 2 good developers this week" and then tell the developers "You can't work on the architect's project this week, you have to do bug fix tickets.") Essentially, a remote culture is a more laid-back culture. It's about herding the cats...not about herding cattle, or milking cats.
Beached 11y ago
You HAVE to have a very heavy heavy heavy hand in hiring. Hiring good is by far the best thing you can do, you could hiring the most brilliant coder in the world, but if he is a poor communicator and procrastinator, your SOL. For remote work, I look for hiring a personable motivated people, who are good at staying up on communication first, I can teach Tech, I don't want to teach someone to communicate or to stay on task. (This means they keep me informed by choice, not when I ask) Also, as the guy above me said, let them fail and dont over work them. Micro management is something that everyone has issues with, especially if your a new-ish manager, and especially if you are managing a remote team, and if you pile 45-50 hours of work on them in a 50 hour work week, they will become disinterested, and just show up put in the hours and leave without any regards to quality to deadlines.
ryanSrich 11y ago
> we've found it hard to always keep our developers motivated and executing on time. Any advice This isn't a remote problem. It's a hiring one. You need to hire better developers.
logfromblammo 11y ago
When herding cats, it is better to carry a can opener than a cattle prod. While this is difficult for traditional management styles to grasp, it is most useful to just ignore the down times and instead do absolutely everything in your power to encourage the ultra-productive "flow" state to happen as often as possible. The necessary conditions will vary by developer. Some people thrive with regular teammate feedback. Others like to pull a lonely all-nighter. Some will do their best thinking on a treadmill or in the shower, then sit down and execute. Some perform work-related rituals, like the morning coffee ceremony. There is no single thing you can do, other than getting to know your co-workers. Once you know them well enough, it should be obvious what you need to do. It may well be that the best way to motivate one of your developers is to institute timelines, milestones, and deadlines, but another will just switch off the creativity and motivation because of the micromanagement, and they won't come back until well after you remove the artificial pressure. There's no magic bullet. Sorry.
sankho 11y ago
One thing I've never heard from a manager at an in office gig - "my team is ultra motivated and always, without fault, executes on time. No problems there!" My point being that with software development, even in an office, you'll still have to deal with lack of motivation and missing deadlines, and will never feel totally accomplished here. Working locations become a correlation, not a causation.

TeamMCS 11y ago

Isn't that just a pacing issue. If there's enough discrete work going through the pipe line then burn-downs (or if you're not traditionally agile, targets) should be pretty reflective of your output. You have to be careful, but I wonder if giving a developer access to their own progress/burndown would be an encouragement for those who arn't quite so self motivated.

fweespeech 11y ago

> As an employer however, we've found it hard to always keep our developers motivated and executing on time. The only time I've seen this to be a "problem" is when one of the following is true: A) Non-technical people are responsible for the estimates and/or have the ability to make changes to the requirements without understanding the complexity of the new requirements. B) They are stuck fixing bugs instead of doing new feature development due to technical debt. C) There is a serious communication problem. D) People want fixed, written in stone deadlines before the prototyping is done when things are still too fluid for anything resembling a good time estimate is possible. For instance, the only deadline I've majorly missed at my present workplace is the one project I told my boss was impractical, a terrible idea, and to please give it to someone else because I don't have the temperament to handle such requests. I'm sure some "business" person responsible for it considers it a "motivation and executing on time" problem despite the fact I basically said this was a terrible idea in front of the entire IT department in an official meeting with minutes being taken. Are you completely certain none of these 4 exist as an employer?

georgehotelling 11y ago
A, B and D would be affecting on-site developers just as much as the remotes, but C (communication) is the thing that requires unique abilities for a remote worker. If either the worker or the company is not good at communicating, that will cause serious problems. Poor communication from the managers can easily cause poor motivation and execution problems from the workers. If a worker is not communicating blocks or reaching out for the help they need, that can also lead to those problems.
- fweespeech 11y ago
  Yes but I don't agree "C" is a "unique" ability for remotes. Our operations/IT stuff always has someone who is technically remote due to business travel. I have a side project with volunteers working on it remotely as well. I don't see it as a separate problem. People either can communicate effectively via text/phone....or they can't. In an office environment, you still need that. About 50% of my stakeholders are "remote" as they work in other companies many miles away.

allochthon 11y ago

> As an employer however, we've found it hard to always keep our developers ... executing on time. There's something off about this -- it has the whiff of micromanagement or waterfall; perhaps I'm misreading your point. Far better than micromanagement is hiring good, trustworthy people and collaborating with them together on incrementally building something out.

49531 11y ago
I would echo this point, our remote team has hired good and bad and it's a lot more about the people and less about being remote. It does seem that remote works shines light on the core of a team members work ethic and productivity.
noarchy 11y ago
It could also have the whiff of an "Agile" team that has a crisis every 2 or 3 weeks, due to routinely setting unrealistic sprint goals. No, this isn't supposed to happen, but I've seen it at more than one shop, that's for sure.
- allochthon 11y ago
  Yes, indeed. "Agile" can have its share of manufactured crises, too.
- jacques_chester 11y ago
  Scrum is not bijective with Agile.
curun1r 11y ago
The motivational aspect is, in my experience, a consequence of working 100% from home. Spending that much time at home can make it hard for me to get stuff done. I'm perfectly capable of being productive when I work from home occasionally...possibly even more productive than I am when I'm in the office since I'm less distracted, but find that my productivity drops off considerably when I work predominantly from home. There's easy fixes for this--headphones, coffee shop Wi-Fi and a VPN connection work well for me--but I have to do something or I go stir crazy and can't get much done.

tdumitrescu 11y ago

Probably the answer is to have a non-technical manager _literally_ breathe down their necks, rather than over digital communication channels. /s i.e. I fail to see how this is a problem specific to remote work.

stephengillie 11y ago

How tight are your schedules? How much do you overcommit developer resources? How much do your salespeople promise that you can't realistically do? I just left a position where remote was impossible because of the workload. The office culture had strict hours, and developers were expected to work on new projects AND bug fix tickets at the same time. (They would tell the architect "You can use these 2 good developers this week" and then tell the developers "You can't work on the architect's project this week, you have to do bug fix tickets.") Essentially, a remote culture is a more laid-back culture. It's about herding the cats...not about herding cattle, or milking cats.

Beached 11y ago

You HAVE to have a very heavy heavy heavy hand in hiring. Hiring good is by far the best thing you can do, you could hiring the most brilliant coder in the world, but if he is a poor communicator and procrastinator, your SOL. For remote work, I look for hiring a personable motivated people, who are good at staying up on communication first, I can teach Tech, I don't want to teach someone to communicate or to stay on task. (This means they keep me informed by choice, not when I ask) Also, as the guy above me said, let them fail and dont over work them. Micro management is something that everyone has issues with, especially if your a new-ish manager, and especially if you are managing a remote team, and if you pile 45-50 hours of work on them in a 50 hour work week, they will become disinterested, and just show up put in the hours and leave without any regards to quality to deadlines.

ryanSrich 11y ago

> we've found it hard to always keep our developers motivated and executing on time. Any advice This isn't a remote problem. It's a hiring one. You need to hire better developers.

logfromblammo 11y ago

When herding cats, it is better to carry a can opener than a cattle prod. While this is difficult for traditional management styles to grasp, it is most useful to just ignore the down times and instead do absolutely everything in your power to encourage the ultra-productive "flow" state to happen as often as possible. The necessary conditions will vary by developer. Some people thrive with regular teammate feedback. Others like to pull a lonely all-nighter. Some will do their best thinking on a treadmill or in the shower, then sit down and execute. Some perform work-related rituals, like the morning coffee ceremony. There is no single thing you can do, other than getting to know your co-workers. Once you know them well enough, it should be obvious what you need to do. It may well be that the best way to motivate one of your developers is to institute timelines, milestones, and deadlines, but another will just switch off the creativity and motivation because of the micromanagement, and they won't come back until well after you remove the artificial pressure. There's no magic bullet. Sorry.

sankho 11y ago

One thing I've never heard from a manager at an in office gig - "my team is ultra motivated and always, without fault, executes on time. No problems there!" My point being that with software development, even in an office, you'll still have to deal with lack of motivation and missing deadlines, and will never feel totally accomplished here. Working locations become a correlation, not a causation.