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?
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?
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.
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.
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.
It does seem that remote works shines light on the core of a team members work ethic and productivity.
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.
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.
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.
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.
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.
/s i.e. I fail to see how this is a problem specific to remote work.
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.
This isn't a remote problem. It's a hiring one. You need to hire better developers.