Most teams are surrounded by objectively easy, low-hanging ways to improve but often do nothing. Why? Even low-hanging fruit requires someone to take the first step. People push back if that step involves a perceived loss of credibility, authority, or control. If one team appears to 'win' while another 'loses'—even a simple fix can feel destabilizing and threatening. And if an idea comes from someone outside the dominant group or threatens an entrenched narrative about how things work, people will resist.
If an improvement is easy and obvious, but it still isn't happening, ask:
Who pays the ego toll?
Who has to admit they were wrong?
Who loses status or authority?
Who has to accept an uncomfortable truth?
What story about the organization or team would need to change?
What you tend to find is that "easy" is rarely easy. In fact, if something obvious has lingered for a long time, it is likely very difficult. The ego toll is high—maybe even higher than if this was a universally recognized "difficult thing to do."
For example, an engineering manager has, for years, played requirements relay between product management and design, and the engineers on their team. They self-identify as being the team's protector, the team's filter, and the codebase subject matter experiment. The company's performance management approach emphasizes individual project work, and the manager believes, with some evidence, that they've "Figured out how to help [their] engineers navigate the system."
But it is as plain as day that their approach causes needless rework, encourages learned helplessness on the part of their reports, keeps engineers from valuable interactions with team members and customers, and ultimately decreases the team's effectiveness.
A lot is happening here—it's not as simple as the manager being closed-minded or resistant to change.
If engineers interact directly with the product manager and designer, the manager will pay the ego toll. Acting as the go-between was a big source of pride and heavily aligned with their work identity. There's also a good chance that the engineers on the team might feel a little awkward as they get up to speed.
If the manager has adamantly protected this stance for years, it might feel like doing anything otherwise is admitting they were wrong.
The manager loses status and authority.
Someone may need to accept the uncomfortable truth that the current way of working, while optimized for engineering efficiency, might not produce the best results.
The company may need to change multiple stories—about role boundaries and definitions, performance measurement and management, the importance of direct contact with customers, efficiency and efficacy definitions, and more.
This is why something as simple as "Maybe we could consider an experiment whereby product managers, design, and engineers work more closely together, and perhaps everyone tries to jump on customer calls when they can" might be met with the Eye of Sauron.
An important point is that it is easy to frame this as a growth vs. rigid mindset issue, with open-minded people (which we all identify ourselves as) on one side and rigid ego-protecting people on the other.
But no one is immune—even (or especially) people who suggest new ways of doing things. Advocates for new ways of working often find a lot of their identity wrapped up in challenging the status quo and being rewarded and recognized for being trusted authorities. They also have a pesky habit of believing their personal toolbox is always the right one.
We all seek to save face and protect our identity and ego.
With that in mind, consider:
How can you offer a new narrative that preserves identity?
How can you reduce the threat level by framing things as specific and temporary—not a whole new way of working?
How can you shift status, not remove it? In this case, is there a path for the engineering manager (and team) to feel respected and rewarded while wearing a different hat?
How can you make this about the whole team, not just one person?
How can you align the effort with something bigger than the team? The business has survived this long, so what "big picture focus" has changed?
Love this, it is where most 'politics' in a company start from. Where the 'build an army' mentality comes from too.
> In fact, if something obvious has lingered for a long time, it is likely very difficult.
This is one of those office koans that took me way too long to grasp. This post does a great job articulating the reasons why “simple doesn’t mean easy” in this context. Going to share with some of the other leaders in my company. Thanks!