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