Managers and developers: Are you two teams or one?

One of the reasons why I love Dilbert so much is because Scott Adams really feels the pulse of the typical IT organization. How many times have you seen the above situation? In one project, the whole world (including me, and I was not even a part of the project) knew that the project was burning, except the people who really needed to know — the managers and stakeholders — had no clue as to the real state of the project.

Why does this happen?

Most manager-developer problems in a software company are caused by one thing: trust, or rather, a lack of trust. Managers do not trust the developers to do any work. They believe that the developers have to be pushed, otherwise nothing will get done. Developers in turn do not trust the management to cover their back. They believe that the managers will screw them when things go wrong. As a result, instead of working together as one team, they become two teams, each defending their turf from outside attack.

Once that happens the project is as good as dead. Communication across the border will virtually stop.

Back to the above cartoon:

Dilbert is comfortable telling Wally the real situation of the project because he knows Wally will support him. After all they are in the same 'team'. When he tells the PHB that the project is fine, he doesn't really mean that its fine. He knows if he brings up any issue, the PHB will blame the team. What he is really communicating is "I don't want to talk to you. I'll say fine so that you go away quickly."

If you are a manager, be sure that you cultivate trust with the development team. What better way to do that then to show that you are on their side. When the team asks for more RAM for their computers, do you get it or do you say that its out of budget? When the team says that the schedule is too short, do you tell that to the customer and try to find a solution or do you ask the team to work weekends?

This is one reason why I like agile processes and the Scrummaster role in particular. Scrum tries hard to make the Scrummaster fit in with the team, to support the team, to enable the team to perform. In exchange, when things go wrong, the team is often more open in bringing up issues because they are all one team, working together in the same direction. They know that the Scrummaster will help in solving the problem rather than blaming the team.

Can your programmers read code?

Surprising as it might seem, programmers spend a majority of the time reading code, not writing code. Take my case. Even though I am working alone, on a new project, I spend the majority of my time reading code. That's not just my code, but also the code in the various open source modules that I'm using. At some point or the other, I've had to delve headlong into the source of Django, Dojo, Mochikit and ToofPy, and try to make out what the code is doing by ignoring the docs (if there are any!) and reading the source. If you are working in a team, the effect is magnified even more.

This was no sudden revelation. When I was hiring, I had a standard question to see if candidates could read code. Here is the code snippet.

int function f(somestruct *a) {
    int x = 0;
    if (NULL == a) {
        return 0;
    }
    x += f(a->left);
    x += 1;
    x += f(a->right);
    return x;
}

Candidates had to try to figure out what function f was doing.

First, I expected the candidate to see the left and right fields and guess that "a" was a pointer to a binary tree of some sort. I then expected the candidate to see the pattern of the recursive calls and guess that it was a tree traversal (inorder in this case). Once that's done, its simple to try out the function with some data and figure out what it does (count the number of nodes).

Given that everyone learns about binary trees, and especially inorder traversal, you would have expected many to get it right. Surprise! Only a few have ever got it correct.

Most answers were something related to linked lists or arrays. It seemed that every programmer when confronted with a pointer in any form assumed it was related to linked lists!!

To be successful at code reading, it is the ability to execute the program in our mind that needs to be developed. This is a learned skill, developed by just reading lots of code.

One conclusion is that many programmers don't spend enough time reading code. It also explains why in many teams, most code becomes spaghetti — programmers can't read the original code, so they hack their fixes.

So, do you check to see if programmers can read code? As an aside, you can now find out how most programmers can't write code either.

Performance reviews reviewed

Harvard Business School's Working Knowledge newsletter has an article by James Heskett titled What's to Be Done About Performance Reviews? that is worth reading. James first tries to clarify why we have performance reviews in the first place:

Perhaps a more important issue is the objective of the review itself. Is it to weed out poor performers? To recognize the so-called A players? To provide the basis for compensation decisions? To provide clues to future opportunity within the organization? To map out an individual plan for personal development? All of these? Too often this is unclear. Is it any wonder then that managers, many of whom receive little or no training in how to do it, conduct the task of reviewing performance so poorly?

Most of the performance reviews that I have been involved in have not gone as well as planned. Why?

Their goals were not well defined: Why exactly were we conducting the review? The reviews were used to determine salary, promotions, past employee performance and future employee development. With virtually everything riding on one review, it is unsurprising that most of us hated it, much like a final exam at school.

They are too infrequent: A recurrent theme in the comments is that performance feedback should be a continuous process between the manager and the reports, not a once a year event. The feedback should be a conversation, not a test. Employees also need feedback at the time of the event, not many months after.

They are too backward looking: The reviews that I have been involved in have tended to be too backward looking. They spend far too much time analysing what happened in the past and not enough time about what should be happening in the future.

Some interesting comments. Jon Clemens says:

In my experience, the nature of reviews at most companies is overly burdened with administrative headaches involved with passing documents back and forth, knowing when things are due, and getting access to timely, relevant information. This in large part contributes to the standard practice of pain that is associated with many company's reviews.

Thad Juszczak says:

Too often I have seen managers tell employees "good job!" and the employees have interpreted that as "outstanding performance!" Managers should not be waiting for the once or twice a year period when feedback and performance results are formally recognized. If either the managers or employees are "surprised" during the formal review process, then someone was not doing their job or listening.

Anonymous says:

The most effective model I have had to implement was Deming-philosophy-based and assumed that everyone did a satisfactory job and did not tie performance to reward. However, we did add to that skill-based pay or project/performance goals (3-5) that would support the organization or department strategic initiatives or self-development. Also, good performers were able to get promoted. This is when we achieved the most growth in our department and organization; employees were put in control of whether or not they achieved their goal and therefore their reward. Performance issues were addressed in real time, not once a year at review time.

And finally, B.Greenspan says:

I have known many colleagues in other organizations where the review systems are essentially "fear based." How can a person get a helpful review when the manager is more fearful of his or her review?

I'll close up this post now. The original article has 93 comments plus a closing summary so do check it out.

Software Project Management — A short story

Since returning to Chennai, I've been working on a project management tool for small, distributed and agile teams. To illustrate my vision for the product, here is a small story. Do you find any part of the story familiar? Are there any characters that you can relate to? Maybe some of this stuff happens in your project. Solving this kind of problem is what I'm setting out to do.

---

The characters

Geoff (Male, 42)

Geoff is a manager at the LoansNow bank. He wants Quality Software Inc to develop an IT system to automate some processes. This is the third time that Geoff is trying to get this system built. The first two times were complete disasters and left a bad taste in Geoff's mouth.

Quote: “If I dont ask for lots of reports, I'll never know what the hell is happening to my project”

Susan (Female, 38)

Susan is a senior manager at QoS Inc. She spends most of her time soothing the nerves of her customers. ‘Yes, you will have your software on time and on budget,’ she tells them, but she doesn't believe it herself.

Quote: “The developers have gone dark again! What do I tell the customer now?”

Alex (Male, 31)

Alex is the project manager for the LoansNow project. Alex finds himself in a tough position, stuck between an irrational customer and the unpredictable developers.

Quote: “Hey! I just remembered something else that we need to do”

Barbara (Female, 29)

Barbara is a senior developer. She has years of experience developing solutions for a number of clients, right from when she was 15. She thinks that software development will be so much better if there were no customers.

Quote: “Not another change in the requirements!”

Kevin (Male, 30)

Kevin is a senior developer leading the second team in Chicago.

Quote: “Why does the other team always mess up?”

---

“Susan, I still haven't got my status report.” Geoff's voice thundered through the phone.

“Alex is working on it” I replied. “You'll have them by this evening.”

After the call, I stopped by Alex's cubicle. Alex is the project manager for this project. We call him the Scrummaster.

“How is the report going?” I asked.

“I'm almost done. Why does he want the reports every week? Susan, it's insane! I spend two days of the week preparing this damn report, and I'm not sure that he even understands what is on it.” Clearly, Alex isn't happy.

Both of us know that the time spent preparing the report can be better utilized in actually managing the project, but what are we to do? We are the third company that Geoff has given this project to. The previous two attempts were complete failures. Not only were they over the schedule, but the delivered system was unusable. Geoff had no idea what was going on till the system was delivered. Geoff is under pressure to make sure that the project goes through smoothly this time, and one thing he has learnt the hard way is that he needs visibility into the project.

I take a look at the report. It contains a bulleted list of tasks completed this week. Visibility. It's that ugly word again. I sympathize with Alex. After all, I spend a couple of days every week writing up a report to email to my boss back at headquarters. It's a pain, but they need to know what is happening.

“How is the project going?” I ask.

“Alex!” A voice rang out from the distance. It was Barbara, our technical lead. Barbara looked angry. She quickly walked down to Alex's cubicle.

“Alex, you won't believe it. It's the Chicago team again. Kevin didn't do the multiple edit feature. He thought that we were going to do it. I thought we made it clear in yesterday's call that it was reassigned to Kevin. Alex, this is crazy. We have a release every two weeks, and these mistakes take up valuable time.”

Alex looked at me. I knew what that look meant. Just a couple of releases ago, a vital feature was not implemented because of a misunderstanding between the teams.

“Let me think about this again,” I said and went back to my cubicle. This was a recurring problem and no solution had been found yet. I decided that writing things down might help. I got myself a coffee and headed to the conference room. Fortunately, it was empty. I took a marker and started to write:

• Communication problems
  • HQ needs to know how the projects are going (once a week)
  • Geoff needs to know what is happening (once a week)
  • Alex needs to keep track of the project (daily)
  • Barbara and Kevin need to synchronize their teams to the current project status (daily)
  • Any changes made by Barbara, Kevin or Alex needs to be propogated to everyone else on both teams (immediately)

Below that I list out our current practices and problems with them:

• Current practices
  • Weekly status report to Geoff
    • Takes two days a week out of Alex's schedule
  • Weekly status report to HQ
    
    • Takes a couple of days a week out of my schedule
  • Daily call between the team here and in Chicago
    
    • Great for status, but details tend to get missed out or misunderstood
  • Excel sheet maintained by Alex
    
    • Alex seems to be the only one who sees this, the rest of the team hardly open it
    • The situation is even worse in Chicago, they hardly ever open this file
    • Everyone thinks they know what they should be working on, but they don't synchronise with the spreadsheet
  • Chart maintained by Barbara's team
    • It's only visible to the team and anyone else who can physically walk there, which rules out Geoff, HQ and Kevin's team

I think for a while. Then I add another two lines below that

• Excel sheet is not visible enough
• Chart is not visible enough

Dang! It's that visibility word again. What a mess. I finish my coffee and look at the whiteboard again. "This is stupid," I think to myself. "Just look at the effort spent in synchronizing everyone and it doesn't even work very well".

I take the digital camera by the side of the whiteboard and take a picture of the board. I email it to my home account. I also take the opportunity to check my mail. There is a mail from Kevin. He is not happy either. He blames our team for the misunderstanding. He suggests that Alex mail out the final task sheet daily after the call. That sounds like overkill. I shut down my computer. It's been a tiring day.

Back home, I take a shower and cook my dinner. Once dinner is over, I take some time to think about the problem again. There is only one project, so why is it so hard to keep everyone in sync? Then it hits me. The DRY principle. The DRY principle is short for Don't Repeat Yourself. It makes sense that if there is only one project, there should be only one authoritative source of information concerning that project. Since everyone needs information about the same project, we can just point to this source and they can get information out of it. Why are we creating lots of different sources and reports and struggling to keep everything consistent?

I take out my notebook and make some notes:

• Keep project information DRY
  • The information should be accessible online. This is for those who cannot be physically present.
  • The information should cover the needs of the various parties. In this project, that would be Geoff, HQ, Alex, Barbara, Kevin, the two teams and myself.
  • The information should be easy to change. That will make sure everyone uses it.

I am on a roll now. I add few lines below that:

• As a side bonus, neither Alex nor I would have to prepare reports, leaving us free to concentrate on our work
• This is great. The tool will free us from doing this kind of silly work and let us concentrate on the things that really matter.

Only one question remains. Is such a tool already available or would we have to roll out our own?

A case study in poor management

If you dont follow cricket, skip to the lessons to learn section below

India got thrashed by South Africa in the cricket match a couple of days ago. Well, no surprise there. The Indians have always struggled in South Africa. What was a surprise was that the BCCI (the Indian cricket board) vice-president, Shashank Manohar came out and said that if it were up to him, none of the players would be paid a single penny. Quoting:

Manohar said the board was not to be blamed for the team's poor performance. "We are administrators and we have done our utmost to provide the players with the best of facilities and support staff. It's the job of the players to deliver on the field, not ours. We at best can take corrective action and measures."

This is pathetic for a number of resons. If Mr.Manohar feels that the players are not good enough, the BCCI should take responsibility, because they are the ones who selected the players. If Mr.Manohar feels that their technique on fast pitches is suspect, the BCCI has to again take responsibility, because they prepare slow pitches for domestic games. When will the BCCI learn that you cannot 'get acclimatised' to fast pitches with one warm-up game, and that it takes years of playing on these pitches to learn to handle them? Mr.Manohar is trying to wash his hands off the matter and put all the blame on the players, when in fact, the majority of the responsibility falls on the BCCI.

Lessons to learn

This is a perfect case study of what not to do. Here are some lessons to be learnt.

How many times have you heard a manager complain that the people under him are not good enough? Pretty often I'm sure. Managers, remember that you hired the people. If they are not good enough, you should take responsibility for it. Now, it is perfectly okay to make hiring mistakes. Everyone does it. But never say that "the person is not good enough", say instead "I made a hiring mistake", and then move forward from there.

Sometimes you don't hire the people under you. Maybe you moved to a new team and have to work with the existing team members. Can you then say that the people are not good enough? No. As a manager, one of your responsibilities is to make sure that the right people are doing the right work. When you take over a team, the first step is to make sure you've got the right people, and take steps to correct the situation if you dont.

Here is a situation: You have a great developer whom you promote to a Project Manager. Management requires a different set of skills to development, and the same person who was so good with development now struggles with management. Do you find this situation familiar? Different situations require different skills. These skills dont magically appear on people as the situations come up. The manager should have an idea of the skills that will be required, and have a personal development plan to help the team members acquire the skills that they are missing. Most managers do not do any personal development and then blame the team member when a situation arrives that the person is not equipped to handle.

Another golden rule is that you always back your team. Within yourselves, you can sort out any issues that need sorting out, but to the external world, you are together. You celebrate together, and you face the music together. When the going gets tough, you face the music on behalf of the team. You never, ever, abandon the team. Yet, when facing the heat, we often see managers who turn round and push the blame on the team. If you stick with the team, you will earn trust and respect, otherwise the team members will only remember you as the weasel who backstabbed them.

Management is unique because you are responsible for the results even though the actual work is done by someone else. A great manager helps others achieve results. The key word here is 'help'. Not 'forces', not 'commands', but 'helps'. How few managers there are who have that attitude. Jack Welch said it best — Before you become a leader success is all about growing yourself. Once you become a leader success is all about growing others.

This post is a part of the selected archive.

Handling conflict

Conflict. It's that word again. We have all faced it and most of us would rather not discuss it, but sooner or later you will be faced with such a situation and it's helpful to be able to understand it. In this article, I will discuss what I understand by conflict, and how we can handle it.

Conflict - good or bad?

Let's face it. People are different - that's what makes us people rather than machines. People with different viewpoints will naturally see things differently, inevitably leading to conflict.

A complete lack of conflict represents a dangerous situation. One possibility is that everyone thinks and behaves the same way. This represents a lack of diversity in the group that can easily lead to not exploring alternate viewpoints and 'groupthink'. Another possibility is even worse - that team members are afraid to speak up, due to some underlying fear. Most commonly, those who present alternate viewpoints are told that they are not 'team players', and the person in question stops raising objections from then on.

To a certain extent then, conflict is essential. It represents the heterogeneity of the group and leads to the exploration of alternate viewpoints.

It is all too easy however, to get caught up in a situation where you are forever arguing with someone with no end in sight. This happens when good conflict degenerates into dysfunctional conflict. After a point, the arguments are no longer on the merits of each case, but tied into the egos of the participants. A decision at that point takes political connotations and is perceived as an attack against the 'loser' of the conflict, which in turn leads into rapidly deteriorating relationships between all those involved.

Thus we see that conflict can be both good and bad. If you have no conflicts at all, then that is a sign that you need more diversity. In the rest of this article I will only talk about dysfunctional conflict.

Alignment

The first step in conflict resolution is alignment. The most obvious form of conflict is when two individuals/teams/groups are working in opposite directions. There are two possible reasons for this. One reason is that the groups are deliberately sabotaging each other due to political reasons. If this is case, the conflict is just a symptom or some other root cause, and you need to go fix that root cause. You have bigger problems.

The other reason is where both teams think that they are doing the right thing, but because there is no common vision, they are going in opposite directions. Both are convinced that they are doing the right thing and wondering what is going on with the other group. The result is a conflict where both sides are convinced about their righteousness. Resolving these conflicts is simply a matter of aligning both groups to a common vision, which of course is easier said than done and is left as an exercise to the reader :)

Handling conflict

Even when you have two people working to the same goals, it is likely that there will be conflicts in the various ways to get to that target. How can these conflicts be handled?

Acknowledge the conflict: The first step is to acknowledge the conflict. Acknowledge both sides in the conflict. Listen to both sides and make sure that they both get heard. The worst possible course of action is to pretend that a conflict does not exist or ignore it and hope that it goes away. First, it will not go away. Second, people want to be heard. It makes then feel empowered and feel that they are valued. Ignoring the individuals in the conflict sends a message that you don't care for their issues. Simply acknowledging the conflict says that you care about what they are feeling.

Separate the problem from the person: The next step is to separate the problem from the person. In any conflict, both sides have something invested in their position, which ties in their viewpoint with their ego. As long as that exists, it is impossible to solve the problem without making it seem personal. By separating the problem from the person, you can attack the problem without attacking the person.

Attack the problem together: Having got the problem in front of you, you can all discuss the problem together. By solving the problem together, you ensure that both parties will find the final solution acceptable. This is in contrast to mandating a solution, where one party might not like the solution but might accept it in order to close the issue. Remember, resolving a conflict is not about closing the issue, but about a solution that everyone feels good about. If one or both of the groups involved is not satisfied with the solution, you can be sure that the conflict is still simmering under the surface and will come out with more force the next time.

Example: How not to handle conflict

Amy: We need some way to bring new team members up to speed
Bob: We need some documentation
Chris: NO! We don't need more documentation

Amy: Chris, Bob has a lot of experience at this, maybe you should listen to him
Later...
Amy: Chris, you are always arguing with the team. You need to be a team player, not a disrupter
Chris: #$@!#$

The above is a case of attacking the person. Chris is likely to be extremely unhappy at the 'resolution'. Relationships are going to go downhill.

Example: A better way

Amy: We need some way to bring new team members up to speed
Bob: We need some documentation
Chris: NO! We don't need more documentation

Amy: Why do you say that?
Chris: Nobody reads documentation
Amy: Okay, that could be a problem. Bob, what do you think?
Bob: Yes, but the current situation is even worse
Amy: What other alternatives can we think of?
Chris: How about mentoring?
Bob: I'm not sure. We don't have the time to mentor each new person
Chris: Mentoring is the only way to teach the details that get lost in documents
Amy: Maybe we can have a small light document that covers the core areas, and we have mentoring to transfer knowledge of the details?
Chris: Yeah, we could do that
Bob: Good idea

In this case, Amy acknowledges both the team members positions, then attacks the problem, not the person. This allows all three parties to work together as a team to solve the problem.

Handling deep conflict

In some cases, the conflict has already been going on for a while. Both sides have already developed deep mistrust for each other and have their positions firmly entrenched. Solving such a conflict is much harder. The same principles apply as above, but because of the mistrust between parties, they do not want to talk to each other. More effort is expended towards preserving their position than towards resolving the conflict. In such cases, the you will probably need to work with the parties individually, as they will probably not see eye to eye together. The key goal is to change the mindset from defending a position to working towards a resolution. Once that happens, the above principles can be used again.

Most deep conflicts are rooted in certain past events. By understanding the history, it is possible to understand the viewpoints of the two sides and bring them to a resolution.

Example of deep conflict

Developer: The management is out to squeeze every ounce of work out of us. They make us work overtime for no particular reason. I refuse to work this weekend.

Manager: The developers are so unreliable. They keep giving excuses about why something cannot be done. We need to monitor them closely and keep pushing them or nothing would get done.

Another example

Widget team: The application team gets all the support. All the good programmers are there. We never get any support from them. It's better not to work with them if possible.

Application team: The widget teams keep asking us for support. How are we to support them and still get our work done? We need to minimize interaction with those teams.

Conclusion

The next time you face a conflict, keep in mind these three guidelines

• Acknowledge the conflict
• Separate the problem from the person
• Attack the problem together

This post is a part of the selected archive.

What skills do I need to be a good scrummaster?

Based on my experiences, my list would go like this -

Have empathy. This is the most important. Learn continuously. This is the second most important. Apart from these, you need

• Understanding of the organization and its culture
• Understanding of the team and its dynamics
• Understanding of the people on the team
• Facilitation skills
• Conflict resolution skills
• Ability to work with people
• Ability to coordinate with teams
• Ability to work with management
• Ability to solve problems and get things done

What does you list look like?

Skill based promotions

I wrote mentioned a skill based promotion system in my essay yesterday. I've fleshed it out a bit more. Here is my current thinking on this topic.

When deciding whether to promote somebody, ignore past performance. This sounds like a radical idea, but it's not.

A promotion usually signifies some change in role. The best person for a project management role is not always the best programmer in the team. Past performance shows that they have the skills to do well in their current role. What is important is that the person has the skills required to perform well in the new role.

Instead, consider a skill based promotion. Establish the skills required for different roles in the organisation. Promote people when they acquire those skills.

Such a system is also transparent: Everyone knows where they stand and what they need to do to achieve a promotion.

Here is a plan on how to implement skill based promotions -

• Write down a list of skills required for each role - apart from promotions, these lists of skills will also help in hiring
• Provide resources to enable employees to acquire those skills
• Promote them when they have acquired the relevant skills

How can we come up with a list of skills? Here is one example -

---

Developer
Key Skills Required -

• Thorough knowledge of the programming language
• Refactoring
• Knowledge of a unit testing framework
• Project architecture and design skills
• Estimation methods
• Design patterns
• Understanding of algorithms
• Code reading skills

Project Manager
Key Skills Required -

• Identifying and managing project risks
• Estimation methods, formal and informal
• People and communication skills
• Knowledge of at least one traditional process and one agile process
• General management skills
• Good technical knowledge to understand problems faced by the team (Although this is not strictly required, programmers do respect their managers a lot more if they are technically oriented)
• Some amount of domain knowledge
• Basic understanding of the target end user - this is needed because the project manager is the user advocate in the team
• Understanding of the technical environment - source control, testing methods used etc

---

Once the lists of skills have been written down for various roles, the next step is to help your employees acquire it. There are three ways to do this -

• Allowing them to attend seimnars, workshops and conferences
• Filling up the company library with relevant books and magazines
• Enabling them to form ad-hoc learning groups

For my views on these three points, see my previous posts on creating ad-hoc groups and modes of learning.

One problem with this method is that there are only about 2-3 different roles available in project development, and thus reduced scope for promotions. It will also take a long time to acquire all the required skills from scratch.

The solution is to create intermediate positions when a part of the skills have been acquired. For example the above list says that a developer needs 8 key skills. There could be an intermediate promotion when 3 skills have been acquired, and another one when 6 skills have been acquired. Here is an example of such a ladder:

• Developer [0/8 skills]
• Senior Developer [3/8 skills]
• Technical Designer [6/8 skills]
• Senior Technical Designer [8/8 skills]

And for Project Manager:

• Project Lead [5/9 skills]
• Project Manager [9/9 skills]
• Program Manager [9/9 skills + sucessful completion of at least two projects]

The above are just examples, and should be tweaked as required.

In my opinion, such a skill based promotion system is superior to a performance based promotion system.

This post is a part of the selected archive.

Merit Based Pay

Conventional wisdom tells us to take the top performers and reward them highly. The theory goes that if they aren't recognised and rewarded, they will soon leave to better opportunities elsewhere. Even if they don't leave, they will soon be demotivated and put in an effort comparable to the weaker performers. After all, the reward is going to be the same!

Conventional wisdom is wrong.

Do not reward the better programmers any more than the weaker programmers.

By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.

The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:

Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:

• Annual salary or merit reviews
• Management by objectives (MBO)
• Praise of certain workers for extraordinary accomplishment
• Awards, prizes, bonuses tied to performance
• Performance measurement in almost any form

If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.

Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.

In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.

One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?

Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.

The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.

Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.

Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.

Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.

No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.

This post is a part of the selected archive.

s0ylentgreen: Management recruitment joke

s0ylentgreen: Management recruitment joke. Super funny.

Carly's Gone. HP Celebrates.

[via Joanna Rothman] A stinging article on Carly's time at HP: Carly's Gone. HP Celebrates. It's kind of sad really. A once great company, now struggling for its very survival. Quoting from the article:

In the midst of the revelry, excited employees openly talked of their frustrations with Fiorina's management style, which seemed to place Wall Street expectations ahead of nose-to-the-grindstone innovation, the very bedrock upon which HP was built. This is, after all, the company that is credited with developing the first personal computer in 1968, a string of scientific calculators, and the desktop ink jet and laser printers.

Fiorina's obsession with Wall Street pushed much innovation to the side, and eventually led to a rather unsettling change in the HP work environment: the company's very first layoffs. When it was all said and done, 15,000 of the then 85,000 workers found themselves without a job by the end of 2003.

Update: Red Herring wrote an open letter to Carly Fiorina in January 2002. Here it is.