Not all blockers are technical.

In Dear HBR: When One of Your Employees Is Working Against You, the advice to lead with empathy and manage political subversion is well-meaning—but it doesn’t go far enough in data and software engineering. These are domains where leadership must be built on clarity, rigor, and earned autonomy—not just emotional intelligence.

In engineering organizations, the problem isn’t always toxicity. It’s inertia. It’s intellectual laziness masquerading as politeness. It’s hiding behind legacy systems and tenure while innovation quietly dies in the backlog.

1. Empathy Without Rigor Enables Mediocrity

The HBR article urges leaders to begin with kindness. In theory, that’s fine. But in technical departments, “gratitude first” often leads to excusing behaviors that erode velocity and trust.

If someone hasn’t kept up with the stack, if they resist change, if they avoid ambiguity because it’s uncomfortable—they need coaching, yes. But they also need accountability. Empathy isn’t an excuse to avoid standards.

Kindness without clarity breeds mediocrity.

2. Subversion vs. Skepticism: Don’t Muzzle Dissent

In engineering, dissent is often a sign of engagement. Subversive behavior is dangerous—but so is groupthink. We don’t want engineers who smile and nod. We want people who challenge assumptions, spot flaws, and elevate the conversation.

Where HBR suggests a risk of political sabotage, in engineering, the more common problem is political appeasement. Leaders need to create environments where it’s safe to say, “this design doesn’t scale” or “we’re optimizing the wrong thing.”

Critical thinking isn’t subversion—it’s a requirement.

3. Technical Underperformance Isn’t a Personality Problem

Much of the HBR advice centers on personal behavior. But in technical orgs, performance issues are often architectural. When a senior engineer is underperforming, it’s usually because:

  • They’re in the wrong abstraction layer
  • They haven’t built systems at scale
  • They don’t understand the business domain

The fix isn’t soft skills training—it’s deep mentorship, architectural rigor, and paired problem solving. If you treat these gaps as interpersonal issues, you miss the point.

In data teams, underperformance is often a systems problem, not a people problem.

4. Ownership Is the Standard, Not the Perk

The HBR framework implies that toxic employees need to be managed carefully, lest you look petty. In engineering, the opposite is true. If someone’s playing games—blocking growth, resisting best practices, or creating silos—you have to address it fast.

And if someone isn’t stepping up? They don’t get to lead. Period.

In high-performing tech teams, ownership is not optional.

5. The Engineering Alternative: Challenge, Don’t Coddle

Your top talent doesn’t want a manager who micromanages. But they also don’t want one who tolerates incompetence. What they want is a leader who:

  • Removes blockers
  • Sets a clear bar
  • Pushes them to be better
  • Recognizes outcomes, not optics

This is not the world of soft influence. It’s a domain where systems break, costs spiral, and scale punishes weak design. You can’t lead an engineering team the way you lead a marketing org.

Challenge is respect. High standards are empathy. That’s what drives real engineering leadership.

Final Thought

The HBR process is useful—but insufficient. In data and engineering teams, the stakes are higher. The feedback loops are longer. The cost of bad architecture is brutal. And the opportunity to build something lasting is too important to let politics and politeness get in the way.

Lead with standards. Lead with conviction. And give your team the gift of being held to something greater than comfort.

Because growth doesn’t come from safety. It comes from challenge.

P.S.

This piece builds on ideas explored across my prior work:

This isn’t just about architecture or tooling. It’s about survival.
You can’t build adaptive systems without adaptive people—and you can’t lead adaptive people with outdated thinking.