I once spent three weeks fighting a battle I'd already won on paper.
The architecture decision was mine to make. I had the authority. I made the call: we were migrating from our monolith to a service-based approach. I sent the announcement, outlined the plan, answered questions in the all-hands.
Six weeks later, progress had stalled. Tickets sat in the backlog. Engineers were technically "working on it" but somehow never quite moving forward. When I dug into one-on-ones, I heard the same thing said different ways: "I'm not sure this is the right approach."
I hadn't asked for their input. I hadn't explained the reasoning beyond the buzzwords. I had told. I had not sold.
The Command Trap
Most tech leaders slip into command mode for reasons they'd call "efficiency." There's a project to ship. The path is clear to you. Stopping to explain feels like slowing down.
There's a subtle status signal at play too. When you explain your reasoning, you open yourself up to challenge. When you tell people what to do, you signal confidence. Authority. Control.
What you get is compliance. And compliance looks a lot like commitment... until you need someone to care.
Gallup's research shows managers account for 70% of the variance in team engagement levels. Not strategy. Not pay. Not perks. The people doing the managing. And the single biggest factor separating engaged teams from disengaged ones is whether people feel their work has purpose and meaning.
You won't create it with a directive.
Compliance Isn't Commitment
Here's the difference in practice.
Compliance gets you work done to spec, on time, without complaint. It also gets you the minimum viable effort, zero creative problem-solving, and a team stops cold the moment it hits an obstacle nobody warned them about.
Commitment gets you engineers who push back when they see a better approach. Who stay late not because you asked but because they give a damn about the outcome. Who tell you when something is going wrong instead of waiting for you to notice.
The difference starts with whether they understand why.
When people understand the goal, they fill in the gaps. They make decisions in the spirit of the objective, not the letter of the ticket. When they don't understand why, every ambiguity becomes a reason to stop and ask... or stop entirely.
What Selling the Why Looks Like
This is not a Simon Sinek presentation. You don't need a vision deck or a "north star." You need three minutes in the right conversation.
Selling the why means answering the question your engineers are asking in their heads: "Why does this matter and why now?"
In my migration example, the answer was sitting right there. We'd lost two significant deals in the previous quarter because we were unable to deliver a feature a competitor had. The root cause was our monolith. The context would have transformed the conversation. Instead of engineers debating the merits of microservices in abstract, they'd have been solving a specific, expensive problem with a clear cost.
I skipped it. I thought they trusted me to know what I was doing. They did. They didn't trust the approach enough to throw themselves at it.
There's a technique from Japanese management practice called Nemawashi (roughly "going around the roots"), where leaders prepare stakeholders individually before any major decision. You share your thinking. You hear their concerns. You tailor the explanation to what matters to each person: technical purity for the architects, shipping speed for the product team, reliability for operations.
By the time the decision is announced, nobody is surprised. They've worked through their questions. They're ready to move.
It takes longer up front. It saves weeks of stalled progress.
Three Things Worth Trying
Prepare people before you announce. Before any significant decision, talk to two or three people whose support matters most. Not to ask permission. To share your thinking and hear their version of the problem. If their framing differs from yours, either you're missing something or they are. The conversation will tell you which.
Define the goal, not the solution. Senior technical leaders who get things done develop a habit of agreeing on purpose before agreeing on approach. "To confirm: our shared goal is to reduce deployment time by 50%, not necessarily to adopt Kubernetes?" One question like this clarifies half the disagreements. People fight less about how when they agree on what success looks like.
Ask what you're missing, not whether they agree. "I'm planning to do X because of Y and Z. What am I not seeing?" is a fundamentally different question from "Any questions?" The first treats your team as a source of signal. The second treats them as an audience. One gets you real input. The other gets you silence.
This Matters More Than It Did Five Years Ago
Distributed teams have made this non-negotiable.
When your team spans three time zones and communicates async, a command without context creates blockers. Someone hits a fork in the road at 9pm their time, has no idea which path you intended, and either guesses wrong or waits until morning. Either way, you've lost time and momentum.
AI tools have added another layer. Individual contributors ship significantly faster now. The rate of decisions being made without you in the room has gone up. If your team understands why, they make better calls in your absence. If they don't, every autonomous decision is a coin flip.
You don't scale yourself by cloning your authority. You scale yourself by distributing your reasoning.
Start This Week
Pick one decision you're about to make. Before you announce it, go talk to two people whose work it affects.
Don't ask if they agree. Tell them what you're thinking and why. Then ask: "What am I not seeing?"
Watch what happens to implementation speed afterward.
Telling is faster in the moment. Selling is faster in the end.