4 ms·

don't do 1-on-1's unless there is an acute problem. I do however, walk and talk a lot i.e. keep on top of things. way way better. most of the time, 1-on-1 is

don't do 1-on-1's unless there is an acute problem. I do however, walk and talk a lot i.e. keep on top of things. way way better. most of the time, 1-on-1 is personal issue (death, scheduling conflict, injury), or personality-clash. not a big fan of endless meetings. much prefer management, to be out and about (checking on the state of things, resolving problems). I don't normally favor firing people (unless there is something seriously wrong with their behavior). There is always a way to work things out. A light touch, at the right time, goes way further than "constant meetings". Also being able to work to accommodate people (remembering them as people, first and foremost).

wokwokwok 8y ago
Please don’t take away from this that you shouldn’t do 1-on-1s, because the parent post doesn’t. If you’re on top of your game, this is totally a valid way to do it. ...but I’ve worked with people who use ‘light touch’ as an excuse for ‘don’t want to do people things, so I’ll just get on with my work’. That’s a failure at everything you’re supposed to be doing. The take away here is talk to people. ...how you do that, though, can vary and still be successful.
- paulgrant999 8y ago
  I would say, suit it to the person you're managing. me I just trained my reports to use their judgement where appropriate, and bring things to my attention when it looked like it was going to be a problem that needed to be addressed long-term (and was above their paygrade/resources). for exceptional workers (blessed with danger sense, good judgement, aptitude), they had full autonomy (fill me in on your touch points but otherwise, handle your business). you could think of it as an "evented" style of management. with direct monitoring as the core. I've always been a fan of go and see; relative to wait and read report. to be frank, when it was just about the work, things went swimmingly. I made sure the right people had the right styles of work (worked to their strengths) and never assigned work to someone who wasn't capable of it. most importantly, I always took into account a persons limitations (physical, social, mental, personal). day-to-day stuff they manage their own time. ... plus a 5 minute discuss/debrief on long-running projects works well with capable workers. same with the general group dynamics (unless there is an objective problem, I let them run their own thing). and yes, that meant sometimes they had disagreements; but as long as they were adult about it, they usually sorted it out on their own. -- same way I run my direct reports up the chain to my bosses, btw. I tend to alter the corporate culture under my "umbrella" of responsibility.
partycoder 8y ago
"Talking a lot" = distracting a lot. Only interrupt developers if it is urgent. For a developer, resuming a task after an interruption can take time and effort. Using an issue trackers and building discipline around keeping it updated is preferable to polling people for updates constantly. "How is this task going?" -> go to the ticket for that task in your issue tracker and read the status field. If you feel like "talking a lot", don't do it in the areas where developers do their work. It is distracting for developers.
- cimmanom 8y ago
  Status fields aren’t much help when you’re 8 days in on “in progress” for a ticket that was originally estimated to take 2. Often that’s exactly when you need to have a conversation. Scope is creeping; or the engineer is taking a poor approach and needs to talk it through with someone; or there’s some tech debt that warrants investing in refactoring; or the engineer just plain misunderstood the goals. And they’re almost certainly demoralized by now and need encouragement or help seeing a way out of the swamp.
- Nimitz14 8y ago
  I'm a developer and completely disagree with your advice.
- paulgrant999 8y ago
  a status field, does not a person or a persons work effort make ;) ...and if my workers were under the gun, they understood I was there strictly to offer assistance. shit sometimes I pull up a chair and code right next to them (now fangled as "pair programming"). sometimes people need a little help. -- true story, I had a dick client-side manager, whose project was about 2 years overdue, getting raked by the consulting company I worked for (body shop). they put me on the project, I tuned that shit up. johnny on the spot, and six steps ahead of the project/clientside managers. ... about two months in, I'm 20 minutes from closing out the entire project (I took some dev shortcuts to speed shit up - I was always a "high velocity" developer), I'm undoing the hacks (finalizing) to turn in the project, when the clientside manager decides he's going to come in to "motivate" me. if you are a developer, whose ever worked with a cunt of a manager who doesn't know tech/their ass from their elbow.... you know what that means. ... literally minutes away from closing out his entire project, and I quit the project (then got fired from the company). took'em a month to close it out after I left. if the work had been less quality, it would have taken them six months. ;) Now if he'ld shut the fuck up and let me handle my business, would have taken exactly 10 more minutes. and this was after I saved his ass on the project, and saved both of their asses with a direct product demo (pieced one together in under 4 minutes with 10 minutes notice) with the client-side ceo. -- I know who can get shit done, and who is having problems. because I know, whats going on in the projects/devs. and that comes from talking to people. not looking at status fields. if you learn nothing else, go and see. codebase ain't always the codebase/trouble-ticket. its the people writing it.

wokwokwok 8y ago

Please don’t take away from this that you shouldn’t do 1-on-1s, because the parent post doesn’t. If you’re on top of your game, this is totally a valid way to do it. ...but I’ve worked with people who use ‘light touch’ as an excuse for ‘don’t want to do people things, so I’ll just get on with my work’. That’s a failure at everything you’re supposed to be doing. The take away here is talk to people. ...how you do that, though, can vary and still be successful.

paulgrant999 8y ago
I would say, suit it to the person you're managing. me I just trained my reports to use their judgement where appropriate, and bring things to my attention when it looked like it was going to be a problem that needed to be addressed long-term (and was above their paygrade/resources). for exceptional workers (blessed with danger sense, good judgement, aptitude), they had full autonomy (fill me in on your touch points but otherwise, handle your business). you could think of it as an "evented" style of management. with direct monitoring as the core. I've always been a fan of go and see; relative to wait and read report. to be frank, when it was just about the work, things went swimmingly. I made sure the right people had the right styles of work (worked to their strengths) and never assigned work to someone who wasn't capable of it. most importantly, I always took into account a persons limitations (physical, social, mental, personal). day-to-day stuff they manage their own time. ... plus a 5 minute discuss/debrief on long-running projects works well with capable workers. same with the general group dynamics (unless there is an objective problem, I let them run their own thing). and yes, that meant sometimes they had disagreements; but as long as they were adult about it, they usually sorted it out on their own. -- same way I run my direct reports up the chain to my bosses, btw. I tend to alter the corporate culture under my "umbrella" of responsibility.

partycoder 8y ago

"Talking a lot" = distracting a lot. Only interrupt developers if it is urgent. For a developer, resuming a task after an interruption can take time and effort. Using an issue trackers and building discipline around keeping it updated is preferable to polling people for updates constantly. "How is this task going?" -> go to the ticket for that task in your issue tracker and read the status field. If you feel like "talking a lot", don't do it in the areas where developers do their work. It is distracting for developers.

cimmanom 8y ago
Status fields aren’t much help when you’re 8 days in on “in progress” for a ticket that was originally estimated to take 2. Often that’s exactly when you need to have a conversation. Scope is creeping; or the engineer is taking a poor approach and needs to talk it through with someone; or there’s some tech debt that warrants investing in refactoring; or the engineer just plain misunderstood the goals. And they’re almost certainly demoralized by now and need encouragement or help seeing a way out of the swamp.
Nimitz14 8y ago
I'm a developer and completely disagree with your advice.
paulgrant999 8y ago
a status field, does not a person or a persons work effort make ;) ...and if my workers were under the gun, they understood I was there strictly to offer assistance. shit sometimes I pull up a chair and code right next to them (now fangled as "pair programming"). sometimes people need a little help. -- true story, I had a dick client-side manager, whose project was about 2 years overdue, getting raked by the consulting company I worked for (body shop). they put me on the project, I tuned that shit up. johnny on the spot, and six steps ahead of the project/clientside managers. ... about two months in, I'm 20 minutes from closing out the entire project (I took some dev shortcuts to speed shit up - I was always a "high velocity" developer), I'm undoing the hacks (finalizing) to turn in the project, when the clientside manager decides he's going to come in to "motivate" me. if you are a developer, whose ever worked with a cunt of a manager who doesn't know tech/their ass from their elbow.... you know what that means. ... literally minutes away from closing out his entire project, and I quit the project (then got fired from the company). took'em a month to close it out after I left. if the work had been less quality, it would have taken them six months. ;) Now if he'ld shut the fuck up and let me handle my business, would have taken exactly 10 more minutes. and this was after I saved his ass on the project, and saved both of their asses with a direct product demo (pieced one together in under 4 minutes with 10 minutes notice) with the client-side ceo. -- I know who can get shit done, and who is having problems. because I know, whats going on in the projects/devs. and that comes from talking to people. not looking at status fields. if you learn nothing else, go and see. codebase ain't always the codebase/trouble-ticket. its the people writing it.