When Feedback Becomes Gatekeeping: Rethinking How We Collaborate in Engineering Teams
Ahmed
Over the years, I’ve worked at different types of software companies—some local, some remote, some tech-heavy, and some more product-driven. And while I’ve encountered my share of challenges—tight deadlines, rushed releases, underinvested architecture—I’ve recently found myself reflecting on a different kind of issue.
Not the kind of problem that’s easy to name. In fact, what I’ve been noticing might not even be seen as a problem by many.
But what if some of the ways we work—especially in mature, technically sophisticated environments—aren’t as healthy as we think they are? What if the processes we lean on are quietly discouraging collaboration or stunting growth?
This post is a reflection—but also a set of open questions. I’m not claiming universal truths. I’m sharing what I’ve seen, what I’ve felt, and what I’m wondering if others have too.
When Collaboration Becomes a Transaction
We have a practice of writing RFCs—documents that outline a proposed architectural or technical approach. In theory, it’s a great opportunity to share designs and get thoughtful input from others across the organization, especially more experienced engineers.
But what was once a collaborative ritual has started to feel like submitting paperwork to a government office. You write the RFC, you wait, and instead of constructive feedback or open-minded discussion, you’re often met with strong opinions, sharp judgment, and little interest in improving the idea together.
Some engineers—especially those in senior roles—seem more focused on pointing out flaws than on working toward better outcomes. Instead of helping others grow or shaping the architecture as a team, the process can feel like a gatekeeping exercise.
Territories, Not Teams
Another pattern I’ve been reflecting on is how teams relate to code ownership. There’s often an unspoken sense of territorialism—certain repositories are seen as “owned” by specific teams, and contributing to them can feel like crossing a line.
This isn’t about being protective of code quality—that’s important. But when contributing outside your team feels discouraged by default, it signals a deeper issue. Repositories start to feel like exclusive domains rather than shared company assets. And that slowly chips away at the spirit of cross-team collaboration.
I’m Not Against Process—But This Isn’t It
Let me be clear: I’m not against RFCs. I’m not against code reviews. I’m not against engineers with experience having strong opinions and sharing them.
In fact, I believe these things are essential. That’s how we build resilient systems and grow together as a team.
But the way we do them matters.
Feedback should be about making the work better—not proving a point. Reviews should help refine and improve—not discourage or exclude. And if we’ve created a system where people feel they’re just trying to get approval instead of solving problems together, then something’s off.
What We’re Missing
The biggest loss in all of this is growth.
When senior engineers use process to defend rather than mentor, junior and mid-level engineers stop growing. When code ownership turns into gatekeeping, we lose opportunities to collaborate. And when feedback becomes something people dread, we risk silencing diverse ideas that could have made the work better.
A Call to Rethink
Culture doesn’t fail all at once. It erodes quietly—through habits we don’t question and behaviors we excuse.
If we care about building great software, we need to care just as much about how we treat each other while building it. That means designing a culture as intentionally as we design our systems.
Collaboration isn’t a checkbox. Growth isn’t automatic. We have to create the conditions for both—or we risk losing them without realizing it.