Us and them
Breaking the walls between teams
You know that feeling when you're on holiday and you come across a fellow tourist from your home country? Even though you have no idea what kind of person they are, you still feel the urge to say hi. Or that energy you get when you're at a game cheering for your favorite team, and you're empowered by the chant of your fellow supporters?
Both of these feelings come from a basic human need: The need to belong.
We're social animals. We crave connection and community, a sense of being part of a tribe. But this feeling can turn sour in a company setting. When we find our group, every other team, track, or department becomes "them". We begin to judge others more harshly and praise our own team excessively.
Research1 backs this up: people tend to rate their immediate team more positively than their department, and their department more positively than the company. The further the distance in the organizational hierarchy, the weaker the sense of belonging.
As engineering managers, we need to recognize this pattern and help channel the "us vs. them" dynamic into something constructive, rather than letting it damage collaboration from the inside.
Where do we belong?
It's easy to forget: we all work for the same company.
If our team is doing great work but every other team isn't, then the company fails. And if the company fails, so do we.
Sometimes, focusing too much on our team's goals can actually mean we're working against others. We might unintentionally hoard knowledge, block cross-functional progress, or simply not care what happens elsewhere. So what causes these splits in the first place?
Why do we split?
In small companies, culture is more unified. You probably know everyone's name, and collaboration feels natural.
But as companies grow, they naturally split into functions, disciplines, and departments. That's not inherently bad (it brings clarity and focus) but it does increase the risk of isolation.
Over time, "us" becomes our team, and "them" is everyone else.
It doesn't just happen across teams. It also shows up in hierarchies. As a manager, you might feel you're part of the "management team", separate from Individual Contributors (IC). Or as an IC, it might feel like the C-level execs are some other species entirely.
This is inevitable. But it's not unchangeable.
As engineering managers, we can play a key role in bridging these gaps.
What can you do about it?
Company alignment
Be the person who reminds others: we're all rowing in the same direction.
Clarity around company goals is essential. Mission, vision, and values are a good starting point but they mean nothing if they aren't lived.
Make the connection visible: show how each team, each person, contributes to broader goals. When that connection is clear, the sense of shared purpose grows.
For example, imagine the company has this top-level OKR: Improve customer retention by 15% over the next two quarters.
Now see how different teams align their OKRs with it:
iOS Team Objective: Increase app stability and performance to enhance user satisfaction.
KR1: Reduce crash rate from 1.2% to 0.4%
KR2: Improve app launch time by 25%
Backend Team Objective: Ensure fast and reliable delivery of key user data.
KR1: Bring 95th percentile API latency under 400ms
KR2: Improve data consistency between services to 99.9%
Customer Support Team Objective: Provide faster, more helpful support responses.
KR1: Reduce average first-response time from 12 hours to 4 hours
KR2: Improve customer satisfaction score from 82% to 90%
Even though each team focuses on different areas, they're all pulling toward the same outcome: better retention through a better experience.
Team outings
When we step out of our work environment, we often speak more freely. Use that to your advantage. Create space for open conversations. Let your team voice their frustrations and help them unpack those feelings together.
Often, what feels like interpersonal tension is actually caused by:
Lack of transparency: We don't know what other teams do, so we assume the worst.
Lack of empathy: We don't understand others' constraints, so we think they have it easier.
Lack of communication: We don't talk, so we assume others don't care about us.
Talking about these issues outside day-to-day delivery can create powerful shifts in perspective.
For example, during an offsite lunch, one of the engineers vented about how frustrating it was to deal with “slow responses” from the QA team.
That sparked a candid discussion where QA shared they were short-staffed and juggling three overlapping releases.
What started as a complaint turned into a moment of empathy, engineering offered to help write better pre-check documentation to reduce back-and-forth.
That one conversation did more for cross-team trust than weeks of status updates.
Cross team pollination
Don't stop at outings—organize cross-team events. Mix entire departments. Encourage interaction across boundaries.
Recurring rituals like weekly engineering meetings, chapter gatherings (e.g., iOS, backend, QA), or demo days can help teams see each other's work and challenges.
The goal: reduce "us vs. them" by building more "us".
For example, once we ran bi-weekly Engineering Demo Fridays. Each team had 10 minutes to share something they'd shipped, learned, or struggled with.
At first, attendance was low. But over time, people got curious: “Wait, how did the backend team cut deploy times in half?” or “Who built that accessibility tool?”
It created organic cross-team conversations, knowledge-sharing, and a renewed sense of pride in each other's work. People stopped seeing their colleagues as distant strangers and started seeing them as partners.
Externalizing
There's nothing wrong with a little rivalry if it's aimed in the right direction.
Instead of letting frustration turn inward, try turning it outward. Make the "them" an actual competitor.
Channel that energy into building better products, shipping faster, or solving harder problems than the company across the street.
For example, a frontend team was frustrated by slow decision-making and design changes. Instead of letting that resentment fester internally, their manager reframed the conversation: “What if we were a startup trying to beat us? How would we build this faster and better?”
That turned into a small, focused initiative: a three-week sprint to rebuild a key flow with half the steps, faster load times, and fewer dependencies.
The energy shifted. It wasn't about internal blockers anymore, it was about outpacing the competition and making something great.
Internal Mobility
The longer someone stays on the same team, the more they identify with it.
Encourage internal mobility, both temporary and permanent. Short-term embeds, rotations, or transfers help people understand how other teams operate and what challenges they face.
This builds empathy, reduces silos, and spreads skills and best practices.
For example, a backend engineer joined the mobile team for a one-month rotation.
At first, they were surprised by how much time was spent handling edge cases and App Store constraints, things they’d never had to think about.
By the end of the rotation, they not only appreciated the complexity of mobile development, but also suggested improvements to their own APIs to make mobile work smoother.
The rotation led to stronger collaboration, faster feature delivery, and a new culture of mutual respect.
Metrics and transparency
Trust erodes when we can't see what others are doing.
Instead of expecting every team to explain their internal workings, give them clear, observable metrics that reflect their contributions to company goals.
Think of each team as a black box: We don't need to know exactly how it works, as long as we can see it's moving the right metrics.
When we do see something off, we don't assume incompetence, instead we reach out to help.
For example, the infrastructure team was often seen as a black hole. Tickets went in, and weeks passed with little visibility.
To fix this, they started publishing a simple weekly dashboard: uptime metrics, average ticket response times, and progress toward quarterly goals.
Other teams quickly realized infra was actually delivering consistent value, they just hadn't been talking about it. The dashboard didn't just build trust. It opened doors to new questions, aligned priorities, and unexpected collaboration.
Conclusion
"Us vs. them" is a deeply human instinct. But in a company, it's not a fight we want to win because it means someone else in the company is losing.
As an engineering manager, you have the opportunity and the responsibility to bridge the gaps between teams, functions, and layers of the org.
Remind your team that we all belong to something bigger. Create opportunities to connect. Bring visibility, empathy, and transparency to your work.
Because when "us" starts meaning "all of us", then everyone wins.