vsbabu.org

Improving efficiency in IT teams

May be it is because of the stellar economy during late 1990’s when IT workers were very valuable. But the fact is, most IT teams - programming, web development, quality assurance - does not work as teams. Most teams suffer from terrible inefficiency that bogs down productivity, make gossip mongers out of team members and make customers very annoyed. Soon, it doesn’t even resemble a team, but a collection of people whining constantly about something to mask inefficiency.

Here are my thoughts on how to improve efficiency in such teams, if you manage one. These don’t address the situation if you are given a bunch of people favorable to the upper management, but whose skill sets are inappropriate. In that case, getting your authority to hire motivated people with appropriate skills as early as possible is the only solution.

Set goals for the team and communicate those to the team very well.

Make the team understand that these goals are your responsibilities and the team is there to meet those responsibilities.

Get people walk the talk.

Very often, incompetence or laziness comes out as never ending arguments. This is very inefficient and can cause morale-slump among motivated team members.

• Ask team members to present deliverables and achievements.
• Nobody needs to listen to thinking pattern or current fantasy.
• Nobody gains much from formatting skills with MS-Word or Powerpoint - this is required often, but should not be the only thing all the time! You might be surprised how often this causes inefficiency. Usually this comes up when preparing business requirements, functional specs etc. When people are stumped on what to put in there, they tend to spend lot of time making it look nice.

Get people to work for your team, not as zones within the team.

A good work area is absolutely essential for this. If off-site people are there in the team, daily status meetings running for 15 minutes or less are good substitutes.

Write down general areas of focus for each team member.

Make every one in the team know that what others are focusing on. That way one person alone wouldn’t need to fix maintenance tickets and every one would know whom to turn to for help, if needed.

Eliminate comfort zones and personalized self-described technology skill area.

Learnability and flexibility are what you need in the IT field. You have a team member who keeps shouting that he or she should be given work only in Basic or Windows NT (or Perl or Linux), then depending upon how much attention is paid to that person will determine how much your team is going to suffer. If the situation is because differing skill sets within the team, the following might help.

• All work, always done in pairs - at least. Plan for tasks with this in mind, understanding that two people might’ve different skill levels and time must be set aside for informal training within the pairs.
• After every paired task, ask the pair to write up a short note on whatever new things they found out. Review these every 3 months, and arrange these into a good knowledge bank. A simple Wiki is the most efficient one. Beware, people might want to waste time producing nicely formatted documents.
• After every paired task, talk to each person about how the pair is working out. Solicit suggestions or "first thoughts" about how to make it better.
• Rotate the pairs often. Group comfort-zones are worse than personal comfort-zones. This way, people might get to know others better, which may turn out to be good or bad. The previous bullet point is to catch potential problems.
• Mingle pairs in such a way that there is always a possibility for each person to improve the skills. If X’s designated focus areas are 1 and 2, and Y’s are 4 and 5, in a task involving 1 and 4, pair X and Y. That way both learn.

Implement rigid handover policy.

Sloppy and imcompetent team members might make it an art to hand over incomplete tasks to others by saying "oh, it is 90% done, so you’ve to complete only 10%". A manager should not fall for this and make it known that the last 10% is also the responsibility of the person who did 90%.

Every competent team member must get opportunities for interacting with the customer.

A common mistake is to designate some one with sweet talking skills as the only conduit to the customer. If that person then emails a developer like "I talked to XYZ. He/She needs this done. Please do it and reply all of us so that I can follow it up with XYZ", it is very bad for the recipient’s morale. It could be a lot better if it is like "I talked to XYZ. This is what is asked for. If you think that can be done easily, please work with XYZ on this." And the recipient reply "Got it, will do" or "Got it, can’t do now due to ____. Needs to escalate this." That way, the people who actually do the stuff get little more recognition with the customer (it is really good for feeling nice). It also makes the doer responsible directly to the customer, improving the chance to feel the ownership of the work.

Archive what every one worked on and status.

That way we can look back at it every 3 months or so and see how many of these things produced tangible results. It will also help in advertising your team well.

Do not spend much time on things that cannot be measured and quantified.

• Numbers are boring, but they reduce ambiguity.
• Reduction in ambiguity improves focus.
• Improvement in focus improves productivity.
• Improvement in productivity improves measurable outputs.
• Measurable outputs are what your customers care for ultimately.

1. Information provided in your site is very good,informative and educative.It will be very nice if you could provide some more points on leadership,self motivation, team building etc.

   Posted by: Devanesan Ravichandran on January 11, 2004 04:37 AM