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.

Selected archives available

Its almost three years since I started this blog. Thats a long time. I was going through my archives when I realised that its impossible for anyone to find the good posts amidst all the other posts. So I sat down and collected some of my favourite posts into a selected archive page. Check it out.

Flexibility vs Efficiency

This post by Dmitri kicked off a mini-debate about agility and rigidity. The debate is about whether a developer should be interrupted for a day to perfrom some side job. Check out the posts linked above for the whole story.

This is a common enough issue that it requires further examination.

At the root of the issue is what I call the flexibility-efficiency dilemma. This tradeoff is, in fact, at the root of many issues of agile vs traditional processes. The essence is that if you want more flexibility, you trade in less efficiency and vice versa.

Example

You have ten packages that you want to send by post. Each package involves buying the cartons, collecting the items, packing the items, writing out the address, filling up forms, and finally going to the post office and delivering them. There are two ways to approach this problem.

Approach 1

1. Buy ten cartons
2. Collect all the items
3. Pack the ten packages
4. Write out ten addresses
5. Fill up the ten forms
6. Go to the post office and drop off all ten packages

Approach 2

1. Buy one carton
2. Collect items for one carton
3. Pack the carton
4. Write out the address
5. Fill up the form
6. Drop off carton at post office
7. Buy another carton, and repeat the whole process ten times

Which approach is better? Most people would say the first one. Hmm. First, we need to define what we mean by better. Let's rephrase that question. Which one is more efficient? I think we can all agree on the first one. Its a no brainer. Just the ten trips to the post office makes the second approach way more inefficient. Let us say that it took ten days to send the ten packages via Approach 1 and fifteen days via Approach 2.

Now, which one is more flexible? Ah. This time its the second one. Why? Because it is much better suited to handle unexpected surprises.

I'm going to add in a surprise now. Surprise: After five days, you are informed that you need to go overseas for an office trip right now. Packages sent using Approach 1: Zero. Packages sent using Approach 2: Three.

Lets try another surprise. Surprise: It seems that customs is not letting such large packages go through. You need to repack into smaller cartons. Approach 1 impact: All your ten packages come back in two days. You repack everything for another ten days. It takes twenty days to get everything through. Approach 2 impact: After two days, your first package returns. You repack and resend it. The unpacked items are packed into smaller cartons the first time around. It takes seventeen days to get everything through.

Apart from the above approaches, are intermediate approaches. You could make five trips to the post office, sending two packages each time. The net result of efficiency and flexibility will be somewhere between the two extremes.

Software processes

Surprisingly (if you think about it, not such a surprise), the two approaches have a direct correlation with software processes. Just a couple of quick definitions. In the next paragraph, when I say 'agile', I mean an Agile (captial A) process. When I say 'agility', I mean ability to handle unexpected requests. So high agility mean high capacity to take on unexpected process, not adherence to an agile process.

At one end is traditional waterfall, exemplified by an up-front plan and minimum adaptation to changing conditions. It can have high efficiency—provided the requirements never change and the software is understood perfectly.

At the other end is the ad-hoc process (bet you thought it would be agile at this end!). With ad-hoc process, everytime someone asks, you can just drop what you are doing and handle it. There is no process constraining you. However, efficiency is extremely low. You are multitasking so often that you never get anything done.

Somewhere in between, but more towards high agility, are agile processes. This is something like the five trip,two package per trip, example above. The idea is that you fix an iteration length. During the iteration, programmers are left alone to work. At the start of every iteration is a 'change point.' This is a point where stakeholders can come in and change the course of an iteration. By choosing shorter iterations, you create more 'change points' for more flexibility. Or you can choose a longer iteration for more efficiency. I'll write more about choosing iteration length in a future post.

FINALLY: The answer

With that under our belt, we can finally decide what to do about the problem. The situation is that one of your developers needs to be taken off for a day to implement a small feature for a sale. Should you do it? Scrum says no disturbance in the middle of the sprint. Joel says that doesn't sound agile to him.

What to do?

The simple answer: Ask the managers to decide if the sale is important enough to delay the other project and take a developer off if it is.

The complex answer: Your average manager is not Joel Spolsky. Most managers are under the mistaken impression that there will be no impact on the original project (hey, its only one developer for a day right?). Not all requests are really all that important. Be clear about the cost to the original project, because this is often hidden to them. Then go ahead and accept the request, but be _very_ careful that the process does not degenerate into a ad-hoc-handle-every-change-every-day process.

This post is a part of the selected archive.

Leaving today

I'll be leaving Singapore today at 2035 SGT, arriving in Chennai at 2200 IST. Only an hour to go before I leave for the airport.

Returning to Chennai

Last Friday was my last day of work here in Singapore. I will be returning to India sometime this week. I've been in Singapore for four and a half awesome years. So why am I returning? I just get this feeling in me that a lot of cool stuff is going to happen in India. So far, India has only been seen as a cheap destination for outsourcing, but that is starting to change. There are a lot of startups, interesting conferences and user groups that are being formed. I could feel the change in the environment when I was in Bangalore a year ago. Very different from when I was there four years ago.

Yesterday, I found that the second Barcamp Bangalore is going to be held on December 2-3. This is exactly what I mean. In the last year there have been Barcamps in virtually all the major cities. Add in stuff like the Agile India conferences, Proto.in, TieCon India.. the list goes on. Can you imagine that the Bangalore Python yahoo group has 230 members? A few years ago, I would have stuggled to find ten people interested in a language that is outside of what is used at work. Very cool. Its for stuff like this that I'm coming back.

Spree River

Spree River
Originally uploaded by Siddhi.

Berlin: Friederichstraße S-Bahn (Metro) Station over the Spree river

Do we need an Apgar score for software?

Daniel Read has a very thought provoking post on whether software needs an Apgar score.

First, I encourage you to read both the original New Yorker article and Daniel's post.

What is the Apgar score? If you don't know, you didn't read the article, so go back and read it. Okay, okay :) The Apgar score is a method used to determine the health of a baby at childbirth. The baby is scored between 0–2 on five factors: heart rate, breathing, muscle tone, skin irritability and skin colour, giving a total score between 0–10. The score is measured once at 1 minute after birth and again at 5 minutes after birth. A score of 7 or more is a healthy baby. Less than seven does not necessarily indicate an unhealthy baby, but doctors will look at the baby to be sure. Before the score was devised, determining the baby's state was a complex mass of subjective measures which often meant that the baby was not given treatment when required because some factor was overlooked.

The key idea behind the Apgar score is that it is simple. It is simple to calculate. It is simple in that it condenses a number of subjective factors into one number. It is simple in that an instant decision can be made as to whether the baby is healthy. The final Apgar score does not take into account the myriad complexities, but it is intentionally kept simple so that it can be used as a quick, shorthand method of assessing the baby's health. That's what it is—a quick, shorthand assesment.

Daniel asks a question—Do we need an Apgar score for software development? Something that can serve as a quick, shorthand assesment of the project's health. Current methods of determining a project's health are a complex mass of subjectivity. Maintainability? Security? Relaiability? Code coverage? Usability? Requirement satisfaction? Customer satisfaction? There is no effective means of quickly measuring the project quality in a way that would give a rough idea as to the quality of the software. An Apgar score could help a lot here. It need not be exact. It just needs to be somewhere in the ballpark so that a decision can be made as to whether the project is healthy or we need to investigate more.

I think this is an interesting idea. It may not be practical as yet for software, but is nevertheless thought provoking. Check out some of the comments on Daniel's post as well.

This post is a part of the selected archive.