When no one is in charge, and why is wrong!


It’s not a new trend, nor the norm, but it is for sure a contemporary alternative way of management, at least, in the technology domain. Leaderless teams are temporarily or intentionally without a leader, but they are self-managed.

What’s the goal of a self-managed team? According to Andy Doyle, former Head of Operations at Medium, a self-management structure “aspires to empower individual voices and avoid the bureaucracy that often accompanies traditional organizational structures.”

With the usual old fashion typical team structure, a team leader is included, who ultimately(?) has the final say on team decisions and strategy. This is not necessarily bad, depending on the team members, the team’s maturity and goals.

The fact that a team leader exists, doesn’t mean that the floor is not open for discussion, or that the leader just delegates work and responsibilities without any feedback from the others. But the leader’s presence should not the issue. The leader, the manager should not be considered an enemy*.

The goal is the team members to be more involved compared to a team with a more traditional hierarchy. Why? Because a self-managed team’s greatest benefit is a more open approach to decision-making, although at the same time it can be its greatest detriment. But is this true? No! I will explain you why.

* . https://www.youtube.com/watch?v=AcgXh25mU2A

Building a leaderless team… maybe

What is the company’s culture?

Does your company have a specific culture? What is the environment any newcomer has to adapt to? Do you treat all the employees the same or do you allow cliques,  flatterers, backscratchers and sycophants? Do you allow any cultural diversity? Do you treat your employees equally?

You want to hire some people, assign to them a set of daily tasks, maybe delegate some authority, and of course responsibility for their actions and delivered work. Are all the details and the logistics clear to them from the very beginning? Were the project’s goal, timelines, other constraints explained in a detailed manner and with transparency? Cause if any information is hidden, this will cause a communication breakdown, at least in the future.

Who picks the team members?

Usually any people hired, are picked through a recruitment process. Who designed this process? Who set the hiring criteria? It was the company itself or they delegated this task to a recruitment office? I never understood why the recruiters are needed. There are middlemen, who I will meet them only for some hour(s), and I will never see them again. Plus I will never work with them! So why should they exist in the very first place?

Also, why a company hires a recruitment office? Don’t they have the resources, the time, the will, or they don’t trust themselves to find the appropriate candidates to interview? I can hardly trust companies who they don’t pick their own candidates. Sometimes they also rely too much on the recruiters’ opinions, while they shouldn’t.

Who handles the negativity?

There will be days, that this leaderless team will have one or more disagreements. The issue is not the friction itself, but the interest of the friction. Some team members want to solve a problem that is preventing the organization from reaching their goals, and others want to satisfy their personal goals.

So who is going to solve these disputes? Are they going to do it by themselves? A technical or project manager might jump in as a Deux Ex Machina to solve the issue? What is the (right) crisis management protocol for these cases, based on the company’s culture?

Negativity plays an important role in programming. I am sure that you have heard many times during your career phrases like “Υou won’t believe what that codebase was like”, “for the love of Hermes WHY would anyone do that”, “I would never write that code”, “we failed because of Chuck Parsley’s unmaintainable code”, “what were you thinking? fix it” [1].

Negativity among the programmers is the way to successfully to communicate value. As a programmer becomes more experienced, there is a great chance that they will have a more negative attitude. If the experienced senior programmers of team, express their frustration of working with bad code, the junior programmers probably will adopt the emotional habits of the senior ones [1].

Even though programmers who express opinions negatively are frequently viewed as both more intelligent and more competent [1], the team, leaderless or not, becomes more toxic. So, who is responsible of saving the team from the toxicity, or maybe from the bad code also?

A leaderless team is never leaderless in the end

In a team, there is always one or two personalities that dominate the team. No matter how much a balance is desired, always someone distinguishes, cause they have stronger personalities than the others. By default, this is not a bad thing. But it depends a lot on the dominator(s) personality(ies). If that, or those, person(s) are problem creators that put their own needs first, then the team’s relationship is going to be hurt a lot.

Other personality types you might face are the following:

  • Challengers: People who love going against convention. Challengers can deliver the great idea that unsticks a team’s thinking, but when the team has been developing that other idea a long time, their behavior can blow everything up, and team dynamics can quickly sour [2].
  • Analyzers: are the content experts. When a team is dealing with a challenge that matches the Analyzer’s area of expertise, you’re seconds away from all the latest data and research that can help you solve the problem. But when the team focus strays from the Analyzer’s areas of expertise, they get bored, lose interest, often affecting a dismissive attitude that can drag down other team members [2].
  • Implementers: or “get it done” people. They are great on the operational side so go ahead and put them in charge of tactical plans, deadlines and workflows. But Implementers can get so caught up in the logistics of asking “but is that idea feasible?” that they inhibit team innovation [2].
  • Collaborators: Say, for example, an Implementer is playing devil’s advocate to a Challenger’s big idea and a fight is about to ignite. The Collaborator is the person who jumps in and says, “You know, Pat, that was a really smart idea, but let’s just take a minute to talk to Chris about whether or not we really have a chance to make this work.” Collaborators are great at smoothing out the rough patches, but they can also take collaboration and consensus building to an extreme that hinders team progress [2].

But, No matter the dominator(s) personality(ies), has the company the reflexes to handle a supposed leaderless team, that in the end is managed by a dominating personality, or personalities? And what happens if that/those person(s) actually make(s) the team more productive? Does the company force him/them back in line or not?


Trying to build leaderless teams is not a simple task. It requires personal and professional maturity from everybody. But this can ΝΟΤ be achieved with junior programmers, cause instead of team players, they will probably behave like pawns. First, the personalities must be built, then the team. Enforcing leaderless team rules to immature personalities is equal to walking straight to hell.

Be careful what you ask for… and from whom!


[1]. https://medium.com/@way/rage-against-the-codebase-programmers-and-negativity-d7d6b968e5f3

[2]. https://www.forbes.com/sites/markmurphy/2018/01/28/how-to-manage-the-four-strong-personalities-you-see-in-meetings/#1d5af39625bf

Leave a Reply

Your email address will not be published.