1 |
On May 29, 2012 3:39 PM, "Grant" <emailgrant@×××××.com> wrote: |
2 |
> |
3 |
> >> >> I'll be getting my feet wet with this shortly. Any other tips |
4 |
> >> >> regarding the management of one or more programmers working on |
5 |
> >> >> various small web projects? Maybe workflow or any key procedures |
6 |
> >> >> a newbie manager should follow? |
7 |
> >> > |
8 |
> >> > You can get away with almost anything except these two things: |
9 |
> >> > |
10 |
> >> > Do not micro-manage |
11 |
> >> > Do not tell them how to do what they do |
12 |
> >> |
13 |
> >> Could you give me an example of this last one? |
14 |
> > |
15 |
> > - I see you are using Perl with hashrefs to do function xyz. Have you |
16 |
> > considered (i.e. I would like you to) using $INSERT_SOMETHING_HERE? |
17 |
> > |
18 |
> > - Fiddling with the roadmap. Somehow, this always ends up like the |
19 |
> > homeowner overriding the architect and trying to get the roof up |
20 |
> > before the walls. |
21 |
> > |
22 |
> > - Giving "advice" on the process such as saying how awesome a concept |
23 |
> > stakeholders and product owners are in Scrum. But they use |
24 |
> > ExtremeProgramming. |
25 |
> > |
26 |
> > - Wanting to personally review the code often. I've seen some managers |
27 |
> > want to do this daily. |
28 |
> > |
29 |
> > - Get personally involved on their level. |
30 |
> > |
31 |
> > |
32 |
> > All these things class as interference. Managers and owners who do this |
33 |
> > have miles of justifiable reasons for doing so, but it's always hogwash |
34 |
> > - they interfere, plain and simple. |
35 |
> |
36 |
> This is really interesting to me. Is there a forum/website/book with |
37 |
> more gritty, practical advice like this on managing programmers? |
38 |
> These are the kinds of mistakes I will definitely make if someone |
39 |
> doesn't tell me not to. |
40 |
> |
41 |
> Could you tell me really briefly what a manager *should* do? |
42 |
> |
43 |
> I think I'll try to manage a single programmer working few hours and |
44 |
> see how it goes. My asking stupid questions is due to my lack of |
45 |
> experience and there's only one way to fix that. |
46 |
> |
47 |
> - Grant |
48 |
> |
49 |
|
50 |
Off the top of my head : |
51 |
|
52 |
* It's OK to ask the team about their roadmap and milestones schedule, and |
53 |
even raise objections and/or suggest changes AT THE VERY START OF THE |
54 |
PROJECT. |
55 |
|
56 |
* When the project is under way, DO NOT EVER interfere unless asked. |
57 |
|
58 |
* It is okay to regularly (weekly or biweekly) ask for progress report with |
59 |
regards to the previously agreed milestone schedule. If delays happen, you |
60 |
must also ask what the cause of the delay is, and what the team plan to |
61 |
overcome and/or compensate |
62 |
|
63 |
* Ask the team to keep a 'weather report' regarding the project, updated |
64 |
continually, stored in a shared folder. This is less a report to you than |
65 |
something you can present to your superiors when they start asking, "Are we |
66 |
there yet?" |
67 |
|
68 |
Rgds, |