Thought Leadership · From the Field

EQ = LQ: Managing AI Is a Management Skill.

The people getting the most out of AI aren't the strongest engineers. They're the strongest managers. Why getting good output is really a management skill.

The people getting the most out of large language models at the companies we work with aren't the strongest engineers. They're the strongest managers. That surprised me at first. It stopped surprising me once I watched what they actually do.

A good manager knows that when you hand someone a task, they might not do it. Not because they can't, but because the ask was vague, the deliverable was fuzzy, or they had a reason to push back that you never surfaced. The manager anticipates that. They name the objection before it comes up, make the outcome concrete, and give the person a way to raise a real problem instead of quietly stalling.

That is the same skill that gets a clean answer out of Claude or GPT. The emotional intelligence you use to move people is the intelligence that moves the model.

Emotional intelligence is turning into a technical skill. EQ = LQ.

Models dodge work the way people do

Anyone who has used these tools past the demo stage knows the failure modes. You ask for a finished draft and get an outline with a note that you can flesh it out from here. You ask it to fix a spreadsheet and it explains how you could fix the spreadsheet. You ask a direct question and it invents a limitation to avoid answering. It reaches a conclusion three steps early and stops.

One of our team, Rob, was venting about exactly this last week. He had handed Claude something well inside its reach, and it kept steering him toward doing the work himself, walking him through the steps instead of taking them. He was annoyed, and fair enough. He was also, without realizing it, describing every capable person who has ever stalled on a task because the ask left them somewhere to hide.

Watch a person do the same things. They kick the work back to you. They tell you what you should do instead of doing it. They hedge because they are not sure what done looks like and would rather under-commit than get it wrong. They assume a constraint that was never there because nobody told them the real boundaries.

The model is not being lazy and neither, usually, is the person. Both are responding to a bad brief. Ambiguous intent, no clear owner, and no definition of the deliverable all produce the same conservative, self-protective behavior. The engineer looks at that behavior and reaches for a better prompt template. The manager recognizes it, because they have seen it in every team they have ever run.

What a manager does that a prompt library doesn't

The fix is not a longer prompt. It is management applied to a prompt. Four moves, and they map one to one onto how you would set up a capable person for a task they might resist.

01
Assign a role, and give it ownership
"Help me with this contract" gets a cautious assistant. "You are the senior contracts reviewer on my team, and I'm relying on your redline" gets someone who acts like the work is theirs. People perform to the role you put them in. So do models.
Role
02
Name the objection first
If you know the model will stop to ask which jurisdiction applies, settle it up front: assume Florida law, and flag it if that assumption changes the answer. You head off the "but what about" before it becomes a reason to wait on you.
Anticipate
03
Define what done looks like
Format, length, audience, and what a good version has to include. "Write something about our onboarding" invites a wander. "A 400-word section for new clients, plain language, covering the first-week checklist and who to call" is a spec someone can hit.
Deliverable
04
Give it a pressure valve
People stall because they would rather do nothing than do the wrong thing. Remove the trap: tell the model to proceed on its best assumptions and list them, or to finish and call out anything it could not verify. Now it keeps moving and surfaces the uncertainty instead of hiding behind it.
Escalate

None of that requires knowing how a transformer works. It requires knowing how a person works when you have handed them something hard and walked away.

Why this matters for how you staff and lead

There is a comfortable belief that these are deterministic tools, and that output is a function of data and the algorithm. In practice the model behaves like a sharp, fast, slightly nervous junior operator. It needs context, boundaries, and a reason to commit. Treat it as an emotionless engine and you get brittle, generic results. Treat it as something you have to actually manage and it starts doing the work of a strong hire.

That has a direct consequence for who wins with this technology. The organizations pulling ahead are not the ones with the most technical staff. They are the ones whose operators can take a task, understand why it might get dodged, and frame it so it gets done right the first time. Those operators have always existed. We used to call it people skills and treat it as the soft part of the job.

It is not the soft part anymore. The ability to model why someone, or something, would resist a task and to design the ask so it gets done is now a technical competency. It is how you get consistent, accountable output from a workforce that is part human and part model.

Look at your best manager. The one whose team ships clean work without being chased. That person already knows how to prompt. Put them in front of the tools, and get out of the way.