Why companies and teams should be dictatorships

Everyone has a unique view of the world, different experiences, different ideas, and acknowledging this and being able to listen and understanding 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 for your nightmares, and these situations can be very challenging.

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

The problem

The same way that a ship has only one captain, your company and your team must have only one leader. Someone to take the decisions and lead the product and the team for 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 point of view, only this way we can rethink our ways and be better.

The problem is: 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 opinions to take the best decision.

Let's analyze this example:

• Your company choose 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 that is in the company for a couple of months, suggests to use Node.js.

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

• Mike, a Mid-Level developer that is in the company for a couple of years, has no preference, but would be open to try something new and use Node.js.

• Lucas, a Senior developer that is 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 work with PHP, has all the pipelines and process 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. This is 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 for any other language, including reverse PHP with Node.js, 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, duplicates the effort, duplicate 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 experience 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), databases.

And 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 developer 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 advices:

• 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, 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 to other places that can make them happier, it's normal, it's the cycle of life. Ideally, on the recruiting process it would be possible to filter people that 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.