8 ms·

Presumably this is your first time managing programmers. Without ill will, you are most likely a very poor manager right now. Management is a separate skill and

Presumably this is your first time managing programmers. Without ill will, you are most likely a very poor manager right now. Management is a separate skill and, like programming, it takes a long time before you're proficient. So, the first step is to acknowledge that, right now, you are a total newb and to tell yourself that a few times every day. From your description, it sounds like these programmers are not as efficient in their work, or as task/goal-oriented as you'd like them to be, but not that they're completely incapable. Sometimes you will find programmers who can't program; they're hopeless, you have to fire them. But otherwise good programmers can be awful at managing themselves... and you're the manager, after all, so it's your problem to solve. Of course, you don't want to micro-manage them every hour of the day; that's not scalable. Not every aspect of Extreme Programming is applicable to every situation. But a quick morning standup meeting can be a very effective tool. First, you will find out when people get off track and are having problems. Second, it creates some accountability to advance the ball every day. Third, while you must actively work to have the team cooperate instead of compete, it will naturally create some competitive and evolutionary pressure, where the more focused members of your team provide a good example and, over time, can share some of their secrets. Finally, the standup helps reinforce teamwork. If someone is having a hard time with a task, you can respond and say, "hey, you know, Bob's in a good place with what he's working on, why doesn't he help you out today, see whether a fresh perspective can help?"

exelius 12y ago
You're absolutely right, management is not programming. But management is LIKE programming in that there are frameworks and libraries developed by people before you that you can use so you don't have to learn everything the hard way. In this case, I suggest the OP read up on the situational leadership framework [1] (Wikipedia is a good start but I suggest you pick up a book since they explain it far better). It is designed for the exact problem OP is encountering: what to do when you have people with different levels of expertise at a task. In a nutshell, it's about helping your subordinates manage the experience curve by recognizing where they are and providing the right kind of encouragement at the right time. [1] http://en.wikipedia.org/wiki/Situational_leadership_theory http://en.wikipedia.org/wiki/Situational_leadership_theory
- joeyspn 12y ago
  This one goes to my reading list cue..
j_m_b 12y ago
What about having each person give you an oral review of what they did at the end of the day to spot problems?
gregd 12y ago
To elaborate a little more on jonstewarts excellent answer: It sounds like you're comfortable with two of them because, in your words, "Two are like I was". You manage 4 people. You're lucky that you can relate to two of them and their work styles. I say this because everybody works a little differently than everybody else. And everybody is going to have strengths and weaknesses. As a great manager, it's up to you to play to each person strengths. The other two employees may be scatter-brained, so perhaps task them with very specific goals that aren't as time critical as the other ones. The term Rock Star Programmer, is so fucking overused, overhyped and just plain stupid and I wish that it never entered into our vernacular. It's also your job to realize realistically, where your employees have weaknesses (trust me everyone does). A great manager will help bolster areas that people are weak in, in a way that doesn't demean them. Management ain't easy.
jmulho 12y ago
Excellent answer up until paragraph three. Nothing will drive your developers (good and bad) away quicker than an a "quick morning standup", aka daily interrogation. Were you productive yesterday? Will you be productive today? What are your excuses? This innocent attempt to keep everyone on track has all manner of unintended consequences. Here is what happens to your developers calendars: Draw a box around the hour before standup. In that box write "Don't start on anything hard." Draw a box around the half hour after stand up. In that box write "Try to regain focus." Draw a box around the last hour of the day. In that box write "Do meaningless things I can mention tomorrow in standup, if necessary." Difficult tasks are rarely accomplished as a series of daily successes. As a manager, the most important thing to remember about the meetings you schedule is that they are for your benefit. If you are the type of person who needs to know what is going on every minute, you will hold a meeting every minute. When developers need to know what is going on they simply turn around and ask, exactly as often as necessary. One way managers could minimize disruption is to walk up and ask developers what is going on as often as necessary on a per developer basis.
- neukoelln 12y ago
  We also thought this way. We had our daily standup at half past ten, which was right in the middle between coming in and going to lunch. Now we moved it to quarter to two, which for most of us means a bit after lunch. Now we have no interruption throughout the morning, and the hour before the standup we're not working anyway.
  - jonstewart 12y ago
    Yeah, I'm a fan of first thing in the morning--if everyone gets to work at the same time--or after lunch, where it helps ease people back into work whilst digesting.
- e28eta 12y ago
  I'm sorry that standups have been like an interrogation for you. They should really be for the team's benefit. The team as a whole should care about delivering the product, and should use standup to communicate about current progress, and especially to help each other with any blockers. It sounds like these engineers have tasks they think are important: I don't think anyone spends several days setting up a VM for fun. Does everyone have a say in what user stories are worked on? Do they have a mechanism to suggest improvements, and help prioritize them against the rest of the backlog to figure out what's most important?
ArekDymalski 12y ago
> Of course, you don't want to micro-manage them every hour of the day; that's not scalable. While some managers want to stay away from so called micro-managing at all costs (either because they are afriad that their employees won't like it or becuase they are lazy) it has to be said very clearly: There are certain situations when so called micro-management (very precisely set goals with clear metrics, large amount of detailed instructions, frequent controlling and immediate corrections) is absolutely necessary to push someone's growth forward. Of course such management style isn't scalable and ultimately must be changed when the employee's competences grow. It's just an investment into future performance. Of course as in case of every investement you need to evaleate if it makes sense. Assuming that the employee has only one particular area that needs to be improved, the answer usually will be "yes".
geebee 12y ago
Standups, like so much of "agile", could be beneficial to every member of the team. I've insisted on them as a developer. Unfortunately, standups, like so much of "agile", are a perfect disguise for wolves in sheep's clothing. I've been incredibly burned by agile, and I realized it's because agile encourages a developer to let down his or her guard at the wrong moment. Going through the agile manifesto, I can now see how each one of these has gone wrong for me. http://www.agilemanifesto.org http://www.agilemanifesto.org "Individuals and interactions over processes and tools". Right, we all get together, discuss what we're working on. It feels very collaborative. But there will be this tool, this time-tracking system, that we'll enter stuff into, and your name will be next to those things with a deadline. If you don't meet it, we'll interact with you as an individual about why you aren't meeting your deadlines. "Working software over comprehensive documentation". Again, sounds great. Rather than spec'ing out every little detail, let's work together iteratively to get the right product out. Here's the thing - you just allowed the people who are putting your name next to a task and a deadline to never commit to exactly what they're trying to build and by when. The deadlines are yours, but they'll enjoy changing their minds, because, you know, "agile." "Customer collaboration over contract negotiation". The trap has been set, this is where it is sprung. Most developers, I'll guess, aren't truly in contract situations where there are lawyers and signatures and so forth. The tend to work on internal projects. But make no doubt - if someone can turn to you and say "you committed to getting X done by date Y", and it's in there in the system, you are in a contract situation. But because it was "agile", you didn't negotiate properly, and now you'll get rolled. "Responding to change over following a plan". I assure you they will hold your feet to the fire if you don't follow the plain that was clearly in the "contract" and documented in the progress tracker system. However, because it was "agile", you never really got them to commit to what they were asking of you, so they retain the ability to change and adapt. If it suits their purpose, so can you, if not, you're "in breach". If it's internal, this isn't some lawsuit, it tends to be a sit down with people, including your manager (and perhaps a few other managers), where people act like they're all here to solve a problem and get things back on track, with a heavy undercurrent that it's your fault. Standups, while not part of the manifesto, corrupt similarly. Instead of "here's what I worked on yesterday, here's how it went, here's what I'll work on today", they become a daily application of pressure and reminder of deadlines. It appeals immensely to someone who would like micromanage a developer. They're meant to keep communication open in complicated projects where it can be difficult to make estimates under uncertainty (you know, a software project). But they often end up with one person trying to explain complexity to an exasperated (and perhaps manipulative) person who really just wants to apply (often artificial) deadline pressure. Unfortunately, "agile", for all its promise, turned out to be amazingly fertile ground for manipulators. I think this, more than anything else, is what has so badly damaged "agile." Waterfall seems like a discredited old system, and I don't love it either, but it has a huge advantage for developers. It requires people who will insist on and enforce deadlines to state upfront, in considerable detail, exactly what they want.
Avalaxy 12y ago
You might be on to something here, but what else can a team leader do to manage other developers besides organising daily standups?

exelius 12y ago

You're absolutely right, management is not programming. But management is LIKE programming in that there are frameworks and libraries developed by people before you that you can use so you don't have to learn everything the hard way. In this case, I suggest the OP read up on the situational leadership framework [1] (Wikipedia is a good start but I suggest you pick up a book since they explain it far better). It is designed for the exact problem OP is encountering: what to do when you have people with different levels of expertise at a task. In a nutshell, it's about helping your subordinates manage the experience curve by recognizing where they are and providing the right kind of encouragement at the right time. [1] http://en.wikipedia.org/wiki/Situational_leadership_theory http://en.wikipedia.org/wiki/Situational_leadership_theory

joeyspn 12y ago
This one goes to my reading list cue..

j_m_b 12y ago

What about having each person give you an oral review of what they did at the end of the day to spot problems?

gregd 12y ago

To elaborate a little more on jonstewarts excellent answer: It sounds like you're comfortable with two of them because, in your words, "Two are like I was". You manage 4 people. You're lucky that you can relate to two of them and their work styles. I say this because everybody works a little differently than everybody else. And everybody is going to have strengths and weaknesses. As a great manager, it's up to you to play to each person strengths. The other two employees may be scatter-brained, so perhaps task them with very specific goals that aren't as time critical as the other ones. The term Rock Star Programmer, is so fucking overused, overhyped and just plain stupid and I wish that it never entered into our vernacular. It's also your job to realize realistically, where your employees have weaknesses (trust me everyone does). A great manager will help bolster areas that people are weak in, in a way that doesn't demean them. Management ain't easy.

jmulho 12y ago

Excellent answer up until paragraph three. Nothing will drive your developers (good and bad) away quicker than an a "quick morning standup", aka daily interrogation. Were you productive yesterday? Will you be productive today? What are your excuses? This innocent attempt to keep everyone on track has all manner of unintended consequences. Here is what happens to your developers calendars: Draw a box around the hour before standup. In that box write "Don't start on anything hard." Draw a box around the half hour after stand up. In that box write "Try to regain focus." Draw a box around the last hour of the day. In that box write "Do meaningless things I can mention tomorrow in standup, if necessary." Difficult tasks are rarely accomplished as a series of daily successes. As a manager, the most important thing to remember about the meetings you schedule is that they are for your benefit. If you are the type of person who needs to know what is going on every minute, you will hold a meeting every minute. When developers need to know what is going on they simply turn around and ask, exactly as often as necessary. One way managers could minimize disruption is to walk up and ask developers what is going on as often as necessary on a per developer basis.

neukoelln 12y ago
We also thought this way. We had our daily standup at half past ten, which was right in the middle between coming in and going to lunch. Now we moved it to quarter to two, which for most of us means a bit after lunch. Now we have no interruption throughout the morning, and the hour before the standup we're not working anyway.
- jonstewart 12y ago
  Yeah, I'm a fan of first thing in the morning--if everyone gets to work at the same time--or after lunch, where it helps ease people back into work whilst digesting.
e28eta 12y ago
I'm sorry that standups have been like an interrogation for you. They should really be for the team's benefit. The team as a whole should care about delivering the product, and should use standup to communicate about current progress, and especially to help each other with any blockers. It sounds like these engineers have tasks they think are important: I don't think anyone spends several days setting up a VM for fun. Does everyone have a say in what user stories are worked on? Do they have a mechanism to suggest improvements, and help prioritize them against the rest of the backlog to figure out what's most important?

ArekDymalski 12y ago

> Of course, you don't want to micro-manage them every hour of the day; that's not scalable. While some managers want to stay away from so called micro-managing at all costs (either because they are afriad that their employees won't like it or becuase they are lazy) it has to be said very clearly: There are certain situations when so called micro-management (very precisely set goals with clear metrics, large amount of detailed instructions, frequent controlling and immediate corrections) is absolutely necessary to push someone's growth forward. Of course such management style isn't scalable and ultimately must be changed when the employee's competences grow. It's just an investment into future performance. Of course as in case of every investement you need to evaleate if it makes sense. Assuming that the employee has only one particular area that needs to be improved, the answer usually will be "yes".

geebee 12y ago

Standups, like so much of "agile", could be beneficial to every member of the team. I've insisted on them as a developer. Unfortunately, standups, like so much of "agile", are a perfect disguise for wolves in sheep's clothing. I've been incredibly burned by agile, and I realized it's because agile encourages a developer to let down his or her guard at the wrong moment. Going through the agile manifesto, I can now see how each one of these has gone wrong for me. http://www.agilemanifesto.org http://www.agilemanifesto.org "Individuals and interactions over processes and tools". Right, we all get together, discuss what we're working on. It feels very collaborative. But there will be this tool, this time-tracking system, that we'll enter stuff into, and your name will be next to those things with a deadline. If you don't meet it, we'll interact with you as an individual about why you aren't meeting your deadlines. "Working software over comprehensive documentation". Again, sounds great. Rather than spec'ing out every little detail, let's work together iteratively to get the right product out. Here's the thing - you just allowed the people who are putting your name next to a task and a deadline to never commit to exactly what they're trying to build and by when. The deadlines are yours, but they'll enjoy changing their minds, because, you know, "agile." "Customer collaboration over contract negotiation". The trap has been set, this is where it is sprung. Most developers, I'll guess, aren't truly in contract situations where there are lawyers and signatures and so forth. The tend to work on internal projects. But make no doubt - if someone can turn to you and say "you committed to getting X done by date Y", and it's in there in the system, you are in a contract situation. But because it was "agile", you didn't negotiate properly, and now you'll get rolled. "Responding to change over following a plan". I assure you they will hold your feet to the fire if you don't follow the plain that was clearly in the "contract" and documented in the progress tracker system. However, because it was "agile", you never really got them to commit to what they were asking of you, so they retain the ability to change and adapt. If it suits their purpose, so can you, if not, you're "in breach". If it's internal, this isn't some lawsuit, it tends to be a sit down with people, including your manager (and perhaps a few other managers), where people act like they're all here to solve a problem and get things back on track, with a heavy undercurrent that it's your fault. Standups, while not part of the manifesto, corrupt similarly. Instead of "here's what I worked on yesterday, here's how it went, here's what I'll work on today", they become a daily application of pressure and reminder of deadlines. It appeals immensely to someone who would like micromanage a developer. They're meant to keep communication open in complicated projects where it can be difficult to make estimates under uncertainty (you know, a software project). But they often end up with one person trying to explain complexity to an exasperated (and perhaps manipulative) person who really just wants to apply (often artificial) deadline pressure. Unfortunately, "agile", for all its promise, turned out to be amazingly fertile ground for manipulators. I think this, more than anything else, is what has so badly damaged "agile." Waterfall seems like a discredited old system, and I don't love it either, but it has a huge advantage for developers. It requires people who will insist on and enforce deadlines to state upfront, in considerable detail, exactly what they want.

Avalaxy 12y ago

You might be on to something here, but what else can a team leader do to manage other developers besides organising daily standups?