Star Programmers [Team] vs Overall team quality

Question

Hi,

I want to know if others have experienced the situation where people around you are very smart and have few star programmers but as a team you are still struggling to move. I am not talking about people with arrogance/pride or social handicap.

Does motivation to create shared vision of product play any part?

---

I understand the value of Star programmer and teams but what I am really looking for is when even in the presence of such teams, product team is not reflecting that! Have people experienced such situation?

Answer 1

Star programmers are fundamental to any team, it would be great if all programmers were stars.

Teams struggling to move are typically teams that don't have a vision of the product or don't believe that the product will succeed.

Or teams that are being badly managed.

Try to figure out what is on their minds besides getting the work done, be careful, you could be opening a can of worms here.

Answer 2

Star programmers are supposed to be the leaders. If none of your programmers are taking intiative and carrying on the project, none of them are star programmers (or good star programmers, if bad ones exist).

That, or, as MrTelly suggests, your star programmers are leading (or at least trying to lead) each other in opposite directions. Anyone who knows vector math knows that the sum of opposite-facing vectors is ... nothing!

Answer 3

I think you've answered your own question, you can have the best team in the world, with or without stars, but if you're not all going in the same/similar direction, sharing a vision as you put it, you're not going to make much progress. It's easy to be busy all the time, but in reality acheive little that an end user could actually install and use.

I've been in this situation a few times, and I'm wondering if your experience is similar. Are you seeing small parts of the code base supposedly complete, but not integrated with the whole? Is the discipline around builds (hopefully continuous) and testing patchy with some areas well tested and others not at all. Most importantly do you have regular code deliveries - there's no better way of getting a wayward team to focus, to force a delivery - however, minor the functionality may be. If you can't get some code compiled, tested, delivered within a short time frame, say 1 month, you know you've got real problems.

BTW I think leading and leadership is a sorely under appreciated skill the development community. Great leaders aren't necessarily star technical people, in fact being a star can be more of a hindrance as the leaders time is taken up with tech issues. The leader needs to concentrate on delivery, without delivery (and of course everything that leads to it) you have nothing.

Answer 4

The definition of a star programmer can be different. Is star programmer the most technical developer on the team? Is it the most dedicated developer? Is it the guy with the most accepted ideas (by management or by other members of the team or both)?

I've had experience where a team was extremely technical and motivated. Every member of the team was a senior developer when he starter and every member had very high growth potential (rightly so). However, as people expect to move in seniority and responsibility, some can feel left out. Until this is resolved by growing the team, moving members around, etc... the team is a lot less productive then it was at the beginging.

There is a saying - "its not enough to know your price, someone has to be willing to pay it." Same way, its not enough to have a star programmer, he has to be willing to lead, and others have to be willing to accept it.

Answer 5

Just a thought, "Struggling to move" might be in the eye of the beholder. Just because they aren't cranking out code yet, does not necessarily mean they are struggling to move. Depending on the type of project, there can be a significant amount of up front work that might make one think nothing is being accomplished (because nothing tangible has been produced) but in reality a lot of the smart work is being created that will greatly simplify things later. Is this a complicated or easy project?

However, assuming that they really are “Struggling to Move”. I have seen that when the smooth-talker developer is put in charge because the manager likes the way they talk, but the smooth-talker doesn’t really know what they are talking about. Yet, the manager doesn’t know enough to know that the smooth-talker is clueless. This is characterized by a lot of give me this rock, no I meant that rock type of activities.

I have also seen the problem when the lead is not really interested in managing, but is more interested in development. This results in the team going in all sorts of directions. They do a lot of work, much of it good, but somehow it doesn’t fit together as a whole. Thus, no real progress is made. Every team needs that nag, who can nag without ticking people off, that keeps the team moving forward in the right direction. The lead who wants to focus on development usually does not fill this role well.

It is hard to give any meaningful feedback because you did not give enough info to describe your particular situation. Do they have a detailed schedule? At the very least that will give you an indication that they know where they are supposed to be heading. If they aren’t meeting the schedule then it should point out who is not making the desired progress. If the schedule isn’t detailed enough to point out who, then the schedule isn’t detailed enough.

Maybe a little more info will help us come up with more suggestions.

Answer 6

There are usually two reasons for this:

1) The programmers have conflicting personalities leading to them sub-consciously playing the role of saboteurs in the team.

2) They have a product that they don't really believe in because it is trying to serve conflicting purposes.

Answer 7

As others have said, no visible progress in terms of lines of code, etc. does not necessarily mean that no progress is being made.

Having said that, yes, I've been in situations where there were plenty of good people, some stars, but things moved slowly or not at all. That can be a result of many factors: "corporate knowledge" (i.e. is there any one around who knows how things were done and why), proper background/training/aptitude/interest for the jobs people are assigned, support of and clear direction from management, autonomy, that shared vision thing, and other things.

As for team building, there's more to it that just having a star programmer or two. To wit, in sports, it's not uncommon for even bad teams to have a star player or two. It's often how the whole group interacts that determines how successful it is. So, do you have a team, or - as I think Casey Stengel said - "an interesting collection of individuals"? If you're not already familiar with it, I'd recommend reading DeMarco & Lister's Peopleware. It's a classic that deals with team building, amongst other things.

Answer 8

While the lack of a shared vision can cause some problems, it isn't the only issue that can act as a way to prevent the team from looking good. Here are another few:

1. Ping-pong requirements. If what is asked requires many hours of work and the team is running in circles, this can be a case where while it may look like nothing was done, because all the changes done for one iteration were undone in another, this can also de-motivate the team and cause problems.

2. Fuzzy requirements. If the end-user doesn't know what they want, it can be more than a little hard for the team to jump on things and git-r-done. What may work one time, may backfire completely another time. This is slightly different than the first one as this doesn't necessarily create a cycle. This may be very similar to the shared vision issue though this is from the business or client or customer that wants the software.

3. Things just don't go together smoothly. Sometimes what one thinks should just plug and play, don't even really plug well. These rough patches can take months to sort out and cause all kinds of headaches that may or may not be easy to resolve, even with clear requirements. Where I work we have had problems repeatedly with various things coming together and what should be smooth, just isn't that way at all. Ultimately things will be fine, but until that end there can be a lot of pain for a lot of people.