> Everything I know about dealing with technical people is from the > school of hard knocks :-)
And class is definitely in session! Thanks to all for your guidance with this. > I don't think it's something that can be taught or > properly described adequately. But there are some obvious concepts: > > Programmers are essentially not too different from any other type of > technical people, and you are already very familiar with those just by > reading gentoo-user. All that stuff we do here wrt top-posting, html > mail, udev and pulseaudio developers having strange ideas and > (being perceived to be) ramming it down people's throats - all that > stuff applies. > > I don't know how you personally deal with such things but whatever you > find works is probably good enough. > > Techies don't like being second-guessed and told what to do when they > are perfectly capable of doing the job properly. This is just a normal > human reaction really and is always solved by simple communication. You > always have to get to know people first, to get a grip on their > personality, and then find out how to successfully interact with them. > If you are married, consider what it took to learn how to interact with > your wife smoothly :-) > >> Could you tell me really briefly what a manager *should* do? > > Ouch. That's another encyclopedia-length answer :-) > > I'll give you a short oblique answer that seems to work for me: > > Managers do not lead, they serve. They are not there to call the shots, get > covered in glory, > be seen as the best of the best or issue decrees. I've been fortunate to > have had a few good managers in my working life and they all seemed to > instinctively do the same very important thing: make it possible for me > to do my job. > > They would deal with finance issues, they would help find out where new > hardware was in the shipping process, they would be a buffer between me > and the customer (or between me and the annoying executive). They would > publicly cover me in glory when things worked out well and cover my ass > when they didn't. And all too often they would clam me down when I went > off on one of my rants. The point is, the manager took care of > everything on the project except the part about being a programmer :-) > > Good managers are very good at observing. They don't impose themselves > on the job at hand, they watch it and see where things are going great > and where things can be improved. They are also patient and only > try to improve one thing at a time, getting that thing right then move > onto the next thing. > > My current manager is great, we're both a similar > age (mid 40s), and we have an understanding - I'm good at my job and > he's good at his. It took a while for both of us to recognize this and > build that trust but I think we got it right eventually. The key thing > was to communicate to the other guy and be honest and listen. In the > beginning there was some "alpha-male" posturing going on and we had to > drop that somewhat quickly :-) > > He's also particular in finding out what the whole team thinks about > things, so really listens to our input. > > That's what I find works for me, but unlike computers I can't put it > down in step-by-step fashion that will give a certain result. > >> >> I think I'll try to manage a single programmer working few hours and >> see how it goes. My asking stupid questions is due to my lack of >> experience and there's only one way to fix that. > > Sounds to me like you already grasp the essentials :-) > > Good luck with the project. > > Oh , one last thing: despite all appearances to the contrary, most > people out there can be trusted to do the right thing as far as they > are able, and do want to do a good job. Don't let occasional lapses > cloud your view of this. Everyone makes mistakes sometimes, we all must > learn to be tolerant when it happens. Sorry for the scrolling but that stuff just can't be snipped. Regarding proposals, schedules, roadmaps, milestones.... I've got a list of a million changes to make to my website's front-end and back-end. There is a very specific way I want things to work, so everything is broken down to a granular "task" level. In the old days I would just dig in and start grinding away on things, but I'm ready to pass that duty on to a real programmer and I can't imagine that it's productive to have him submit a proposal, set up a schedule, generate a roadmap, and create milestones for every little thing that needs to be done. Can I hire one guy and give him one task at a time and see how it goes without any of that stuff? - Grant
