What was your experience with a Lead Programmer Team Structure?

Question

In the 60s and 70s, Harlan Mills of IBM promoted the idea of Lead Programmer teams, which he compared to a surgical team -- a highly trained and talented individual as the person who was actually "hands on the patient" and who was, in turn, supported by others who provided him or her with tools and routine procedures. He contrasted this structure with the more common non-hierarchical structure in which everyone was assumed to be more-or-less equal in talent and duties (his loaded metaphor for the latter structure was a "hog-butchering team").

The Lead Programmer structure seems to rest on the belief that there is a great disparity in the potential contribution of team members and that the benefits of restricting the influence of relatively inexperienced or untried developers outweighed the potential benefits of what we'd now call collective code ownership.

Lead Programmer teams were studied, a little, and didn't seem to show clear benefit. They fell out of favor and today "Lead Programmer" generally just indicates seniority, not structural responsibilities. Today, with a culture more attuned to the Agile Manifesto, the very idea of a structural hierarchy within the development team is probably distasteful to many. On the other hand, the development industry is far more heterogeneous than it was in the early 1970s and I think that there may well be a greater gap in potential contribution between team members, especially when working with distributed teams or teams involving both part-time and full-time workers.

Have you worked on a team with a Lead Programmer-style hierarchy? If so, was it effective?

While this question obviously relates to general questions of how talent is distributed and whether meritocracies are good or bad, I'm hoping to hear experiences, whether good or bad, with those who've actually tried the Lead Programmer structure.

Answer 1

I've had a couple jobs where we had a Technical Lead, which is kind of like what you're describing. This is great idea in theory, but in practice it's very easy for people in that position to assert (or be assigned) lots of managerial tasks like project planning and other administrative junk.

In short, for this to work, I think it has to be explicitly delineated that the Technical Lead is not "the boss" per se.

Answer 2

I've worked on both. Generally I have had bad expriences with it. This is mainly because the absolute smartest person is not the one in charge. Promotions to a higher level have a degree of politics in them and not just talent. With this type of management style it assumes the top person is the smartest. This leads to two scenarios:

1. All the smart people quit, becuase they conflict wit the lead person
2. The lead person only higher less expienced people than him/herself.

I quit my last job because of this, and so did the rest of the talented people.

I did see this work once, and it did because the person in charge really was better software development than all of us. He was just generally right. That being said we had some leeway and we could convince him other wise on occasion, but in truth generally he showed us a better way of doing things when he disgreed with us. This is definately not the rule though.

The best type of management style I've seen is where the manager realizes that the people reporting to him/her have talent and they have the ability to make the right decisions (generally) even if its different.

Answer 3

In my job there is no Agile manifesto. It is only the lead programmer structure. It really only works if there are only 2 people actually coding. The one with more experience (Lead Programmer) and the one with less experience. No matter what even the one will less experience will teach the Lead programmer something new in any project.

However on the logistics side of the equation when you add more people to the performance is shot completely or the project can go dark. No more than 2 people coding is the golden rule for non-agile Lead Programming.

Answer 4

From my experience, that's actually a wrong question. The organizational structure that will work depends on a mixture of individuals in a team. Lead programmer might work in one team, and completely fail in other, but success and failure is highly dependant on how that fits with the team. Lead programmer is just an organizational pattern, which should be used as needed, not as a rule, and the question should be not if it fits in the organization, but if it fits to the people involved.

In other words, having a lead programmer is fine only in a situation where you have smart person interested only in technology, and not in management (although he will typically have to manage people to some extent), and a team interested in learning from him.

That said, the healthy role for lead programmer is not to "offload boring tasks" to his team, but to educate his team until they get to the point of being too smart to be used for boring tasks. And in programming, somebody's boring task is always a challenge to somebody else. If somebody has reached his limit and isn't learning anymore, he'll still become bored after doing the same thing for a long time, and good manager will move him to the position that is a challenge to him, be it something harder or something completely different.

Answer 5

Talent is not evenly distributed, nor is expertise, nor experience. A lead engineer encapsulates this level of expertise and makes use of the other talents around him or her to get the job done.

I have worked mostly in environments like this. I find it can work very well. In fact, in my experience, I find there is always a lead--sometimes explicitly, but more often implicitly. There are simply harder areas, design tradeoffs, knotty performance and bug issues, which the lead is going to be able to get through far more effectively than the non-leads.

A lead also provides a steady hand for the technical direction of the project.

That is not to say there are not pitfalls:

• Arrogance can be a problem. The lead must not treat his or her team members like dirt.
• Failure to share can be a problem. The lead can easily hoard responsibility. This leads to a stressed lead, as well as other team members who are not working to full potential, not learning, becoming resentful, etc.
• Overloading the lead with managerial tasks can be a problem. We managers need to make sure to leat the lead do what he or she is best at--leading, technically. To the extent we bug them more and more for schedule updates and powerpoint slides, we are doing the whole team a disservice.

The "producer/director" split of roles, first described in Brook's Mythical Man Month, describes the role of the lead and the manager very well. I completely ascribe to this view!

Answer 6

I've worked with it and without it. I've found it to be effective in cases where there has to be someone to catch things that would fall through the cracks or be responsible for delivering a solid piece of code. The Lead Programmer as I've seen it is usually project-specific where a particular developer is driving a given project to completion. Without this person, things can still work OK though there can be cases of finger-pointing and someone has to step in to resolve the issue, e.g. there is a bug and the front-end developer claims the issue is with the back-end and the back-end developer claims the issue is with the front-end and really either can make a simple change to fix things but who should have the change?

Answer 7

I'm in that Lead Programmer role right now, but admittedly not by choice. That's just the way the hierarchy worked itself out. The advantage is near-dictatorial control of the code, but the many obvious disadvantages far outweigh any benefit.