Everyone sees the world through a unique lens, shaped by their own experiences and ideas. Recognizing this and being willing to listen to and understand different perspectives is essential for discovery, personal growth, and building better things together. However, sometimes this openness can also lead us down a darker path.
As a leader, you need to be someone your team can rely on, someone they trust and feel comfortable speaking to, whether they have an idea, a problem, or even a solution to your nightmares.
It's always valuable to listen to your team, but that doesn't mean you should always follow their suggestions. Good leadership involves hearing every voice, then making thoughtful decisions based on what's best for the team and the goals at hand.
In this article, we’ll explore the risks of trying to consider everyone’s ideas equally, and share strategies to avoid these challenges while still encouraging collaboration and open dialogue.
The problem
Just as a ship has only one captain, a company or team needs a single leader: someone responsible for making decisions and guiding both the product and the people toward what’s best for the group as a whole.
If you rely too heavily on group opinions or put every decision up for a vote, you risk avoiding your responsibility as a leader. It's your job to understand the bigger picture and how each decision affects it. If things go wrong, it’s your fault, not theirs. That’s why it’s essential to be discerning about how you listen to others.
Let’s be clear: people have their own motivations, their own challenges, and their own areas of focus. Your team isn’t responsible for the big picture — their job is to handle the small details. And it’s precisely those details that keep a company growing and delivering results.
A developer won’t have insight into marketing, just as a salesperson won’t be familiar with the company’s quarterly financials. That’s not their role.
A leader, however, must understand the broader picture: the basics of how each area of the company operates to align everyone toward a common goal. Team members are the engines of the company, and leaders are the gears that connect them to the wheels, making the whole vehicle move forward.
The solution
Listening to others is essential. No one has all the answers, and the wisest thing you can do is stay open, truly open, to other people’s perspectives. That’s how we grow, challenge our assumptions, and become better.
Sometimes, a janitor might share an insight that changes your life. Never judge someone by their role, race, sexual orientation, or any other bias. When you do, you’re not just being unfair, you’re closing the door to valuable experiences and perspectives.
Listening to what others have to say, understanding their context, and having the empathy to put yourself in their shoes, that’s what allows you to truly analyze their perspective. Doing this for each person on your team, one by one, is what will lead you to greatness.
It’s not easy, is it? But no one ever said that being a good leader would be easy.
The example
Let’s look at an example:
Your company has decided to refactor an important microservice. The current codebase is outdated, written in PHP 5.4, and no longer meets modern development standards. Your team is now responsible for rewriting the service, giving it the opportunity to choose a new programming language.
Your team consists of four members: John, Dave, Mike, and Lucas.
John, a junior developer who joined the company a few months ago, suggests using Node.js.
Dave, another junior developer recently hired, agrees with John.
Mike, a mid-level developer with a couple of years at the company, has no strong preference but is open to trying Node.js.
Lucas, a senior developer with many years of experience in the company, suggests sticking with PHP and simply upgrading to the latest stable version.
If you run your team like a democracy, the decision would be to use Node.js: two votes in favor, one neutral (effectively in agreement), and one against.
That sounds good, right? Power to the people. Everyone feels heard, there's no conflict, the team stays happy, and you avoid potential dissatisfaction, heated discussions, or even team turnover. Problem solved, right?
Now let’s analyze the context, because understanding context is your job as a leader:
The company has several teams, and all of them work with PHP.
The entire infrastructure (pipelines, deployment processes, monitoring) is built around PHP.
The most experienced developer on your team has years of professional experience with PHP. The second-most experienced does as well.
The only experience with Node.js comes from two junior developers, both in their first jobs.
So, do you still think choosing Node.js is a great idea?
I don’t. In fact, I believe that any leader who allows a refactor like this to happen in a different language (under these circumstances) shouldn’t be in a leadership position.
Is that because PHP is the best language in the world, suited for every project, everywhere? Absolutely not.
It’s because PHP is the best choice for this specific context.
You could swap PHP or Node.js with any other language: Python, Ruby, Go. The logic still stands: good decisions are made with context, not popularity.
To be even more didactic, let’s weigh the pros and cons of rewriting the project in Node.js in this context.
Pros
Your team members, especially the juniors, are excited and happy.
You might see performance improvements or gain access to certain modern tools or frameworks.
Cons
Your team would be the only one in the company using Node.js, creating an inconsistent pattern across teams.
There would be no one else to turn to for help. You’d be on your own when facing issues. It’s a very important service. Are you sure that you should accept the risk?
If the company uses internal libraries or shared utilities, new versions would need to be written just for your project.
New deployment pipelines and processes would need to be built and maintained separately.
The most “experienced” developers in Node.js would be two juniors, still in their first jobs, with limited real-world understanding of the language and its ecosystem.
And if they leave the company or, as the classic phrase goes, get hit by a bus, what then?
When you look at the full picture, it’s hard to argue that the pros outweigh the cons. For me, it's clear: the cons far outweigh the benefits.
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? Making decisions is not about choosing the option that has no risks, but choosing the one that has the risks that you are willing to take.
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 can fall into this trap. When you’ve worked with the same technology for a long time, it’s natural to feel bored and eager to try something new. And that’s a good thing—innovation comes from curiosity.
But innovation needs direction.
So instead of experimenting with the company’s core systems (the ones that run the business and keep everyone’s jobs), why not apply that drive for innovation to smaller services or less critical parts of the ecosystem? That way, you encourage growth and experimentation without putting the stability of the entire company at risk.
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
As a leader, it’s your responsibility to evaluate the things your team members may not have the context to see. You must protect your project's integrity within the company so that the product remains functional, valuable, and sustainable. Your job is to make sure the work continues, and that everyone still has a job next month, next year, and so on.
Here’s my final advice:
Don’t let quantity intimidate you. Just because many people are saying something doesn’t mean it’s the right thing. Leadership is about discernment, not popularity.
Think long-term. You or your team members might not be in the company a year from now. That doesn’t mean you should cut corners. Build something that’s maintainable for the people who come after you. That’s how you show real leadership and respect.
You can’t make everyone happy. Sometimes people leave, and that’s okay. It’s the cycle of life and work. Ideally, the hiring process filters out those who aren’t aligned with how the company operates, but when that fails, we have to manage the gap with empathy and maturity.
Always listen. Truly listen. Great ideas can come from anywhere—yes, even junior developers. Your role is to encourage those voices, evaluate them with context, and decide what’s best for the bigger picture.
