Why companies and teams should be dictatorships

Why companies and teams should be dictatorships

Everyone has a unique view of the world, different experiences, and different ideas, and acknowledging this and being able to listen and understand to all these different views is essential for us to discover new things, improve ourselves and the things that we build, and be better, but sometimes, this can lead us to a dark path.

As a leader, you should be a reliable person. Someone that your team members can trust and look for when they have something to say, be it an idea, a problem, or the solution to your nightmares, and these situations can be very challenging.

In this article, we will discuss the dangers of listening to everyone's ideas and the things that you can do to avoid them.

The problem

In the same way that a ship has only one captain, your company and your team must have only one leader. Someone to make the decisions and lead the product and the team to a place where it's better for the collective.

If you listen to many people or leave things open for voting, you are being a terrible leader and avoiding the responsibility of your position. It's your job to know the macro context and know how a decision will affect this context. If things go wrong, that's on you, and this is why you should be worried about how to listen to people.

The solution

It's very important to listen to other people. Nobody knows everything, and the wisest thing to do, always, is to listen and try to understand other people's points of view, only this way we can rethink our ways and be better.

The problem is that everyone has a bias. Everyone has THEIR OWN point of view and many times, the things that they say go from that point of view, so you must know how to evaluate people's opinions to make the best decision.

Let's analyze this example:

  • Your company chose to refactor an old code base written in PHP 5.4 to something more up-to-date

  • Your team has the responsibility to choose which programming language you will use to do it.

  • Your team has 4 members: John, Dave, Mike, and Lucas

  • John, a Junior developer who has been in the company for a couple of months, suggests using Node.js.

  • Dave, another Junior developer just hired, agrees with John.

  • Mike, a Mid-Level developer who has been in the company for a couple of years, has no preference but would be open to trying something new and using Node.js.

  • Lucas, a Senior developer who has been in the company for many years, suggests not changing the programming language and just upgrading PHP to the latest stage version.

If you run your team as a democracy, your team would refactor the system using Node.js, since you have 2 votes in favor, 1 absent, and 1 against it. But that's good, right? Power to the people, this way your teammates are happy, and you avoid having discussions, dissatisfactions, members leaving the team, and any other trouble that could happen.

Now let's analyze the context, that it's your job as a leader, to know of:

  • The company has a couple of teams, and all of them work with PHP

  • The company is used to working with PHP, and has all the pipelines and processes to work with it

  • The most knowledgeable developer in your team has years of professional experience with PHP, the second also has years of experience with PHP

  • The only experience with Node.js that your team would have is from 2 Junior developers, in their first jobs.

Do you still think that would be a great idea? Because I don't. I think that any leader that allows it to be rewritten in any language that isn't PHP should not be a leader. Is this because PHP is the best language of all time for all the projects and everyone should be using it? For sure not. It's because PHP is the best language for this specific context. You could replace PHP with any other language, including reverse PHP with Node.js, and the result would be the same.

Let's see the pros and cons of allowing the project to be rewritten in Node.js.

Pros:

  • Your team members are happy

  • Depending on the technology, you may have a better performance or some kind of technical gain

Cons:

  • Your team would be the only one working with that language, and the only one to have a different pattern.

    • You will have no other teams to ask for help, you will have to figure everything out by your own.
  • If your company has internal libraries, they would have to create other libraries just to be used on your project.

    • Duplicates logic/utils, duplicate the effort, duplicates the costs.
  • New pipelines would have to be created, just for your team's project.

    • How much time it would take? Time is money, how much money it would cost?
  • The most experienced developers of not only your team, but the entire company, in that technology, would be the Junior developers that don't have any kind of deep understanding of how that language works.

    • What happens if they get hit by a bus?

For me, looks like the cons overcome the pros, no?

You could argue that "changing versions also could lead to all these problems", and you are right, but what can cause more conflicts, changing versions of the same language, or changing entire ecosystems?

The same principle could be applied to anything: Libraries, frameworks, protocols (like GraphQL), and databases.

Note that in this example I used Junior developers to be the ones that bring these changes, but this is not a matter of seniority, even Senior developers could do things like these.

Sometimes, the pros overcome the cons, and the technical gains that you have with that change would make up for all the trouble that comes with it.

Conclusion

It's your responsibility as a leader to be able to evaluate all these things that your team members may not have the context to understand. You must protect your project's integrity inside the company, to ensure that the product works, and you all have jobs the next month and next year.

Here are my final advice:

  • Do not let quantity scare you, just because many people are saying something, it doesn't mean that it's right.

  • Always think in the big run, your team members may not be in the company in the next year, and you may not be in the company in the next year, but don't be an asshole with other people. Create a project that can be maintained for years.

  • It's impossible to make everyone happy, and sometimes people will leave for other places that can make them happier, it's normal, it's the cycle of life. Ideally, in the recruiting process, it would be possible to filter people who can't stand the way that your company works, but sometimes they don't, so we have to deal with it.

  • Always listen to your teammates and try to understand what they are saying. Great ideas can come from everyone, even Junior developers.