I work on a team that has been flat organizationally since it's creation several months ago. My manager is non-technical and this means that our whole team is responsible for decision-making.

My manager is beginning to realize that there are several benefits to having a lead developer, both for his sake (a single point of contact and single responsible party for tasks) and ours (dispute resolution, organized technical guidance, etc.).

Because the team has been flat, one concern is that picking one lead developer may discourage the others. A non-developer suggested to my manager that rotating the lead developer is a possible way to avoid this issue. One developer would be lead one month, another the next, and so on.

Is this a good idea? Why or why not?

Keep in mind that this means all developers — All developers are good, but not necessarily equally suited to leadership.

And if it is not, how do I recommend that we avoid this approach without seeming like it's merely for selfish reasons?


17 Answers 17


Don't rotate.

I don't think anyone gains anything from the position being rotated (apart from the ones that don't deserve to be the lead might get more money than they are currently receiving).

Having a brilliant lead developer who can do the following, does wonders for the development process:.

  1. Knows how to delegate.
  2. Is in control.
  3. Is an experienced developer.

He's a single source for the rest of the team to look up to and seek advice from. He's also the mediator between higher-level management and the core development team. I don't know of any managerial team that likes dealing with change (unless they're the ones instigating it).

If you really are the best suited for the position, everyone would know that. Everyone would know that (e.g. higher-level management, your teammate, etc.). State that you don't believe rotating the position is worthwhile (if you believe so). Then sit back and let them do the appointing - refrain from name-dropping or any sort of self promotion as this would make you look unprofessional

  • @Jonathan Khoo: your answer appears to be "forget a flat system, hire a rock star developer".
    – Мסž
    Commented Mar 2, 2011 at 5:14
  • 3
    @moz - Maybe not a rock star developer, but once a project reaches a certain size it does make sense to have some sort of primary point of contact that handles the administrative overhead. This could also just be a project manager that doesn't do any development work.
    – rjzii
    Commented Mar 2, 2011 at 5:47
  • 2
    if it's a flat team, the "lead developer" won't get any more payment than the rest. He'll have the responsibilities but not the benefits of having a senior position. That's in fact the reality in just about any team I've ever worked in.
    – jwenting
    Commented Mar 2, 2011 at 7:46
  • 6
    @moz: A rock star would be wasted in that position, since a lot of what the lead developer does wouldn't involve programming. Experience is useful since it allows the lead to mentor, and gives him or her the geek cred to lead effectively, but you probably don't want your most productive developer spending time in meetings with higher management. Commented Mar 2, 2011 at 16:37
  • 1
    I find that managerial types that know what coding is about (can read code, know what tables and databases are, know what a TCP/IP-socket is, may have coded before) are the best fit for these roles. There IS a lot of paperwork involved after all, and they're used to it. Commented Mar 2, 2011 at 16:57

There are two parts to being a lead developer:

  • Technical Leadership For technical leadership, it makes sense to choose a different lead developer at the project level. Make each developer be a technical lead for a different project, rotating if necessary as projects rotate. This kind of approach can deal with the team dynamics, and make sure everyone is properly challenged

  • Communication A single point of contact for communication with the outside world is good for the outside world, and bad for the point of contact. Whoever gets stuck with the communication ball will have less time to do real work, and have to run around getting information from everyone to pass along. If you're the best communicator and are willing to stop doing as much of the fun work in exchange for doing all the talking, more power to you.

  • So would it not be possible to split these two roles? Often the best communicator isn't the best one technically. I have found the best "pair programming" situation comes when each one excels in one of those
    – CashCow
    Commented Mar 2, 2011 at 12:09
  • Can confirm. I accepted my first lead role 6 months ago (team of 12 devs), and have never spent as much time not programming as I do now. Mostly just mentoring, managing, and reporting upward. Commented Sep 6, 2013 at 13:25

It's not necessarily a bad idea, provided the developers involved are engaged and (ideally) capable.

I'm having trouble finding references for this (but I'll keep looking), but if I recall correctly some agile companies do this -- they rotate the title of "team lead" either every iteration or at some other pre-define time period. That promotes developer involvement and gives everyone a chance to do some of the team management/external communication without permanently moving a developer from developing into that role.

Some drawbacks include potential loss of information (this can be mitigated in a number of ways) and higher potential for "bad" leadership. It may also be difficult to maintain a vision/direction for the team. However, if everybody is on board with this approach and the team members are both knowledgeable and interested in making such a system work, it can be worth a shot.

  • I don't think you necessarily want to rotate EVERY dev into the team lead position, but I would expect a senior dev to be able to handle those responsibilities. Frankly, it's a thankless job, and it's more a case of sharing the burden and avoiding burning out one individual. I also think it'll help keep the advantages of your flat org team dynamic in tact to not have one dev as the permanent lead.
    – MebAlone
    Commented Aug 28, 2012 at 1:47
  • "Some drawbacks include potential loss of information (this can be mitigated in a number of ways) and higher potential for "bad" leadership" : what about rotating only on selected developers, this may avoid this problem.
    – Adriano
    Commented Sep 22, 2014 at 10:42
  • 1
    @AdrienBe You'd still need to transfer info between them. Unless they're leading at the same time all the time (which defeats the purpose), you're going to have to take this into account. You might also alienate other devs on the team who don't get to lead at all and may feel left out.
    – Adam Lear
    Commented Sep 22, 2014 at 14:20

If you rotate, don't do so during a project. There's nothing intrinsically wrong in assigning different roles to different people for different projects, based on who's most appropriate in each position for that particular project. But don't make Joe "lead programmer" just because it's his time on the roster to perform the job. He may not be skilled for it, he may not even want the job.


Rotating the lead developer based on time is a bad idea.

Everyone is a good developer does not means everyone is a good leader. And one is a good leader doesn't means he is suitable for the leader of this program.

I think the importance of the missions assigned to developers is different, and each developer's leadership is different.I think you can advice your manager to hold a vote. Every one vote 2 people for the best candidate, and the person who get the most vote should be the leader developer


I'm inclined to agree with Jonathan Khoo that rotating the lead developer could be a bad idea. Generally for larger projects there is a single technical lead that heads the project and that person may have several component leads reporting to them to discuss various system wide issues.

However, one important point that Jonathan didn't mention is that the technical lead also develops a high degree of institutional knowledge that others on the project might not have. By rotating the technical lead you are requiring them to develop that knowledge each time someone is rotated into the position. Additionally, the lead will develop a rapport with the customers outside of the project as they should ideally be present for some of the (larger) meetings with the end users.

Having a technical lead is good, but if you try and rotate them out you may find you were better off without one.


I think first you need to determine what the role of this person is, more than who does it and for how long.

You also need to determine whether this is going to significantly change the way the rest of you work and whether it will reduce your performance. Having one person have to "approve" every line of your code rather than any peer do that can have a serious effect.

Different specific roles can be given out to different team members, without any of you being "superior". The one who is best at communicating between the manager and others may be given a specific role to do that, but that doesn't mean they are a "lead developer", and they might not be the person who is best technically or best at doing code reviews.


I'd be willing to bet that while the team is ostensibly flat, there IS a leader among them already, AND they all already know it.

Org charts rarely reflect how people actually work. Especially idealized charts like "a flat team".


If your organization is flat, then have all your dev's go through Requirements and Solutions Analysis (RSA) training to have them follow a formal process. You can then assign multiple subject matter experts (SME) to a project and get a documented process to all the solutioning.

Also, since you mentioned that the manager is non-technical, that individual can still drive the RSA process and facilitate the communication. You can also assign a particular SME as a lead on a project by project basis to assist in facilitation and build their individual skillsets.


Why doesn't the dev team vote anonymously? I would use preferential voting.

  1. You can select someone among your team to lead your team.
  2. Your boss can hire another experienced person to take this position

P.S. I don't think rotating is a good idea, the person must skill at communication , and have a good experience in managing a team.


As your question suggests, the whole team is responsible for decision making, I'd suggest you can keep it the same way. However, for communicating and reporting to authorities outside the team, you can have a Team Co-Ordinator selected from with in the team. His/her responsibilies would include everything non technical. For all the technical aspects, the team should sit and discuss the same way as you do right now. Whatever decision you make, would be communicated to outside world via the Co-Ordinator. This position can be rotated easily on a time based fashion.

The other approach can be to have a lead developer based on the level of experience > experience on the same project > experience in the same company. And if the need be, the position can be rotated on phase to phase basis. Ideally, each development phase has its own set of requirements and deliverables, which can be planned for and worked on as a mini project. Having a different lead for each phase would minimise almost all the negative impacts of rotation.


Instead of having a rotating lead developer, have a rotating project leader, someone who has the most knowledge and understanding to get x project towards completion.

Lead Developer usually is a promotion, and should be earned.

But to help train and develop leadership skills, rotate who is in charge of different projects, and then have clear measurement of how well they did or not did.


There must be a team leader in the same way there is a captain on a sufficiently large ship.

If the manager do not or can not fill that role, one of the developers must be appointed to fill it.


I think you should first collectively realize how lucky you are to have the power of making all the technical decisions inside the development team. How many teams suffer from the burden of a micromanaging hierarchy that impose their technical whims on them, often resulting in inconsistent choices, compatibility nightmares and developer frustration...

In the benefits of a dev lead you mention, some of them (organized technical guidance...) should already be happening if there actually was a naturally outstanding person in terms of technical skills. If this is the case, I can't see how officially making that person a lead developer would give better results than the ones you get now. If such a team member doesn't exist in your team, then I can't see how officially giving technical authority to any person would lead to better results than discussion and collective decision.

I see much more value in establishing an organizational leader - a coordinator as Danish put it. Not a manager, not a boss but someone who would organize the collective decision making process and act as a spokesperson for the team, an interface to the outside. If you go that way, rotating can be a good idea to avoid aforementioned issues - salary differences, jealousy...


Sometime, being a leader is rather a heavier responsibility than something else. Someone HAS to take responsibility for choices, that's how society works when nobody else wants to do it.

The fact a team wants to rotate the leader may mean that everybody feels they can can take responsibility for what they do, and they don't want to favor anybody, and it seems to be a good thing: there are no hard feelings, and everybody wants the team to success.

In those cases, when there are hard decisions to take, just do a vote for those decisions, and when you need a representative to talk to other people, just elect someone that has the best communication skills.


First of all, I think you need to separate out the roles. There is no reason that the person acting as the point-of-contact between the team and the rest of the company needs to necessarily also be the person making final technical decisions.

Acting as the point-of-contact shouldn't confer any authority, so rotating that responsibility on a fixed schedule shouldn't be necessary. I'd say have the team sit down, everyone says how much they'd mind doing the job (some people might like it, others might be strongly opposed to doing it), then vote someone to fill the role. Make it understood that they can turn it over to someone else whenever they get sick of doing it.

As for the technical lead side. If everyone has the same skill set and roughly the same level of experience, then sure, let everyone try their hand at being a lead. The important thing is to absolutely not change mid-project. Wait until the start of a new project, and then pick the lead either who has the most experience in that area, or at random.

Not the answer you're looking for? Browse other questions tagged or ask your own question.