Evaluating Software Teams

There has been a very interesting discussion on one of the LinkedIn groups I belong to on evaluations of team members for Software Teams and how to go about it. If you manage a Development team you'll know the answer isn't as simple as comparing producing features against the number of bugs, it's far more complicated than that.

Often there is little in software development to quantify and you are working with as many different people as you have team members. They all have differing levels of skills and different personalities. Even the area of applications they work in will make comparing production to other team members almost impossible. 

Developers can knock over 20 bugs and add 3 new functions in a one day but spend the next week trying to resolve a single bug. Performance against sheer production is just not an option. 

Managers need to look at other options. 

To properly evaluate, managers must be able to repeat the same evaluation 6 months later and compare the two to see if the individual is performing better than he/she was in the first evaluation, so the evaluation must be against something that is quantifiable, repeatable, comparable, and understandable. 

Luckily there are things that you can use other than functions vs bugs. You can evaluate items like:

• Standard of dress (programmers turn up in tee shirts - but are they clean and non offensive). 
• Attendance to work during required times and hours. This will include calling in if late for any reason. 
• Attendance to meetings 
• Quality of documentation and testing 
• Time to respond to a request 
• Ability to get along with the others in a pleasant and non-disruptive way 
• Ability and willingness to help out others with mentoring. Includes things like contributing at meetings. Must be weighed up with doing their own work. 
• Following the correct process 
• If customer interaction is involved, how many complaints and compliments. 
• Desk tidiness (mine is terrible so I have to make a real effort to tidy it every couple of days). 
• Willingness to take on new work. 
• General attitude 
• Attitude to change 
• Clarity and effectiveness of documentation

Try marking these out of 5 (5 being the best). Try to keep them all around 3 so that areas of discussion and commendation are easily highlighted.

After this the manager can make general comments on their assessment of the team member's skills. This part however is very subjective so must be introduced as comments only discussed behind closed doors and something for them to consider, but its not anything that can be quantified so it can't go into, say, consideration for a bonus. 

Try not to compare team members against others - this is THEIR evaluation. It's also not wise to evaluate the team itself - the team is where YOU will be evaluated, not the individuals. 

Your comments?

Employment Scene over the last two years

It's been hard to miss, the financial crisis of the last few years. 

There have been some real horror stories coming from the United States on the employment scene with many people losing everything, starting with their jobs. In one case I know, a person with a well run retirement fund that had grown to around 14 million, was reduced to a few hundred thousand in a matter of a few days. Things are a little better now but the fabulous retirement that was planned will now never be.

Australia fared reasonably well on the world stage but still suffered some serious concerns for both full time employees and consultants. The downturn meant that few were hiring. I spoke to an employment agent in Sydney during that first 18 months. His business was not doing very well and he told me that although you could walk the streets in Sydney and see crowds of people in business suits going about their work, it was his estimation that at least a quarter of those you saw on the street were looking for work. I considered myself very lucky to have found work during that time.

New Zealand did not fair as well. When I returned to Wellington at the end of the first quarter last year, I took up a contract with a Government department here. Paradoxically, this contract itself would not have been available except that there was a freeze on employment and they took in a contractor instead. One of the few management positions available for contract. During that time we were able to employ a number of others into short term contracts for necessary projects. 

In the interviews, it was immediately obvious that every person, some very highly qualified and experienced, had a large gap in their employment. The financial downturn turned a lot of very good people out on the street. The look behind their eyes when we discussed this with them showed the horror of the times on their personal and family lives.

Things are just starting to get a little better but there is still a long way to go before we get anywhere near the heady days of only 5-6 years ago.

Returned

I've been very remiss in updating this blog over the past couple of years and I'd like to kick start it again. I get a lot of enjoyment and learning from writing this blog and I've had a lot of feedback to say that others also get that same enjoyment.

There has been a lot of things happening over the last two years.

I've found it very sad that I was placed into a position where I had no choice but to return to New Zealand from where I was living in Australia. I loved Australia and the people there. New Zealand has wonderful people too but I had built up a number of friends in both Melbourne and Sydney and a even few in Perth (although I never actually got to Perth).

My main areas around application development teams has been a joy to me in my contracts, and although my secondary area of Marketing has also been of use, it's the team and the process that has always been of greatest interest.

This last few years has seen me in different contracts as a Marketing Manager; a Software Development Manager for a government department; and a Software Consultant for a team with a great product now in Wellington New Zealand.

Over this time I've been very involved in a number of projects and technologies so there is plenty of interesting bits that I can delve into. I'm back on the Blog scene again and will update this again shortly.

While I was away I had so many spam posts that I had to switched off the ability to comment on my posts. I feel sad that I have to apologise for the stupidity of a lot of people - mostly Indian programming companies touting for work by adding posts that said things like "I agree" and signing off with their company link. Those posts will be removed and the company reported to the blog hosting company so they will be blocked.

I'll begin posting again shortly.

Leadership of the Technical Team #3

Number 3 in the series on Technical Leadership.

Makes Decisions for the Team

I was surprised to find that this section was more difficult to write for several reasons. the title “makes decisions for the team” is something that I could have well reconsidered as it seems both obvious and at the same time very snobbish and places the leader in a position that should not be taken – at the top.

Most people automatically place the leader at the top of the team in a visual organisational chart. While the organisational chart does indeed show this position at the top, it is not the visual reference that I want to portray. I’d suggest that the leader is the one underneath; leading from behind or holding the team up; in a supporting role; carrying all the responsibilities of the team; a servant to the team; and the person protecting the team from the politics and pressures that attempt to divert the team from its path of productivity and enjoyment.

One of the ways a leader can serve and support his/her team, is in making decisions for the team as a whole.

In the position of leader and manager, you are expected to move the focus from the code being produced to the product. You are also expected to know and understand the perspective of several other areas including those of the boss, the company, the customer, the financial budget, and those of other departments within the company.

It has been said that there are two different types of leaders - we’ll ignore the fact that there are several, just for this instance, let’s assume there are two. Take, for example two good managers of forestry teams tasked with clearing a section of forest and harvesting its timber.

Leader One will take his team into the forest, start them cutting trees in the most effective pattern that his experience shows for its productivity; he’ll have the trucks lined up to take away the timber in the correct times in the correct order; have the forklifts correctly placed to load the trucks; and have everything running like clockwork so that he/she clears the most timber of any forestry team. That is an excellent team and a good leader.

However, Leader Two will go into that same section of forest but before work begins, this leader will climb a tree, have a look around and come down to declare to his team that they are in the wrong forest and they should be over the other side of the hill.

Leader One was acting in the best interest of the project looking at the tasks required and delivering to the tasks. Leader Two however realised that his position was to serve the team by having the ability to view the larger picture, ensuring that the team not only delivered to the project, but delivered to the RIGHT project in the CORRECT direction to also serve the company.

This ability to raise your head above the tasks at hand to see the overall picture is usually very difficult for those whose lives to this point revolved around climbing inside the disk drive door, only coming out to eat or sleep.

The leader is in a position to make everyday decisions for the team. With the knowledge and understanding of the forces that effect the team, the leader can guide the team into exceptional productivity and communicate that to those others in the company who need to know. Communication is a strong point and I direct you to a previous post titled “Even Programmers need to Communicate”.

Don’t be scared to make decisions. You will never have all the information, so make decisions on the information that you do have. Some of the most ineffective managers I have come across will be those who will not make decisions but continually wait for more information.

Remember, you can always change or deal with a bad decision but you can do nothing when no decision is made. Yes, be prepared and able to hold your head up high while you do a total 180 on a decision as more information becomes apparent.

I have never understood the old saying of "make a decision and stick to it". That is unwise advice and will have you standing in the wheelhouse of a sinking ship with total resolve as you draw your last breath in the knowledge that you stuck to your decision to ram the iceberg even after it became apparent that it was larger than your ship.

A good leader will not only make decisions, he will also allow the team to make decisions where appropriate. Grow your team by allowing them to make decisions where they are able. Ensure that they have as much information as possible to allow that decision without attempting to tell the team which decision they should make (although there are times when that might be required). However, be also prepared to stand behind the decision that is made and make it clear to the team if it becomes apparent that they should make a change to that decision.

Rely on your gut feelings, they will NEVER fail you. Just make sure it is your gut you are feeling and not your heart - that can fail you.

Technical Leadership #2

(continuing on from “Leading the Highly technical Team”)

The thing about leadership is that its such a large subject and there are any number of books and other writings on the subject. The point that I'd like to make, stated in my last instalment, is that leading technical teams has some very different aspects to leading other teams.

However some things don't change. There are lot of young people who have been placed onto a leadership role and have had no training or mentoring and in these days of tight training budgets, and no place to get it. Often these people are given those roles due to nothing more than their technical knowledge. It is my hope that this series will give those people some basis for their new career.

Firstly, for those who are starting in on this path I will congratulate you. You have shown that you do have the ability to lead, even if you don't yet realize it. To get to this point you have not only shown leadership in the past but you probably also have the support and recognition of your peers. All you need is some training.

Let's cover the bases first, in no particular order a good team leader…

1. has empathy with both the team and the individuals in the team.
2. makes decisions for the team
3. is able to listen effectively and impassively
4. stands between the team and others who might work against the team
5. gains the respect of the team
6. ensures the productivity of the team
7. ensures the ongoing enjoyment and cohesion of the team
8. ensures the team produces in the overall direction of the company
9. ensures the team works effectively with others
10. makes the very hard decisions that are sometimes needed for the good of the team

Empathy

Empathy itself is a large subject and absolutely essential for leadership. Without it you are nothing more than a manager and possibly a tyrant.

Empathy means to have an understanding of another person's viewpoint. Not just knowledge of, but “understanding”, there's a big difference. Some have described empathy as "Agape".  Agape is a Greek word with several meanings relating to a type of love. In this case the meaning I’m using is of a brotherly type of kinship, understanding, placing yourself in another’s shoes, a non-physical, non-sexual type of love. Not the English word or meaning of love but something that still means a positive emotional, yet professionally appropriate, feeling towards another.

Don't confuse this with agreement, its not necessary to agree with someone to have a true understanding of their viewpoint. This empathic feeling goes towards the team as a whole as well.

Often during this series I'll be talking about the individual and the team as if they are entirely separate and this is definitely the case. The team is like another identity that takes on it's own role and personality. I have even seen teams hell-bent on doing something that none of the team members want, usually a very bad situation, however it goes to show that the team itself does take on a personality of it's own. It's up to the leader to ensure the team's personality is in harmony with those in the team, and with the positive purpose of the team.

It is then with this empathy that the leader can understand the person's position and feels a genuine compassion for the circumstances, but in their position of management he/she also must take into consideration all the other factors surrounding a decision and acts accordingly. Being empathic, the leader will let the person know that he/she understands their position and communicates both his/her understanding, and the final decision equally.

I can almost hear some readers say that this talk of empathy will show a leader to be weak. Not at all, in fact I might suggest that if you are at all worried about appearing weak to your team, then perhaps you may have to reconsider how you interact with them. Are you leading them from the front, or are you chasing them from behind?

Weakness suggests that you can’t make those all important decisions and are easily led. We’ll get to those hard decisions in a later part of this series, but I’d suggest that you don’t even go there for the moment. You don’t want to appear ready and able to be the hire/fire kind of boss that looks around only to find no-one there.

Empathy has nothing to do with either strength or weakness. It has to do with understanding your team.

For the technical team this takes on another dimension. It is rare indeed that the leader has all of the skills of the team. I’ve heard even recently a manager claim that he would never ask one of his team to do something that he would not be able to do. This is a fallacy, in a technical team all the team members are there because they have specialist knowledge that is sometimes very unique. Its not possible for a leader to do everything the team members are able to do unless the members are reduced to a single skill level. Not a very effective team in most cases.

I couldn’t do half the things my wife does and she could not attempt to do a lot of what I do, yet we make a very effective team. As leader I have led teams who program in several languages on several platforms and have qualified skills that I could not master without the years of training and experience that they have. This I consider ideal as every member of every team is different. I have great admiration for the skills of the team members and this in turn prompts me to do the very best for the team; to be there for them when they need it; to listen; to stand for them against others; and to serve in the best way I can to allow them to use those unique skills. That is empathy.

Rather than weakness, this empathy is what allows a leader to make what are sometimes very hard decisions for the good of both the team and its individual members.

continued next session…