5 ms·

oh, and any suggestions on how to continue to create "onboarding magic" for my new employee... i'd love to hear your thoughts! how do i create THE BEST working

oh, and any suggestions on how to continue to create "onboarding magic" for my new employee... i'd love to hear your thoughts! how do i create THE BEST working environment possible? tips / tricks / insights?

aogl 7y ago
Don't micro-manage. Focus on output delivery.
new_guy 7y ago
What the above comment says. Don't micro-manage, and LISTEN. If your programmer tells you something listen to them and trust their judgement, it's why they're there. Also don't fall for any tech 'buzzwords', just go with what gets the job done.
- saddington 7y ago
  +1 — great reminder.
AnimalMuppet 7y ago
Don't take vacation the week your new hire shows up. I've been on the receiving end of that. It went... badly.
aliswe 7y ago
Listen to the employees. Anything hampering their work needs to be gotten out of their way, even if it's you. Everything you can do to optimize their job is valuable. Do they have a trash bin nearby? Is there a draft annoying them? Is there noise coming from somewhere, perhaps a door that never gets closed? Is it annoying when you take phone calls? Bad seat? Password policy? One guy was amazed when, at one time, his two founders came and said they wanted to apologize to him. They had been running past him way too often, and they felt they mist have been annoying him. He hadn't even noticed though... Listen to silence, try to interpret queues. Ask them to elaborate when going silent, please, speak your mind. Often employees won't say something verbally, but can be inferred somehow. Goes silent? Gaze drops? Tiny mouth? Learn to interpret body language. They may not be that telling, but indicative that ypu need to dig out something.
muzani 7y ago
My rule of thumb: happy programmer = productive programmer productive programmer = happy programmer Lots of managers somewhat assume that a developer is trying to do as little as possible, but it's quite the opposite. Many have pride in their work, and enjoy getting into flow. Very often they can get frustrated, with processes, with equipment, and often with themselves. Sometimes they end up in an unproductivity-depression spiral too, and need a little help out of that. Often the best solution here is not to be hard on them when things go slow, and make it clear that they're encouraged to bring up problems as it happens. The easiest way to find out is to just listen - regularly schedule 1-on-1s. Well, if you have one programmer, there's going to be a lot of 1 on 1, but keep it a habit. I'd say don't worry too much about onboarding. Start them off with a little goal, that's not too time dependent and have someone they can fully interrupt in the first few days. The process of the tech team can change very rapidly in just a few months, based on team size, managers, DevOps, etc.

aogl 7y ago

Don't micro-manage. Focus on output delivery.

new_guy 7y ago

What the above comment says. Don't micro-manage, and LISTEN. If your programmer tells you something listen to them and trust their judgement, it's why they're there. Also don't fall for any tech 'buzzwords', just go with what gets the job done.

saddington 7y ago
+1 — great reminder.

AnimalMuppet 7y ago

Don't take vacation the week your new hire shows up. I've been on the receiving end of that. It went... badly.

aliswe 7y ago

Listen to the employees. Anything hampering their work needs to be gotten out of their way, even if it's you. Everything you can do to optimize their job is valuable. Do they have a trash bin nearby? Is there a draft annoying them? Is there noise coming from somewhere, perhaps a door that never gets closed? Is it annoying when you take phone calls? Bad seat? Password policy? One guy was amazed when, at one time, his two founders came and said they wanted to apologize to him. They had been running past him way too often, and they felt they mist have been annoying him. He hadn't even noticed though... Listen to silence, try to interpret queues. Ask them to elaborate when going silent, please, speak your mind. Often employees won't say something verbally, but can be inferred somehow. Goes silent? Gaze drops? Tiny mouth? Learn to interpret body language. They may not be that telling, but indicative that ypu need to dig out something.

muzani 7y ago

My rule of thumb: happy programmer = productive programmer productive programmer = happy programmer Lots of managers somewhat assume that a developer is trying to do as little as possible, but it's quite the opposite. Many have pride in their work, and enjoy getting into flow. Very often they can get frustrated, with processes, with equipment, and often with themselves. Sometimes they end up in an unproductivity-depression spiral too, and need a little help out of that. Often the best solution here is not to be hard on them when things go slow, and make it clear that they're encouraged to bring up problems as it happens. The easiest way to find out is to just listen - regularly schedule 1-on-1s. Well, if you have one programmer, there's going to be a lot of 1 on 1, but keep it a habit. I'd say don't worry too much about onboarding. Start them off with a little goal, that's not too time dependent and have someone they can fully interrupt in the first few days. The process of the tech team can change very rapidly in just a few months, based on team size, managers, DevOps, etc.