4 ms·

I suspect this is going to rub people the wrong way but the best way to manage a team is, in my opinion, is to not manage them. By far the biggest issue for me

I suspect this is going to rub people the wrong way but the best way to manage a team is, in my opinion, is to not manage them. By far the biggest issue for me getting stuff done is managment. I've sat in several companies, at times with not a lot of work, because managers aren't willing to sign off. Motivation dwindles and people leave. Of course you have to hire people you trust. You need to actually trust them and get out of their way. Let the technical people make the technical decisions, let them do the work, remove obstacles and make sure you're not one of those obstacles. You will pay the price that a couple of non-contributors will fly under the radar for a bit longer, but between git logs and productivity tools you should still be more than capable of gauging productivity, which should be a binary. Regarding the article, written communcation is important even if you're in the same office. Listen, it's fine if John tells Steve about foo, but unless it's written down Bob and whoever else wasn't privy to that conversation isn't going to know and you're going to need to repeat yourself with every hire. If there is a significant difference between what you do with remote folks and what you do with guys in your office, you're probably doing it wrong with the guys in your office and you just haven't figured out how much time you've wasted having to explain everything verbally to new guy Dave.

winter_blue 13y ago
> the best way to manage a team is, in my opinion, is to not manage them. This is one-view of management. It's called the "hands-off" manager. He trust him team to get the work done, and operates in a sort-of hands-off way. For the longest time, I felt like this was the right way to manage teams at technology companies, but recently I read a piece that argued that the middle ground -- ie. somewhere between being hands-off and micromanaging (the other extreme), was ideal. Now I'm not so sure myself if this is right, but it's cast a bit of doubt to my long-held notion that off-hands was the best way to go.
mjolk 13y ago
>You will pay the price that a couple of non-contributors will fly under the radar for a bit longer, but between git logs and productivity tools you should still be more than capable of gauging productivity, which should be a binary. You're missing part of the picture here - time spend helping other employees is time that an employee isn't making commits. Or, conversely, unless you're looking into the contents of a commit, you don't know the difference between someone making many, regular commits on an easy issue and the person that commits relatively seldom, but contributes code to address harder/meatier problems. >Regarding the article, written communcation is important even if you're in the same office...you're going to need to repeat yourself with every hire. Documentation is great, but it's time consuming and much can change in a few weeks time. Write down the stuff worth keeping around for months, and let go of the rest -- giving a new hire volumes of text regarding irrelevant conversations/processes is a sure way to increase spin-up time.
- ownagefool 13y ago
  > You're missing part of the picture here - time spend helping other employees is time that an employee isn't making commits. Actually I do get that, that's why I said its binary. Don't compare Bob, Steve and John. Look at them individually and see if they're contributing. Set a minimum standard and stop caring about squeezing every little bit out of them. You might run into a problem if all you ever do is mentor, but then your manager should be aware of that and view you in that context. > Or, conversely, unless you're looking into the contents of a commit, you don't know the difference between someone making many, regular commits on an easy issue and the person that commits relatively seldom, but contributes code to address harder/meatier problems. Following my advice doesn't preclude you from looking at the context of the commits, my point was leave the fucking team members alone unless you have a good reason. Bobs not doing a lot of projects, look at what he actually does and validate him. Steven has almost low commits? Look at it in the context of the problem he's working on and judge him based on that. Only step in when theres a real need, otherwise leave them alone, you'll just make things worse. > Documentation is great, but it's time consuming and much can change in a few weeks time. Write down the stuff worth keeping around for months, and let go of the rest -- giving a new hire volumes of text regarding irrelevant conversations/processes is a sure way to increase spin-up time. No, you should give a new hire a piece of A4 that tells him how to get up and running. You need a network login? It should tell him where to go. Need to do something to project? Get it from git, vagrant up. Expected to be on IRC? Heres the creds. Need more info? Heres the Wiki. In the wiki, you only need to give specific minimal information such as specific repo the project is in, steps to push your changes, etc. Anything non-standard as your hires should know how to do their job or to google it and figure out. I never said anything about giving them irrelevant conversations or processes, I said the info needed to be a remote worker is exactly the same as one in the office and it's pretty much always the same a) Where do I find this shit? b) what does it use? c) Any gotchas? d) Ok fixed, how do I make my changes live? The only exception is if you're training juniors, they might need you to actually talk to them about work now and again, everyone else should get on with it from the above.

winter_blue 13y ago

> the best way to manage a team is, in my opinion, is to not manage them. This is one-view of management. It's called the "hands-off" manager. He trust him team to get the work done, and operates in a sort-of hands-off way. For the longest time, I felt like this was the right way to manage teams at technology companies, but recently I read a piece that argued that the middle ground -- ie. somewhere between being hands-off and micromanaging (the other extreme), was ideal. Now I'm not so sure myself if this is right, but it's cast a bit of doubt to my long-held notion that off-hands was the best way to go.

mjolk 13y ago

>You will pay the price that a couple of non-contributors will fly under the radar for a bit longer, but between git logs and productivity tools you should still be more than capable of gauging productivity, which should be a binary. You're missing part of the picture here - time spend helping other employees is time that an employee isn't making commits. Or, conversely, unless you're looking into the contents of a commit, you don't know the difference between someone making many, regular commits on an easy issue and the person that commits relatively seldom, but contributes code to address harder/meatier problems. >Regarding the article, written communcation is important even if you're in the same office...you're going to need to repeat yourself with every hire. Documentation is great, but it's time consuming and much can change in a few weeks time. Write down the stuff worth keeping around for months, and let go of the rest -- giving a new hire volumes of text regarding irrelevant conversations/processes is a sure way to increase spin-up time.

ownagefool 13y ago
> You're missing part of the picture here - time spend helping other employees is time that an employee isn't making commits. Actually I do get that, that's why I said its binary. Don't compare Bob, Steve and John. Look at them individually and see if they're contributing. Set a minimum standard and stop caring about squeezing every little bit out of them. You might run into a problem if all you ever do is mentor, but then your manager should be aware of that and view you in that context. > Or, conversely, unless you're looking into the contents of a commit, you don't know the difference between someone making many, regular commits on an easy issue and the person that commits relatively seldom, but contributes code to address harder/meatier problems. Following my advice doesn't preclude you from looking at the context of the commits, my point was leave the fucking team members alone unless you have a good reason. Bobs not doing a lot of projects, look at what he actually does and validate him. Steven has almost low commits? Look at it in the context of the problem he's working on and judge him based on that. Only step in when theres a real need, otherwise leave them alone, you'll just make things worse. > Documentation is great, but it's time consuming and much can change in a few weeks time. Write down the stuff worth keeping around for months, and let go of the rest -- giving a new hire volumes of text regarding irrelevant conversations/processes is a sure way to increase spin-up time. No, you should give a new hire a piece of A4 that tells him how to get up and running. You need a network login? It should tell him where to go. Need to do something to project? Get it from git, vagrant up. Expected to be on IRC? Heres the creds. Need more info? Heres the Wiki. In the wiki, you only need to give specific minimal information such as specific repo the project is in, steps to push your changes, etc. Anything non-standard as your hires should know how to do their job or to google it and figure out. I never said anything about giving them irrelevant conversations or processes, I said the info needed to be a remote worker is exactly the same as one in the office and it's pretty much always the same a) Where do I find this shit? b) what does it use? c) Any gotchas? d) Ok fixed, how do I make my changes live? The only exception is if you're training juniors, they might need you to actually talk to them about work now and again, everyone else should get on with it from the above.