Why Assertiveness Should Be the Default for Engineering, Product, and Design Leaders

I am a more demanding leader than I am a patient one. Competitive, opinionated, fast to a conclusion. The first time someone on my team told me that a sentence I had said in a sprint review made them stop contributing for the rest of the meeting, I didn't argue. I just sat with it for a long time afterward, replaying the moment.

The thing I had said wasn't wrong. It was an observation that turned into an evaluation in the same breath, delivered in the tone I use when I am sure. The person on the other end of it heard the tone and not the observation. By the time I noticed, three or four other people in the room had quietly shifted into the same posture: heads down, opinions pocketed, waiting for the meeting to be over.

The thing I have been working on for years since is not less assertion. The assertion was the right instinct. What needed to change was the speed with which I climbed from what I saw to what I concluded — and the gap between what I needed and what I was demanding.

TLDR

• Assertiveness has a curvilinear relationship with leadership effectiveness — too little fails on goals, too much fails on relationships, and the middle is the only place leaders score well on both (Ames & Flynn, JPSP, 2007)
• Decision effectiveness correlates with financial performance at 95% confidence; the best decision-making companies return 4x more to shareholders and grow profits 5.5x faster than peers (Bain & Company, 2010)
• 61% of executives say at least half their decision time is wasted, and only 37% say their org's decisions are timely and high quality (McKinsey, 2019)
• The Ladder of Inference (Argyris) and Nonviolent Communication (Rosenberg) are the two frameworks that let demanding leaders stay decisive without crossing into demand

Why is assertiveness the right default for engineering, product, and design?

A landmark study by Daniel Ames and Francis Flynn analyzed nearly 1,000 coworker comments on colleagues' leadership and found that "assertive" was the most-cited word in weakness descriptions — appearing roughly twice as often as runners-up — with 48% of those weakness comments naming too much assertiveness and the rest naming too little (APA / Ames & Flynn JPSP, 2007). The shape of leadership effectiveness against assertiveness is an inverted U. The middle is the only place leaders score well on both goals and relationships.

That curve is the case for assertiveness as a default. It is also the case for paying attention to where on the curve you actually live.

Most working definitions go like this. Passive leaders defer their judgment, which protects relationships at the expense of outcomes. Aggressive leaders impose their judgment, which protects outcomes at the expense of relationships. Assertive leaders state their judgment and invite challenge, which is the only posture that holds both at once. The first two have failure modes you can see coming from a mile away. The third has a failure mode that hides — assertive leaders drift into aggressive territory under pressure and rarely notice the moment it happens.

The cross-functional cost of leaning passive is brutal. Product managers who don't push back ship the wrong feature. Engineers who don't push back implement the wrong architecture. Designers who don't push back render the wrong screen. Each of those people was hired for their judgment, and passive collaboration is a tax on the people you hired for it.

The thing I have come to believe is that in cross-functional work, each role's expertise is wasted when its owner isn't assertive about it. A product manager who has watched fifty customer interviews and yields to a louder engineer's opinion about what users want has thrown away exactly the thing they were brought in to provide. A senior designer who lets a PM redraw the flow on a whiteboard without saying "this breaks the affordance pattern we just learned in usability testing" is doing the same. The fix isn't more deference. It's more directness, calibrated to the room.

How does the Ladder of Inference trip up cross-functional teams?

Chris Argyris's Ladder of Inference describes how we climb from observable data to action in milliseconds, often without noticing the rungs in between (Argyris, Overcoming Organizational Defenses, 1990; popularized in Senge, The Fifth Discipline, 1990). At the bottom is observable data — the actual words, code, screens, metrics, behaviors. Then we select a slice of it. Then we add meaning. Then we make assumptions. Then we draw conclusions, adopt beliefs, and take action. The climb feels like one step. It's seven.

The classic failure mode in a cross-functional team is a fast climb on thin data. A PM sees one frustrated message in Slack from one engineer, selects that message as the signal, decides it means engineering is "blocking" the launch, concludes the org is misaligned, and walks into the staff meeting with that frame. The conclusion may be right. It also may be three rungs of inference stacked on a single Slack message that, in context, was just somebody having a bad afternoon.

The thing nobody tells assertive leaders is that we climb the ladder faster than passive leaders do. The same trait that makes us decisive makes us prone to acting on the third rung as if we were standing on the first. Passive leaders linger at observation. Aggressive leaders skip observation entirely. Assertive leaders are the dangerous middle — we observe just enough to feel grounded, then climb seven rungs in two seconds and act with conviction. Awareness of the climb is the price of admission for staying in the assertive band on the curve above.

The biases that fuel the climb show up differently in each function. Engineers tend to anchor on the first estimate — software developers in controlled experiments produce estimates strongly biased by an arbitrary anchor even when warned about anchoring beforehand (Aranda & Easterbrook, 2005). They also test confirmatorily; an empirical study found that confirmation bias in developer testing correlates with higher software defect density (Calikli & Bener, Software Quality Journal, 2013). Sunk-cost fallacy and the planning fallacy keep half-built systems alive past their expiration date.

Product managers anchor on the first estimate they hear from anyone in the room. They privilege the loudest user (availability heuristic) over the quieter median user. They defer to the highest-paid person's opinion (HiPPO bias) when the data is ambiguous. They count the customers who renewed and forget the ones who churned silently (survivorship bias).

Designers love what they made. The IKEA effect is the classic demonstration: subjects in Norton, Mochon and Ariely's experiments paid 63% more for items they had partially built themselves than for identical pre-assembled equivalents — labor alone is enough to induce attachment (Norton, Mochon & Ariely, HBS, 2011). Designers also suffer from the curse of knowledge — they cannot un-see the system the way a new user sees it — and from aesthetic-usability bias, where a beautiful interface is rated more usable even when it is provably less so.

When I sit in a room with all three functions, I am no longer trying to identify "the bias in the room." I am trying to identify which ladder we are each climbing right now and slowing my own climb visibly enough that other people slow theirs.

What's the difference between a request and a demand?

Marshall Rosenberg's Nonviolent Communication framework draws a sharp line between the two: a request invites a "no" and survives one; a demand punishes a "no" by name or by tone (Rosenberg, Nonviolent Communication: A Language of Life, 3rd ed., 2015). Most leaders who think they are making requests are actually making demands. The test is simple — what happens, in your team, when somebody declines?

The five steps of an actual request, as PuddleDancer Press lays them out in the canonical 4-part NVC diagram, look like this:

1. Connect with the need first. Before you ask, name what you actually need. Not the strategy you have in mind for getting it.
2. Ask for the moon. Be playful and clear about the ideal, not the compromise. Compromise is a thing that happens after the conversation, not before it.
3. Make it measurable. A clear, doable action — "code review by EOD Thursday" — not a vague desire like "more rigor on the team."
4. Phrase it in the positive. "Can you do this?" beats "please stop doing that." The brain processes the positive form faster, and it leaves the receiver with a path forward.
5. Be willing to hear no. If you cannot accept "no" gracefully, what you have is a demand wearing a request costume.

The thing I had to learn — slowly, painfully, over a number of years — is that step five is not a courtesy. It is the load-bearing step. The other four are technique. Step five is the entire framework.

I had a deadline conversation with a senior engineer once where I'd been asking — repeatedly, with increasing intensity — for a milestone to land by a particular Friday. Each ask sounded like a request. Each was technically phrased in the positive. None of them were measurable in the way step three actually means. And when the engineer finally said "I don't think Friday is possible, here's why" — the right answer for them to give — I noticed I was frustrated by their answer. That frustration was the tell. I was not making a request. I was making a demand and calling it a request because the words were polite. We rebuilt the conversation around the actual need (a customer commitment that didn't, on inspection, require Friday at all) and landed on a date neither of us had been considering. The engineer kept their integrity. The customer got served. I stopped pretending I had been asking.

Most "demanding leaders" aren't actually demanding behavior change. We are demanding strategy compliance. NVC's split between needs and strategies — needs are universal, strategies are negotiable — is exactly the calibration tool a demanding leader needs. Be assertive about the need. Hold the strategy loose. The engineer's strategy and mine were different. The need underneath was the same.

How do you separate observation from evaluation in technical reviews?

Rosenberg's first stage — observation, not evaluation — is where most engineering and product leadership goes sideways (Rosenberg, NVC: A Language of Life, 2015). The two look almost identical from the inside. They are completely different from the receiving end. "This PR has 1,200 lines and 3 tests" is an observation. "This PR is sloppy" is an evaluation. The first invites a conversation. The second invites a defense. The Indian philosopher Krishnamurti called observing without evaluating "the highest form of human intelligence." Most of us, in standups and design reviews, do not reach it.

The rest of NVC's stages map cleanly onto leadership stances most engineering leaders never make explicit:

• Feelings are rare in technical contexts but matter. "I'm worried we're shipping risk" is more useful than pretending the worry is data. Worry is data — it's just data about the leader's nervous system, not the codebase. Naming it lets the team respond to the actual signal.
• Needs, separated from strategy, are the move that opens the conversation. "I need confidence we won't regress production this week" is a need. "You must add 90% test coverage by Friday" is a strategy. The strategy is one of dozens of possible answers to the need. Lead with the need, hold the strategy loose, and let the engineer surface a better strategy than yours half the time.
• Requests, not demands, close the loop — and "request" means what section above means.

The three modes — Self Connection, Honest Expression, Listening Empathically — wrap all four stages and map onto leadership stances most of us never make explicit. Self-connection is what you do for thirty seconds before a tough 1:1, before walking into a roadmap meeting, before responding to the Slack message that landed wrong. Honest expression is what you bring into the room. Listening empathically is what you do when someone disagrees with you, especially when you are sure they are wrong. The order matters. Self-connection first, expression second, listening when challenged. Most of the leadership failures I have logged came from doing the second one without the first or skipping the third when challenged.

What does psychological safety have to do with assertiveness?

Amy Edmondson's foundational 1999 study established that psychological safety predicts learning behavior, which predicts team performance — across 51 work teams in a manufacturing company, the chain held (Edmondson, Administrative Science Quarterly, 1999). Google's Project Aristotle later confirmed psychological safety as the single largest predictor of team effectiveness across 180 internal teams (Google re:Work / Project Aristotle, 2016). And yet only about a quarter of leaders consistently exhibit the behaviors that produce it (McKinsey, 2021).

The misread of this research is that psychological safety means being nice. It does not. Edmondson's work explicitly defines it as a climate where people can take interpersonal risks — including disagreement, dissent, and admission of error — without fear of being punished or humiliated. Psychological safety is a precondition for more candor, not less. Teams with high psychological safety argue more, not less. Assertive leaders create it; aggressive leaders destroy it; passive leaders fail to provide enough disagreement for the team to know it is safe to disagree.

The practical move here is the one that ties this whole post together. The reason to separate observation from evaluation is not to be polite. It is to make disagreement cheap. The reason to lead with the need rather than the strategy is not to soften your position. It is to give the team a real opening to surface a better strategy than yours. The reason to be willing to hear "no" is not to be permissive. It is so that when the answer is "yes," you actually know it is yes.

Gallup's longitudinal data from 2.5 million work units shows managers explain 70% of the variance in team engagement (Gallup, 2015). The variance is not in whether the manager is assertive or not. It is in whether the manager's assertiveness creates room for the team or replaces it. The post on listening before being heard is the companion piece to this one — that post is about creating the room; this one is about what you do once the room is open.

A field guide for the demanding leader

Translating both frameworks into daily practice, here is the short list of moves that have actually changed my behavior over the past few years:

• Name the rung. When I notice I am about to act on a conclusion, I say it out loud: "I think I'm jumping ahead — let me back up. What I actually saw was X." It feels strange the first ten times. It changes the room every time after that.
• State the observation before the evaluation. "This PR is 1,200 lines and has 3 tests" lands different than "this PR is sloppy." Both can lead to the same outcome. Only one keeps the engineer in the conversation.
• Lead with the need, hold the strategy loose. Be unapologetic about the need — production reliability, customer commitment, design integrity. Be loose about how it's met. Half the time the team's strategy is better than yours.
• Phrase requests in the positive. "Can you walk me through your test plan?" instead of "stop merging without tests." The brain handles the affirmative form faster and the receiver leaves with a path forward, not a constraint.
• Earn the right to ask for the moon. Step two of NVC — be playful and clear about the ideal — works only after the need is shared. If the team doesn't know why the moon matters, asking for it is just demanding.
• Calibrate intensity to the room, not your default. A senior engineer can hear "this is wrong" the way I mean it. A junior designer in their first month at a new company cannot. Same words, different rooms, different effects. The skill is reading the room before opening your mouth.
• Make "no" cheap. If your team can't decline a request without paying a social cost, your requests are demands. Track it: in your last week of Slack messages, how many ended in "no" from someone other than you? If the answer is zero, look at why.

The single habit that has helped me most is a thirty-second pause before the kind of meeting I know is going to be hot. Not breathing exercises. Just one minute of asking myself: what is the actual need? What ladder am I already on? What would I ask for if I were genuinely willing to hear no? Half the time I walk in with a different opening sentence than the one I would have led with. The other half, I walk in with the same one but I know why I am saying it, which changes how it lands.

Frequently Asked Questions

Isn't "assertive" just a polite word for "aggressive"?

It isn't, and the difference shows up in how each style handles disagreement. Assertive leaders state needs and invite challenge — when somebody pushes back, the conversation continues. Aggressive leaders state strategy and punish challenge — when somebody pushes back, the conversation ends and the relationship cost compounds. Ames and Flynn's curvilinear data (JPSP, 2007) measured this directly: too much assertiveness fails on relationships, and the failure is observable in coworker comments.

What if my team reads any direct feedback as harsh?

That's data about psychological safety, not about your tone — and the McKinsey finding that only 26% of leaders consistently create psychological safety means most teams have never experienced direct feedback inside a safe climate (McKinsey, 2021). The fix is structural, not stylistic. Soften the system, not the message: written-first formats, paraphrase-before-respond rituals, and visible "no" handling. The post on why your team can't listen until they've been heard covers the structural moves in detail.

Doesn't NVC slow teams down?

The framework looks slow on paper and is fast in practice. Bain found decision effectiveness correlates with financial returns at 95% confidence and 4x shareholder returns over five years (Bain & Company, 2010), and McKinsey found 61% of executives say at least half their decision time is wasted (McKinsey, 2019). The thirty seconds you spend separating observation from evaluation save the thirty minutes you would otherwise spend repairing the conversation.

How do I get senior leaders to lead this way if they don't?

You probably can't change their default in a quarter. What you can do is model the request-not-demand pattern in your own peer interactions, name the ladder when you climb it in front of them, and protect your team from the worst of the demand-style asks coming down. Senior leaders watch what their direct reports actually do far more than what they say. Be the example you wish you reported to.

Demanding Isn't a Flaw — It's a Tool

The thing I want competitive, opinionated, fast-to-conclusion leaders to take from this post is not that you should be less of yourself. The data does not support that. Passive leadership has a cost the engineering, product, and design teams I have led cannot afford. Each member of those teams was hired for their judgment, and the leader's job is to make their judgment real in the world, not to flatten it under their own.

The discipline is not to soften your default. It is to slow your climb up the ladder, to separate the need from the strategy, and to mean it when you say "no is a real answer." The frameworks above — Argyris's ladder, Rosenberg's stages — are not corporate-training fluff. They are the closest thing engineering leadership has to a debugger for the conversation in your own head. Treat them like one.

If your team has stopped pushing back, look at your last ten requests. Count the ones where "no" was a real option. If the count is low, the problem is not that your team is too quiet. The problem is that your requests have not been requests for a long time. Fix that, and the assertive default becomes the asset it should have been all along.

If you're rebuilding how your team handles direct conversation, the post on why your team can't listen until they've been heard covers the structural moves. And if you want the longer arc of how I think about cross-functional teams, the piece on engineering team learning connects this same idea to how teams actually grow.