Barking orders means you already trained people to wait

“How do I give direct orders without seeming like a dictator?”

If your first move is a barked order, you are usually cleaning up earlier leadership mistakes.

That line is from Jocko Willink and Dave on Extreme Ownership. The question sounds practical. Their answer is uncomfortable: if you have to bark, you already messed up.

The short answer

Barking orders is a symptom. The disease is a team (or a system) you trained to wait.

Clarify the mission and the end state. Let people own the plan. Train decisions on purpose. Back decisive calls with real support, not cover-your-ass half-suggestions. Do that, and curt direction becomes rare—reserved for redirects nobody at the edge can see yet.

The same pattern shows up when companies put agents into production. If every action needs a human bark, you did not build an agent system. You built a remote-control toy and called it autonomy.

You already made the mistakes before you raised your voice

Willink walks through the failures that force a bark:

• The mission is unclear.
• The team does not own the plan, so they cannot adapt when reality moves.
• People were never trained to decide.
• The end state is unknown, so nobody knows which direction “good” is.
• Decisive people do not trust they will be supported.
• Leaders second-guess in a way that trains silence: “I don’t know if I’d do that.”

Each of those creates the same outcome. Someone waits. Then you bark. Then waiting becomes the habit.

Unexpected redirects still happen. On a battlefield or in a production incident, someone with a wider view may need to give curt direction. Willink’s point is that this should be rare. If it is your default, look upstream.

Plan ownership is how adaptation happens without you

If you invent the plan and something changes, only you have the deeper picture. You become the bottleneck and the loudspeaker.

If the person doing the work owns the plan, they adjust when conditions change. You do not need to narrate every correction. That is decentralized command in plain language: shared intent, local control of the how.

For engineering and AI delivery, this is the difference between a runbook nobody believes and an outcome contract a team can execute. If the end state is “reduce median first-response time for these two request types without changing refund authority,” people (and systems) can choose moves inside the fence. If the end state is “use AI somehow,” every surprise becomes a status meeting.

Every interaction is training, formal or not

Willink separates three layers of training:

1. Formal training — a class on how to decide.
2. Short role-plays — a few minutes on a contingency.
3. Daily work — proposals, client questions, mission plans, reviews.

Life at work is the real curriculum. Every time you let someone make the call and back them, you train decision-making. Every time you seize the call, you train waiting.

Dave’s add-on matters as much as the team effect: you are also training yourself. Barking teaches the leader not to trust, not to practice decentralized command, and not to build the communication that makes it possible. The habit hardens on both sides of the relationship.

Half-suggestions create subordinates who ask for orders

One of the sharpest warnings in the conversation is the cover-your-ass response.

Someone proposes a move. The leader says, “I don’t know if I’d do that,” then lets them proceed anyway. No clear veto. No clear support. Just enough doubt to teach the next person to shrug and ask, “What do you want me to do, boss?”

If the idea is wrong, say what you see and why. If it is fine, say so and give the support the decision needs. Ambiguous negation without ownership is how you manufacture people who will not decide.

The agent version of this is a confidence score with no policy. The system looks decisive until someone asks who owns the exception. Then everyone waits for a bark.

What this means for teams running AI

Production AI fails in the same places human teams fail when leadership is centralized by accident.

• Mission and end state. An agent without an outcome contract will keep asking what to do, or it will invent a goal you did not want.
• Plan ownership. If only the architect understands the workflow, every edge case escalates. That is barking with a ticket queue.
• Decision training. Shadow mode, assisted mode, and bounded automation are how you train a system to act inside limits before you hand it more authority.
• Support and recovery. If operators get punished for using the fallback, they stop escalating until the outage is loud. If agents get no clear approval path for irreversible actions, they either freeze or overreach.
• Interrupt policy. Curt human direction still belongs in the design—kill switches, incident redirects, policy overrides. It should be rare and explicit, not the daily operating system.

Decentralized command is not “nobody is in charge.” It is clear intent, trained judgment, real support, and a narrow set of moments where a louder voice is allowed.

The leadership rule

Do not practice barking. Practice the conditions that make barking unnecessary.

Make the mission obvious. Make the end state visible. Let people own the plan. Train decisions in the work, not only in workshops. Support the calls you asked them to make. Save the curt order for the rare redirect they cannot see from where they stand.

And if you find yourself barking often, treat it as telemetry. The system you built—human or machine—learned to wait because you taught it to.

Source: Jocko Willink and Dave — Extreme Ownership clip. Their Leadership Academy pitch in the video is theirs; this post is about the operating idea, not a product endorsement.