BrainsLink

Linking the left brain and the right brain

Focus on Team Collaboration Not Individual Skills

I’ve had scenarios similar to the following one come up several times over the years. You have someone on your software development team that writes great Java code — and does it fast — but can’t or won’t do much else. Should you remove him from the team? Before you answer that, let’s dissect the situation further.

Ideally, members of an agile development team should have both technical and non-technical skills. You see it in job postings all the time. Assuming the team is building a system using Java as the primary language, knowledge of Java, the JRE, and various Java development tools and libraries are needed skills.

The non-technical skills are more complex. They fall into buckets such as communication skills, team player, customer oriented, quick learner, results-driven, etc. (I don’t know why they leave off “walking on water”.)

Let’s face it, very few of us can do everything well. What do you do with someone who writes great code but falls far short in the non-technical (subjective) areas? I’m sure many managers would say ‘send him to training’. After all, we’re all supposed to work on our weaknesses, right?

Two major obstacles come to mind.

  1. The developer may have no interest in mastering the non-technical parts of the job. Sending him to training might result in small improvements but major gains are unlikely. In fact, the situation could deteriorate if the employee rebels against the forced subjective behaviors.
  2. The developer may have an interest in bettering himself but you have to expect that his coding prowess will suffer. How can he continue to write great code at a fast pace while also spending more time on other aspects of the job? It doesn’t add up.

Think carefully before creating a mold and trying to get everyone on the team to fit into it. You might be better off leveraging people’s strengths and offering assistance to cover their weaknesses. As long as the team possesses all the skills needed to deliver the results required by the company, they can be successful. Expecting every member of the team to possess every skill may sound good but it’s unrealistic.

Focus on collaboration instead.

Get team members to help each other and reinforce their abilities. Agile teams are not collections of people who work independently. They need to work together.

As for that Java developer I mentioned above, do everything you can to help him write great code. Have someone else on the team pick up the non-technical aspects of his workload. He’ll be happier and more productive. The team and the business will be grateful.

Updated: April 12, 2012 — 9:37 pm

4 Comments

  1. Collaboration ofcourse yes is the way to go. How much of success did you have with that approach. I would not say i had no success at all but for some reason is not as much as i expected.

    Developers seem to loose focus given an over egged collaboration :). I guess its case of finding that balance.

    1. You’re right. Having a balance is the key. If you have a team full of developers that only want to crank code, you’ll run into trouble. There needs to be a balance of skills, needs, wants etc. such that all of the work gets done. This may require replacing one or more team members with others that can provide that balance.

  2. Collaboration and communication is what makes a team a real team. Often it’s better to develop these skills in the team, using for instance retrospectives to see what goes good and what could be improved, and improve the way of working in the next iteration.

    I’ve seen teams where people with with very strong technical skills openend up and started to work more closely together with the other team members. Sometimes initially with some pair programming (or peer review), later with coaching and helping team members to develop new skills. It also proved to be beneficial for the technical expert, since they didn’t have to do everything themselves anymore, but had people in the team that could help getting the work done.

Comments are closed.

© Damicon 2014 Frontier Theme