Your Team Is Too Respectful (And It’s Killing Your Product)

It was 2:47 on a Thursday, and Somchai hadn’t blinked in eleven seconds. I’d just finished walking through a proposed architecture change — something I felt strongly about, something I’d spent the weekend sketching out on my S25 Ultra with the S Pen while my wife pretended not to notice. The air conditioning hummed its usual losing battle against Bangkok humidity. Around the table, six engineers held that particular posture you learn to recognise after a decade in Asia: spines straight, eyes attentive, mouths closed. Somchai’s pen hovered over a notebook where he’d written nothing. The silence had weight.

“Any questions?” I asked. Six heads shook. “Any concerns?” Six heads shook again. I shipped the plan. Two sprints later, it failed in exactly the way Somchai would have predicted — the way he’d told Namfon over lunch the same afternoon, the way he’d typed in a DM to a colleague that evening, the way he’d told everyone except the one person who needed to hear it: me.

That moment didn’t represent a failure of intelligence or competence. It was a failure of culture. And it’s one that most psychological safety content completely misses, because most of that content was written for teams with the opposite problem.

The Wrong Framework for the Wrong Room

Here’s an uncomfortable truth about psychological safety: the concept, as popularised by Amy Edmondson and adopted by virtually every engineering organisation with a LinkedIn presence, was largely developed in Western academic contexts. The problem it was designed to solve — workplaces where people are punished, humiliated, or retaliated against for speaking up — is real and important. But it’s not the only problem.

In many engineering teams, particularly those that draw talent from high power distance cultures — and if you’re building software in Southeast Asia, you absolutely are — the issue isn’t hostility. Nobody’s being punished for speaking up. The problem is that nobody’s speaking up in the first place. Not because they’re afraid of being attacked, but because they’re being respectful.

The sociologist Geert Hofstede’s research on cultural dimensions identified “power distance” — the degree to which people in a society accept that power is distributed unequally. Countries like Thailand, India, and the Philippines score high on this index. The practical implication for engineering teams? In high power distance cultures, subordinates are less likely to challenge authority figures directly. A senior engineer’s opinion doesn’t just carry more weight — it carries a kind of gravitational force that pulls dissent into silence.

And here’s where it gets personal. I’m an opinionated person. I’ve got decades of experience in software engineering, and if I’m not sharing that experience, I’m arguably less useful. But opinion, delivered from a position of seniority, lands differently than opinion delivered from a peer. What I intended as “here’s my thinking, let’s discuss” was landing as “here’s the decision, execute accordingly.”

“Because Joel Said So”

The moment I knew we had a real problem wasn’t in a meeting room. It was in a Slack thread I wasn’t supposed to see.

Someone had asked an engineer why they’d made a particular architectural choice. The response: “Because Joel said so.”

Four words. And they should terrify any engineering leader who hears them about their own team.

There’s a lot to unpack in that sentence, and none of it is good. On the surface, it looks like deference — an acknowledgement of expertise. Dig deeper, and you’ll find something far more corrosive: an absence of ownership.

If you’re doing something because someone else told you to, who’s responsible when it fails? Not you, of course. You were just following orders. And that’s not just a convenient escape hatch — it’s a fundamental breakdown in how engineering teams need to function. Software engineering demands ownership. Every commit, every architectural choice, every trade-off is a decision that someone needs to stand behind. When “because Joel said so” becomes an acceptable justification, you haven’t built a team. You’ve built a chain of command.

Stanley Milgram’s famous obedience experiments at Yale in the 1960s demonstrated something deeply unsettling about human behaviour: when people enter what he called an “agentic state” — viewing themselves as instruments carrying out another person’s wishes — they stop seeing themselves as responsible for their actions. His research showed that when participants were reminded they bore personal responsibility for outcomes, compliance dropped dramatically. But when someone else would accept responsibility, obedience soared.

The parallels to engineering teams are uncomfortable. When an engineer implements a design “because the tech lead said so,” they’ve entered a professional version of that agentic state. They’ll execute competently — these are smart people — but they won’t challenge, they won’t improve, and they won’t catch the blind spots that the person who made the decision inevitably has. They’re not engineers anymore. They’re sophisticated typists.

The Cultural Undertow

Before you assume this is a problem unique to any specific nationality — it isn’t. But culture provides context that you can’t ignore if you’re leading diverse teams.

Some of the countries we hire from have corporate cultures where direction flows strictly from the top. Where questioning your manager isn’t a sign of critical thinking — it’s a sign of disrespect. Where the safest career strategy is to do exactly what you’re told and let someone else take the risk of being wrong.

The thing is, most of my engineers don’t actually want to work this way. They’re happy with autonomy. They thrive when given ownership. But old habits have deep roots, and when pressure ramps up or uncertainty creeps in, people default to the patterns they learned first. The meeting room fills with polite silence. The architecture gets implemented without challenge. And two sprints later, we’re debugging a failure that three people saw coming but none of them mentioned.

As Paddy Mayne — the legendary SAS co-founder — told his men before a raid: “You must ask why, because if you know why you are carrying out your mission, when things fuck up — as they inevitably will — you will know how to achieve what you set out to achieve in a different way.” He was talking about blowing up German airfields in the Sahara, but he might as well have been talking about your next sprint. If you don’t understand why you’re building something, you have no business building it. Not because you lack the skill, but because you lack the context to make the hundreds of small decisions that turn a plan into working software — and to adapt when the plan inevitably falls apart.

I had to make this explicit with my teams. I sat them down and said, plainly: never do something just because I said to. If you don’t understand why, stop. Ask. Push back. Challenge the reasoning. And if the answer you get doesn’t make sense, say so. Your work is yours. Your decisions are yours. You can’t outsource accountability to someone else’s opinion, no matter how senior they are.

Inviting the Fight

Telling people to challenge you is easy. Actually making them believe you mean it is the hard part.

I’m a naturally opinionated leader — I come to discussions with strong views formed by years of experience. That’s a feature, not a bug. An engineering leader who doesn’t have opinions isn’t leading; they’re facilitating. But strong opinions, delivered without safeguards, create an invisible hierarchy that no amount of flat org charts or open-door policies can dissolve.

So I started changing how I end sentences.

“I strongly believe we should use GraphQL for our API layer. From my experience with similar scale, REST would create more complexity. I’m happy to be proven wrong though — perhaps there are use cases I haven’t considered?”

“Based on our profiling, moving to Redis would give us the best performance gains. I’m open to other approaches — maybe you’ve seen different solutions work well in similar situations?”

“From my analysis, Kubernetes feels like overkill for our current scale and team size. I believe a simpler deployment strategy would serve us better — but I’d love to hear counterarguments.”

See the pattern? State your position clearly — don’t hide behind false neutrality. Then explicitly invite challenge. Not as a rhetorical flourish, but as a genuine request. “Prove me wrong.” “Show me data that says otherwise.” “I’m open to other opinions.”

This isn’t performative humility. It’s tactical communication. When someone senior enough to intimidate delivers an opinion, they need to also deliver permission to disagree. Every single time. Because the moment you skip it — the moment you state a strong opinion without the invitation — someone in the room files it under “directive” instead of “discussion.” And you won’t know until two sprints later, when the thing you were wrong about ships anyway.

Margaret Heffernan, in her work on organisational blindness, argues that the biggest threats organisations face aren’t hidden — they’re in plain sight, ignored because nobody feels empowered to point at them. Engineering teams are no different. The bug that takes down production, the architectural choice that paints you into a corner, the performance issue that only surfaces at scale — someone almost always saw it coming. The question is whether your culture made it safe enough and expected enough for them to say something.

The Language of Feedback

There’s another dimension to this that’s specific to engineering culture. We give and receive feedback on code, designs, and ideas constantly. It’s embedded in our workflow — pull requests, design reviews, architecture discussions. But the language we use in that feedback matters enormously, and most of us have never thought about it deliberately.

Here’s a phrase you’ve almost certainly used before: “Why don’t you…?” Hold that one in your head. Remember what it feels like to say it. Now remember what it feels like to hear it.

You’re reviewing someone’s PR, and you think they should be using a message queue instead of direct API calls. Here are three ways to say essentially the same thing:

“Why don’t you use a queue here?”

This sounds like criticism. It implies the other person missed something obvious. The subtext reads: you should have thought of this. For someone already navigating a power distance dynamic, this lands like a judgement from above. They won’t hear the suggestion — they’ll hear the disappointment.

“Did you think about using a queue here?”

Better. This sounds like curiosity. It’s more collaborative, more inquiring. It acknowledges that the other person had a thought process and you’re interested in it. The subtext reads: I’m curious about your decision-making. It opens a conversation rather than closing one.

“Can I suggest using a queue here?”

Best. This sounds like offering help. It positions your feedback as an option rather than a correction. The subtext reads: I have an idea that might help, but you’re in control. It preserves the other person’s ownership of their work while sharing expertise.

The difference between these three phrasings is subtle in text and enormous in impact. “Why don’t you” is a question that isn’t really a question. “Did you think about” is genuine inquiry. “Can I suggest” is collaborative contribution. Each one signals a different relationship between the person giving feedback and the person receiving it.

These kinds of subtle changes in your language as an engineering leader matter, regardless of how much effort you put into dismantling invisible hierarchies. There will always be people who give your opinion extra weight because you have experience, and honestly, that part is fine — it would be strange if experience counted for nothing. But when your opinion lands with that kind of gravitational pull, you need to deliver it in a way that doesn’t flatten the people around you. You need to leave room for them to push back, even against you. Especially against you. Or the CTO. Or anyone whose title makes their opinion feel like law.

Psychological Safety Isn’t What You Think It Is

Most engineering organisations have adopted some version of psychological safety as a cultural aspiration. They run workshops. They put it in their values documents. They bring it up in retros. And almost universally, they get it wrong — not because they don’t care, but because they’re solving for the wrong failure mode.

The standard psychological safety playbook is designed to make hostile environments less hostile. Stop punishing people for mistakes. Don’t shoot the messenger. Create space for vulnerability. All good advice, all necessary — and all completely insufficient for teams where the problem isn’t hostility but excessive deference.

Think about it this way: if your team is too aggressive — people talking over each other, shooting down ideas, making others feel stupid — then yes, you need more respect. You need to dial up the safety, create guardrails around how people interact, and make kindness a professional expectation.

But if your team is too respectful — people deferring to seniority, withholding concerns to avoid seeming negative, agreeing in meetings and disagreeing in DMs — then you need more directness. You need to make challenge feel normal rather than confrontational. You need to actively create discomfort with silence, because silence in your context isn’t peace. It’s suppression.

The physicist Richard Feynman, reflecting on the Challenger disaster investigation, observed that the engineers at Morton Thiokol had raised concerns about the O-ring seals in cold temperatures. Management overruled them. The engineers went quiet. Seven people died. The information existed. The expertise existed. What didn’t exist was a culture where junior engineers could override senior management’s desire to launch on schedule. Respect for the hierarchy was literally fatal.

We’re not launching rockets. But we are building systems that millions of people depend on. And every time an engineer stays quiet because they don’t want to challenge a senior colleague’s decision, we’re accepting a smaller version of the same dysfunction.

Building the Muscle

Directness isn’t a switch you flip. It’s a muscle you build. And like any muscle, it atrophies without regular exercise.

Here are the practices that have actually worked for us:

Make “why” the default response. When someone tells you they’re implementing something a certain way, ask why. Not as a challenge — as genuine curiosity. And when someone asks you why, answer completely. If you can’t articulate the reasoning behind a decision, that’s a signal that the decision needs more thought, not less questioning.

Normalise disagreement in low-stakes settings. If the first time someone disagrees with you is during a high-pressure architecture review, it’s going to feel terrifying. Create regular, low-stakes opportunities for people to practise pushing back. Design reviews, tech talks, even informal discussions about tooling preferences — these are all gyms for the directness muscle.

Use other people’s statements as justification. This is a technique I’ve found particularly effective in cultures with high power distance. Instead of asking someone to challenge the boss directly, ask them to reference research, industry practice, or another expert’s opinion. “The Martin Fowler approach suggests…” is easier to say than “I think you’re wrong.” It’s a stepping stone, not the destination — but stepping stones get people across rivers.

Stop rewarding silence. In most meetings, the person who says nothing is assumed to agree. There’s actually a principle in Russian culture — молчание — знак согласия — “silence is a sign of agreement.” In our culture, silence isn’t agreement. It’s avoidance. Flip that assumption. If someone hasn’t spoken, ask them directly — not in a put-on-the-spot way, but genuinely: “Namfon, you’ve worked on something similar before. What are we missing?” Make contribution the expectation, not the exception.

Model vulnerability from the top. Talk about your own mistakes openly. When you make a bad architectural call — and you will — dissect it publicly. Show your team that being wrong isn’t a status threat. It’s just Tuesday.

The Paradox of Strong Leadership

Here’s the thing that took me years to understand: strong opinions and invitations to challenge aren’t contradictions. They’re complementary. The strongest leaders I’ve worked with don’t hide behind consensus — they state their position clearly and then make it genuinely safe to disagree.

Weak leadership looks like either extreme. The leader who has no opinions and waits for the room to converge is abdicating responsibility. The leader who has strong opinions and doesn’t tolerate dissent is building a team of followers, not thinkers. The leader who has strong opinions and actively invites challenge is doing something much harder and much more valuable — they’re creating a culture where the best idea wins, regardless of whose mouth it came from.

As Nelson Mandela put it: “I learned that courage was not the absence of fear, but the triumph over it.” For your engineers, speaking up despite the discomfort of challenging seniority isn’t the absence of respect — it’s the highest form of it. It says: I respect you enough to tell you the truth, even when it would be easier to nod.

The Bottom Line

Your team’s silence isn’t agreement. Their nodding isn’t understanding. And their compliance isn’t commitment.

If you’re leading engineering teams — especially diverse, cross-cultural teams where people bring different relationships with authority to the table — you can’t just create a safe environment and hope people start speaking up. You have to actively, repeatedly, and sometimes uncomfortably invite dissent. You have to change the words you use, the questions you ask, and the way you respond when someone finally does tell you that your brilliant architecture is going to fall over at scale.

Psychological safety isn’t the absence of conflict. It’s the presence of trust — trust that your opinion matters, trust that disagreement won’t be punished, and trust that the team values getting it right more than making the boss feel good.

Now, if you’ll excuse me, I need to go review a PR where one of my engineers just told me my suggested approach “has some issues.” Six months ago, she would have implemented it without a word. Progress isn’t always comfortable, but it beats debugging silence two sprints from now.