To do this without being a helicopter manager, state clearly to them what your goal is. Most employees will work with you if the end result is wfh without a nannycam. Explain you need a way to confirm work product in a way that management can approve of without being too invasive, and keeping on pace with in office work.
In truth, you should not care if they slack off half the day as long as they produce quality work product at a similar rate. Wfh is fewer interruptions and meetings, and means already they will have more “free” time. This is a management principle that is hard to accept, but insisting on the appearance of work is detrimental. Obviously this varies based on the type of work, but yours sounds like a software development situation. “so long as your reports are filed and your queue is cleared every 48 hours, your pace is up to you”.
Give them the rope to hang themselves with. Tell them that’s what you’re doing. Maybe one dev prefers to go easy then crunch for 6 hours on the 2nd of that 2 day cycle, for example.
Ultimately you cannot teach people to be responsible but you get far more positive results from treating people with trust and positivity than with skepticism and monitoring. That makes you less a team and more “the other”.
Obviously this advice may not apply in your situation but in general try where you can to apply this in principle.
The rope. I’m afraid they will immediately hang themselves. They’re juniors, they need guidance. It’s difficult to guide people over Slack.
We do need better tasks created, and since we don’t have a proper PM, that usually falls on me. We aren’t a deadline oriented company. We all know what the project is. You take the time you need to make it happen. But historically, they have been waiting until the last minute to make the product and it comes back buggy. I’d be less concerned about what they do with their time if everything was spot-on. It’s getting a lot better, but not to where I’m comfortable just letting them loose.
That’s fair. Still might be worth openly discussing that as a goal even if it’s nothing you can act on now. Let them show competence on their own perhaps.
Anyways, you sound like you already have the right mentality. Good looking out for your teammates.
personally I don’t think WFH is viable or productive for Junior devs, they need to learn a lot to be productive and unless they are the type they won’t learn it on their own time.
They do need to learn. They’re fine once you explain it. Mostly it’s issues with the bigger picture, not just a single task. We try to let them take a whole project from back to front. That includes database and api design. Sometimes it’s great, but often they are way over complicating things. K.I.S.S.
Why over complicate this? Tell them the expectations and if they can’t live up to those then fire them. It’s up to them to learn to either be professional or find a job in the office.
To do this without being a helicopter manager, state clearly to them what your goal is. Most employees will work with you if the end result is wfh without a nannycam. Explain you need a way to confirm work product in a way that management can approve of without being too invasive, and keeping on pace with in office work.
In truth, you should not care if they slack off half the day as long as they produce quality work product at a similar rate. Wfh is fewer interruptions and meetings, and means already they will have more “free” time. This is a management principle that is hard to accept, but insisting on the appearance of work is detrimental. Obviously this varies based on the type of work, but yours sounds like a software development situation. “so long as your reports are filed and your queue is cleared every 48 hours, your pace is up to you”.
Give them the rope to hang themselves with. Tell them that’s what you’re doing. Maybe one dev prefers to go easy then crunch for 6 hours on the 2nd of that 2 day cycle, for example.
Ultimately you cannot teach people to be responsible but you get far more positive results from treating people with trust and positivity than with skepticism and monitoring. That makes you less a team and more “the other”.
Obviously this advice may not apply in your situation but in general try where you can to apply this in principle.
The rope. I’m afraid they will immediately hang themselves. They’re juniors, they need guidance. It’s difficult to guide people over Slack.
We do need better tasks created, and since we don’t have a proper PM, that usually falls on me. We aren’t a deadline oriented company. We all know what the project is. You take the time you need to make it happen. But historically, they have been waiting until the last minute to make the product and it comes back buggy. I’d be less concerned about what they do with their time if everything was spot-on. It’s getting a lot better, but not to where I’m comfortable just letting them loose.
That’s fair. Still might be worth openly discussing that as a goal even if it’s nothing you can act on now. Let them show competence on their own perhaps.
Anyways, you sound like you already have the right mentality. Good looking out for your teammates.
personally I don’t think WFH is viable or productive for Junior devs, they need to learn a lot to be productive and unless they are the type they won’t learn it on their own time.
They do need to learn. They’re fine once you explain it. Mostly it’s issues with the bigger picture, not just a single task. We try to let them take a whole project from back to front. That includes database and api design. Sometimes it’s great, but often they are way over complicating things. K.I.S.S.
Why over complicate this? Tell them the expectations and if they can’t live up to those then fire them. It’s up to them to learn to either be professional or find a job in the office.
That’s one way to do it.