I often get surprised when I hear someone say they like a certain manager. I usually have very different reservations about them in my head. The gap between what I think and what I hear can be hard to reconcile. It took me a lot of time to realize why. They give happy answers to everyone. They are easy to deal with.
Here’s my hypothesis. When too many people like a manager, it’s fishy. A manager should not be liked by everyone. If you are doing the job properly, it is not actually possible.
Management is trade-offs, and trade-offs disappoint people. You have limited capacity, limited money, limited time, limited attention, limited promotion slots, and limited tolerance for risk. Someone will want an exception. Someone will want a date before the work is understood. Someone will want to avoid hearing that their performance is not good enough.
So if nobody is ever disappointed with you, there is a hidden cost. Maybe other leaders love you because your teams keep absorbing messy dependencies. Maybe your directs love you because the standards are soft. Maybe your PMs love you because you rarely push back on dates.
Nice vs Useful
Being liked is a nice side effect. It cannot be an operating model. People confuse being nice with being useful. Nice makes the current conversation easier. Useful makes the next few months less painful. Those are not the same thing, and they are often opposites.
A nice manager says yes because the meeting is overwhelming. A good manager explains what needs to be true before saying yes responsibly. A nice manager delays feedback because the person is struggling. A useful manager gives the feedback while there is still time to do something with it.
No Soup for Happy Answers
Your Peers
Easy to work with has a good version and a dangerous one. The good version means other leaders can actually move work through you. The dangerous one means your org is just easy to push work into. I am not arguing for territorial nonsense where every dependency becomes a political battle. That is exhausting and usually useless. But the difference is important.
That is why my default answer is often no. I am not trying to be difficult. We can only do so much, and I need to understand what we can actually take on at a given time. If we let things loose, our own roadmap gets worse. Saying no is protecting people from priority churn, protecting teams from weak handoffs, and protecting the organization from work entering through side doors.
That same tension shows up with your peers. Everyone wants the best for their people, including them. Naturally, there is conflict. Calibration is one place where it becomes visible. If an engineer did strong work, defend it. If a manager built a healthier team under ugly constraints, make that visible. If someone challenges the impact, bring evidence. If another leader tells a cleaner story, get better at telling the truth with force.
You still cannot win every fight. That is alright. But there is a difference between losing a fight and never having one. Weak managers come back with fog. The budget was tight. More visibility next cycle. Maybe it is true. Maybe it is just what is left of a fight they avoided.
Resourcing is the same trade-off in a different room. Your org needs people. So does your sister org. Everyone pulls from the same resourcing pool. If you do not make the case, or you do not fight when the case is strong, your peers may like you. Of course they may. You are easier to negotiate against.
Your org pays for it. You keep running with too few people, too little seniority, or too much work mapped to the same two engineers. Growth slows, dependency risk goes up, and good people get tired. Eventually, people start to read the pattern.
Your Directs
If all your directs like you, you may not be distinguishing between low and high performers. You are supposed to do that. Period. That feels unfair to a lot of managers, because they think fairness means treating everyone the same. It does not. Fairness means the bar is real, visible, and applied with judgment. Someone who consistently raises the quality of the system should not have the same experience as someone who creates work for everyone around them.
A vague bar is the opposite of a visible one, and vagueness is comfortable. It makes the manager easier to like, because nobody has to hear anything too clearly. So low performers get more time, more interpretation, more benefit of the doubt, more "let's support them," and more "maybe the expectations were not clear."
Sometimes that is the right call. People need coaching, and a bad quarter does not make someone a bad employee. But there is a point where support turns into denial. The work is not at the bar, the team knows it, and the person probably knows it too.
Past that point, everyone starts working around the problem. High performers pick up the gap. The manager compensates. The team builds local hacks to survive the weakness without naming it. That is not kindness. It only feels kind to the person avoiding the conversation.
And it does not actually fix anything. Bad work does not get better because it was hidden politely. A strong engineer keeps fixing bad PRs. A skip manager keeps covering for a manager who cannot run the operating rhythm. From far away this can look like stability, which is the trap. Up close, the people doing the compensating get tired. Nobody has infinite stamina.
This is not only about individual contributors. The same blind spot shows up one level up, in how managers get judged. One builds a healthy team, grows people, manages risk early, keeps delivery honest, and makes the work easier to reason about. Another avoids hard feedback, lets operational debt grow, leans on two seniors, and reports everything as fine until it is not. If both get the same treatment, you are not being fair. You are avoiding judgment.
Either way, the team learns the real rule: standards are flexible when enforcing them would cost the manager too much. People adapt to a cost they no longer expect you to remove.
Your PMs
The relationship between Product and Engineering should have tension. No tension means no real negotiation. Product should push for outcomes, customer value, dates, and market pressure. Engineering should push for feasibility, sequencing, quality, reliability, and capacity. When that tension is healthy, the plan gets better. When engineering keeps saying yes, the plan just gets flashier, not more real.
A PM who never walks away from you frustrated is a PM you are failing, especially where it hurts engineering health. A roadmap without engineering pushback can look fancy and be completely toothless. If nobody forced the trade-off, the trade-off did not disappear. That is how you end up with a fixed date, fixed scope, fixed quality bar, an unstable dependency, no room for engineering health, and somehow no change in expectations. You looked collaborative when you agreed. Now the team has to pay for it.
There is a counterpoint, though. Engineering should not become the place where momentum goes to die. The org still needs to move faster, and engineering leads should be willing to take calculated risks. Your job is to make the risk explicit. That is the buffer role. That is normal. That is good. I am happy to be told that my idea to get something done in two months is stupid. It is better to hear that early than assume it is possible and miss it later.
I learned something in my career: if someone says yes without a but, without friction, I do not fully trust their yes. The useful answer is rarely just yes. We can do this, but not at the current scope. We can hit the date, but these pieces have to move. We can build it now, but this area is already operationally weak. We can ship it, or we can stop and clean this up so the next three features do not get slower.
Your Boss
Some leaders please upward by making every update sound controlled, reasonable, and mostly on track. Leadership wants tangible results. Move a metric, improve a KPI, sell more, retain more, convert more, reduce cost. That is normal. Metrics matter. The question is always: at the cost of what? You can reduce infrastructure cost and make developer experience terrible. You can ship faster by skipping the migration work. You can improve the dashboard by pushing operational cost into the team. You can make the quarter look better while making the next three quarters slower. The problem starts when a leader wants to be liked upward, so they present the fast path as if it is the real path. The number looks better, but the architecture, migration cost, ownership model, and operational reality have not been thought through.
There is no clean delivery of a project, program, or business outcome. It involves people, their careers, their aspirations, their incentives, and their fears. There will be issues. Hiding them as if they do not exist might feel like you are doing a good job. Your boss might even like it because you always sound calm and under control. A better version is to surface the issues and bring alternatives. Give your boss enough context to choose what to do next. They have been there. They have done that. Most of these problems are not new to them, but they have power you do not have. Use that. Worry them early. Worry is only useful while there is still time to act on it.
The Other Side
There is a fair objection here. Some managers are liked because they are good. They explain trade-offs clearly, they apply the bar evenly, and people respect the result enough to enjoy the work. That happens. But it is rarer than it looks, and it is easy to confuse with its cheaper cousin, where people like you because nothing is ever asked of them. The test is what the liking is made of. Respect for clear calls, or relief that no call was made.
I guess it’s obvious but being disliked is not the goal either. If everyone liking you is a warning sign, it does not follow that being disliked makes you good. Plenty of bad managers are disliked too. They are just disliked and wrong.
Disliked is a cost you sometimes pay for being useful. It is not proof that you were. Did the disappointment buy something? Did anyone's next few months get better? If yes, the cost was worth paying. If no, you did not make a hard call. You just made people unhappy.
The Cleanup
The worst part is that the manager who runs this playbook usually does not stay long enough to pay the bill. The surface holds while they are there, and then they move on through a promotion, a transfer, or a new company, leaving the system behind exactly as it was.
Whoever takes it over has to start saying the things the liked manager spent years avoiding, and the moment they do, they become the difficult one. The discomfort was never removed, only deferred onto whoever arrives next. A likable manager can leave behind an unlikable recovery, and someone else has to clean up the shit they were too liked to touch.