[param]

I am making a transition from being a developer to a manager these days. I consider myself a passionate developer, and hence I never thought twice about spending time beyond 9-5 and getting a job done (as it made me happy). Now that I am a manager, I am working with multiple resources, some of which like to work for work's sake, some are good resources that will only work 9-5, and some losers that won't get a good job done at all.

Could someone explain how they manage people who won't

a)estimate right when given the chance,

b) understand the criticality of the deadlines,

c) put in a fair 40 hr/week if the deadline is still a month away (i.e. start missing internal milestones from day one),

d) not escalate/be concerned unless you probe them etc?

[dkarl]

a) Nobody can be "given" the chance to estimate accurately. Either you already know the code and know exactly what you're going to do, or you're just guessing, hoping that the task will prove similar to something you've done in the past.

b) People are used to being lied to about criticality, and "understanding" the criticality of deadlines is usually code for working extra hard to compensate for planning mistakes, unplanned work, or other people's mistakes. The willingness of developers to work unpaid overtime to meet deadlines should be marveled at and appreciated. It's not like we're respected as professional-class people (doctors, lawyers, etc.) We're just "resources" who are usually suckers enough to work unpaid overtime when needed. Don't complain when we actually do the sensible thing and leave at 6pm.

c) Putting in a fair work week and hitting internal milestones "from day one" are not the same thing.

d) Good managers stay in touch. It's part of the job. Just accept it.

[param]

Agreed. You may want to see another comment I've made where I would be ok if they can explain the delay with a valid reason for it - personal reasons/infrastructure issues/unexpected complexity.

The basic point you are making is that if there are unplanned/under-planned developments, we need to account for them in a way that's humane, rather than forcing the developer to hold on to an arbitrarily identified date. I am all for it, but in my case, I am not getting any good reason for the delay, just a note that things are delayed.

[seiji]

> I am working with multiple resources,

First step: stop calling people "resources"

[potatolicious]

Second step: stop referring to people as "which". "which" is for things, "who" is for people.

Replying to param, but don't want to spam another comment:

> "b) understand the criticality of the deadlines,"

Why is the deadline critical? For whom? What is the programmer's stake in this deadline, and do your people feel like they have been treated fairly?

To answer the first part, ask yourself seriously: what happens if we don't hit this deadline? Does it truly impact the company and/or team, or does it impact you?

I've seen many a time when deadlines are touted as hyper-critical, but have minimal actual business impact. They were hyper-critical because it was critical for the manager to get it done on-time, otherwise he/she looks bad. This is not something I would normally presume about a manager, but you've already demonstrated some misguided overly corporate buzzword-notions in your post.

I personally am much more likely to trust my manager's prioritization of tasks (and thus, deadlines) when I feel that he is looking out for the team (or hell, the company) rather than himself.

[param]

sorry - English is not my first language. (Not fixing the comment to keep yours relevant)

I think my question is being taken the wrong way. Let me try asking again: I have work X to get done. I have a team member who I would like to work on this. I ask them to estimate the work, validate the estimates and then track against the same. In the weekly status calls, if they are behind schedule, can not give a justifiable reason for being behind (like personal reasons, unexpected technical complexity, hardware issues); how does the group manage?

[eru]

Your questions look pretty valid to me. It's a shame that the language barrier leads to down-mods. Especially, considering that you are making the effort and speaking their language in the first place.

(English isn't my first language either.)

[rubinelli]

If you know developers X and Y aren't hitting their deadlines, then a weekly status call isn't enough. You will have to micromanage; this means at least daily one-on-ones, seeing with your own eyes what was produced, testing their finished products, and discovering _what is wrong with them_.

In me experience, poor performers aren't lazy. They either have personal problems, or burned out, or need something but are afraid of asking because, ironically, they thought it would make them look bad.

[rbanffy]

The company I work for had a strong bias towards PMI-ish project management. Once I was discussing some allocation issues and the project manager said we should allocate more "Java resources" (despite the fact the product in question did not use any Java code).

I fired back with a recapitulation of all the "resources" allocated to the project, the "PHP resources", the "design resources", the "testing resources" and, when it came to count him, I mentioned one "powerpoint resource".

It took him about 5 seconds to get the joke.

[param]

heh, sure. I see how my comment is coming off as bitchy and is being downmodded. However, I am genuinely curious. There are people in my team that are currently just working 9-5. There is one guy who is working nights and weekends because he likes it, and then there is one guy that's working (productivity wise) 25-30 hrs a week while missing internal milestones.

Its frustrating to be in my place, because I feel sad for the nightouter when he picks up for the third guy

[potatolicious]

> "because I feel sad for the nightouter when he picks up for the third guy"

Why not talk to the night-coder? The best bosses I have ever had were the ones who actively told me to work less. It's so rare to hear that in our industry that you may just earn yourself some real loyalty.

[edit] To clarify: the guy not pulling his weight is IMHO a separate issue from the guy who works at night. If the guy not pulling his weight is forcing other people to work more though, by all means don't let that happen. Then you have two problems on your hands instead of one.

[param]

Ah, thank you. Now I feel we are on the same page. The nightcoder- talking to him is something I was not considering so far, but now am.

Could we also talk a bit more about the problem I was trying to get around to - how do you solve the second problem? How do I 'by all means don't let that happen'?

[smokinn]

You confront him.

It may make you uncomfortable but it needs to be done. You need to be up front with him and say that lately his performance has been unacceptable and that he needs to correct the situation.

Being honest about it will often fix the problem.

From your vocabulary and planned milestones and weekly status meetings I'm assuming you work for a large company. If he continues under-performing without valid reasons you start the process your company has for getting him fired. You call him in to your office to issue a formal warning with a copy given to HR and explain to him that he's on the path to getting fired if he still doesn't correct the situation. Depending on your company policy you can usually fire after 2 or 3 documented warnings. After the warning, if he still doesn't do anything about it you start putting out job offers for his position.

It's the only way his performance won't sap the energy of the entire team.

[blizkreeg]

Unless the project is the Apollo-11, I have never understood why 9-5 is not sufficient. That's 7 solid hours of work (1 hour for lunch). If pointless meetings consume a lot of that time, I get that may not be sufficient.

Personally, whenever I've put in 7-8 solid hours of coding and/or design/thinking, I'm spent for the day. Done. Over. I just want to give my brain a rest at that point. I don't think it's humanly possible to be working at peak capacity for anything before 10 hours a day. I wish modern workplaces focused more on how to create an environment/culture where employees are in "the zone" more often than just having them put in longer hours. That I believe would produce higher quality work.

This whole thing about expecting programmers to work beyond 9-6 is just sad. I have never once seen a Product Manager or Business Dev guy work late into the night.

[mvp]

It is impossible to estimate accurately. I read somewhere which seem quite valid - "if we can't predict how much time was spent developing something even when we have the finished product at hand, what chance have we got of estimating something that is still up in the air".

About managing people, the best you can do in your situation if you really care is to inspire those you think are not performing as well as they could. Explain how working passionately will ultimately benefit them. Of course, treat them as human beings first and not as resources.

[waivej]

I'm not sure I agree with the estimating thing. Though I've only met one developer/manager that is good at estimating. He works at a steady pace and doesn't cave when people want things faster. It's tough at first but once you deliver on time, they respect your estimates.

He's also the only guy that I know that buys new cars with cash. He just puts away a "car payment" every month. When the old car wears out, he buys a new one.

It's tough to manage people that aren't pulling their weight. Take time to listen to what signals they are giving. If they want to work, help remove their obstacles. If not, do what you need to so the productive people don't get dragged down.

[abstractbill]

There are people in my team that are currently just working 9-5.

Were they hired with the expectation that they would work longer than that? I ask because it's not unheard of to be told you'll be working one set of hours, and then expected to work something completely different.

If no expectations were set at all during the hiring process, that's more the company's fault than the employees' fault.

[pyre]

I think that he's more concerned with dealing with the guy that is not pulling his weight, not with motivating the 9-5'ers to work overtime.

[rimantas]

More than once I had a wish managers would have read this book: http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

[waivej]

When I was made a manager, I had the company buy cases of that book: one for each person in the department.

[edw519]

As a former developer turned manager turned developer again, a few suggestions:

1. Never lose your developer mindset. Personally, I have great difficulty respecting a non-technical manager of technicians. I bet I'm not the only one.

2. Manage things. Get good at project management. Very good. A good plan, agreed upon, well built and administered, will always be your friend. Something for everyone to fall back on when things get hairy.

3. Don't "manage" people, lead them. Preferably by example.

4. Everyone has problems. Now that you understand that, don't let people's problems interfere with their work or nothing will ever get done.

5. Learn the difference between issues and details. Focus on the issues. Don't waste too much time on the details. And get your team to do the same.

6. When all else fails, communicate. When all else goes well, still communicate. Never underestimate the power of communication. You'd be surprised how much slack others will cut you if you're simply open and honest with them.

7. Treat everyone else the way you'd like to be treated. (This goes for everyone, not just managers.)

8. Listen at least as much as you talk. (This also goes for everyone, not just managers.)

9. Get stuff done. And have fun doing it.

10. Lighten up. You'll be fine.

[norbu09]

your number one task as a manager is to find suitable sub tasks a developer can estimate on. this implies that you actually know your developers and their skills and give them only the amount of work to judge on they are comfortable with. i can judge on a project that is worth some months of work easily, a junior developer probably only looks about 2-3 days ahead.

[richieb]

a)estimate right when given the chance,

First look up the definition of "estimate".

Second the shorter the estimate the more accurate it will be. So, I a developer says I can do this in a day that's probably mostly right.

But if he says that he can build something in 3 months, that's most definitely wrong.