I had a conversation for a potential engagement, and was asked "What leadership do you have to offer to someone with 10 years experience?" This is a very good question. As a senior developer with over 30 years of experience I need to be able to articulate the value I bring to an engagement, and many business or even technical people may believe that with 10 years of experience developers know what they need to know.

I do not expect to need to tightly direct a group of developers with 10 years of experience each. They should be quite capable of working independently. There are two areas where I have seen consistent value contributed, above technical abilities, that may not be as present in any given team, and where I contribute value: culture and judgement.

Culture

In any development group there is a culture. Some group or company cultures follow traditional cult approaches: 1) we vs. they, 2) leaving is failure, 3) we know better. While these create a sense of closeness, they have many drawbacks.

The cult like cultures result in a stagnant culture which, once established, never changes. While such practices can lead to team cohesion at the beginning of a project, in the long run it has several negative effects:

1. it tends to exclude new members, by its nature those that do not conform or agree with the cult prior to joining are rejected,
2. it tends to reject new inputs due to the input being foreign to the existing culture,
3. it does not recognize mistakes, or values contrary to the doctrine of the cult.

A recent example of this in the Ruby community is the prevalence of developers to look down on other developers that use a different editor than they have found productive. In particular the VIM sub-culture is very vocal, and often indicated by a quick query in an interview about which editor does an applicant use. There is nothing wrong with enthusiasm for a tool that is useful, but when it becomes a gating condition on evaluating a candidate's value, a cult mentality has set in.

What senior developers like myself contribute in this area is having worked in many different groups. We have seen enough different developer cultures to have an idea about what culture is forming in a group. The better senior developers contribute to the building of a culture which supports an openness to ideas, to being adaptable, and to embracing change.

Agile/XP type processes strive to build software that is resilient and open to change, the group process and culture needs the same focus. Just as software needs to be refactored to incorporate new inputs and requirements, the team dynamics and culture needs to be reexamined periodically and updated to meet the new and changing organizational requirements and to incorporate new experience and industry inputs.

Judgement

While I would hold it true that technical judgement improves with experience, I would assert this is more true if that experience is varied and shows diverse domains. Twenty years in the same industry or the same job clearly is not as valuable as twenty years in different industries, and in different roles. A developer that knows many languages is well accepted to be more valuable than a developer that has only worked in one language, because their thinking is more varied and their approach to any problem can be richer. The same is true of developers that have worked on many types of projects in many types of organizations, and in many different roles. They bring a richer set of experiences.

In addition to technical judgement, there is a critical aspect to judgement that in my experience forms fairly late in many developer's careers. This is the weighing of business value vs. technical value. This must include consideration for the actual individuals doing the work, and the time required to deliver the business value. This is a complex decision making process.

1. Technical: risk, effort required, and team skills.
2. Business: value, revenue, expense, and impact on customers.
3. Opportunity cost: what could the same effort produce in other areas of the project?

Recent processes attempt to deal with these factors in prescriptive ways. They establish rules to deal with these issues. This has drawbacks as covered in the culture section, when applied too dogmatically. These rules are most definitely the attempt by senior developers to codify their judgement, but such codification is never as accurate as a person, or persons, with good judgement.

It is good to have language around this area such as "technical debt", or "refactoring", or to include customers in the decision making process. Having language for a practice increases the cultural awareness of the practice. Ultimately a person with good judgement and a good understanding of both technical and business aspects is the best option.