Prompt Engineering Taught Me How to Manage People

I managed a team of 30+ people before I ever wrote a prompt.

When I started working with AI models, evaluating pre-release versions for companies like OpenAI, Google, and Meta, something clicked. The way you get good output from an LLM is the same way you get good work from a person. The skills transfer directly. This is the foundation of personal AI agent design.

The parallel nobody talks about

Prompt engineering articles are everywhere. Management advice is everywhere. But nobody connects the two.

Think about what makes a bad prompt: vague instructions, no context, unrealistic expectations, no feedback mechanism. Now think about what makes a bad manager: vague instructions, no context, unrealistic expectations, no feedback mechanism.

It's the same list.

When I was running operations at a law firm, I had to learn management the hard way. Trial and error, reading the room, figuring out what worked with different people. When I started evaluating AI models, I realized the meta-skills were identical.

Lesson 1: Context before instructions

Here's a bad prompt: "Summarize this document."

Here's a good prompt: "You are a legal operations manager reviewing a client intake form. Summarize this document for the case team, focusing on potential conflicts of interest and missing information. Flag anything that would prevent us from taking the case."

The difference is context. The first prompt gets a generic summary. The second gets something actionable.

Now here's a bad management instruction: "Handle the client escalation."

And here's a good one: "This client has been with us for two years, they've had billing issues three times, and they're threatening to leave. I need you to call them, acknowledge the frustration, offer a 10% discount on next month, and document everything in the CRM. If they push back, loop me in."

Same principle. The quality of the output is determined by the quality of the context, not the capability of the receiver. Whether the receiver is a language model or a team member, they can only work with what you give them.

When I started training chatbots at Proto AICX in 2019, the models were primitive compared to today. But the lesson was already clear: context quality determines output quality. I wrote about what I learned evaluating AI models, and the same finding applied everywhere.

Lesson 2: Specificity beats volume

When I first started building automated systems, I threw everything at the wall. More data, more rules, more conditions. The system got slower, more confused, and less reliable.

The same thing happens with people. New managers often compensate for unclear expectations by adding more rules. More check-ins.

Bad (volume)

• "Make sure the pipeline is healthy"
• "Check on the leads regularly"
• "Keep the database clean"
• "Make the dashboard look good"

Good (specific)

• "If the error rate exceeds 5%, restart the service and log it"
• "Review new leads every Monday, score them, move qualified ones to outreach"
• "Remove duplicates weekly, validate email formats, archive stale entries"
• "Load time under 2 seconds, mobile responsive, green status indicators"

I learned this while designing training programs at SBTech, where I reduced new hire ramp-up time by 30%. The fix wasn't more training materials. It was better ones.

The same principle drove our work at Proto AICX. We improved first-contact resolution by 20% not by handling more cases, but by focusing the chatbot on the 5 issues that accounted for 35% of all tickets. Depth beat breadth.

Lesson 3: Feedback loops, not fire and forget

Bad prompt engineering: write a prompt, get output, use it. Never look at it again.

Good prompt engineering: write a prompt, get output, evaluate it, refine the prompt, test again, iterate until the output consistently matches what you need. The same pattern powers tool-calling architecture. See how it all comes together in the case studies.

Bad management: assign a task, get results, move on. Never revisit.

Good management: assign a task, check in at defined intervals, give specific feedback, adjust expectations, iterate until the person consistently delivers what the team needs.

When I built the lead qualification pipeline at the law firm, conversions went up 45%. That didn't happen because we built a perfect system on day one. It happened because we built a feedback loop.

The team that built the pipeline wasn't given a spec and told to execute. They were given a goal and a feedback cadence. Every week, we looked at the numbers together.

AI models are the same. I evaluated 13 pre-release models by running them through 100+ use cases, scoring the outputs, and feeding the patterns back. The models didn't get better by accident.

A task without a feedback loop is a hope, not a plan. This is true for AI models and for people.

Lesson 4: Know when to step back

The thing nobody tells you about prompt engineering: the best prompts are the ones you stop refining. At some point, the output is good enough, and further optimization is diminishing returns. The skill isn't making it perfect.

Management works the same way. The best managers I've worked with know when to step back. They set the context, define the boundaries, establish the feedback loop, and then they get out of the way.

At the law firm, I had a team lead who needed approval for every decision. Not because she was incompetent, but because the culture was set up that way. Every email had to be reviewed.

I changed the rules. Instead of approving everything, I defined the boundaries: "You have full authority on cases under $10K. For cases over $10K, loop me in.

Her output improved immediately. Not because I taught her anything new, but because I stopped hovering. The same way a well-prompted AI model performs better when you stop adding constraints and let it work.

One Review Pass for Prompts and Delegations

Before I send a prompt or delegate a task, I run the same review pass over the brief. The fields are identical on both sides, and writing them out catches the failure that costs the most time, which is the wrong deliverable arriving looking right.

Take a request everybody has written at some point. Figure out the lead situation. For a model, the review turns that into a role, the systems to read, the date range, an output shape with named columns, and what to do when a field is empty. For a person, the same fields appear in plain language, plus the decision the work feeds and when you need it. The review questions are shared. What does done look like? What should the receiver do when data is missing, ask or decide? What falls outside the task? How will I check the work? A brief that cannot answer those four gets rewritten before it is sent, in either job.

The failure mode hiding behind a confident done is the expensive one. A model returns a clean table with invented values in the empty columns. A person replies all set with a spreadsheet half merged. Neither is lying. Both optimized for looking finished. The defense is the same on both sides. Define the acceptance test before the work starts, something like "done means the form count matches the CRM export for that week", and make the first check cheap enough that you run it.

Scope drift is the second one. You add a sentence to the prompt and the model quietly drops an earlier instruction. You delegate a task with a surprise case inside it and the person handles it their own way, which you find out at the deadline. Neither needs constant supervision. Both need one checkpoint at the first natural boundary, like the first ten records or the first draft, where a wrong direction still costs minutes instead of a day.

What good looks like is boring. The receiver asks one clarifying question instead of guessing, and answering takes a paragraph because the brief covered the rest. You check the output against the acceptance test and it passes without a rewrite. If you find yourself rebuilding the brief at review time, the brief was the problem and the receiver was fine. That diagnosis works the same way when the receiver is a person on your team or a model behind an API.

The reverse is also true

Working with AI models also exposes your weaknesses as a manager.

If your prompts consistently get bad output, the problem isn't the model. It's your communication. If you can't articulate what you want clearly enough for a machine to understand, how clear are you being with your team?

I've caught myself writing vague prompts and realized, in the same moment, that I'd given a vague instruction to a team member that morning. The AI forced me to be specific, and that specificity bled into how I managed people.

The overlap goes both ways. Management teaches you empathy, reading context, adapting to different communication styles. Those skills make you better at prompt engineering because you understand that different models have different strengths, just like different team members have different strengths.

If you're a manager who hasn't worked with AI tools, start. It will make you a better communicator. If you're a prompt engineer who hasn't managed people, consider it.

I spent two years evaluating AI models for companies like OpenAI and Google. I spent years before that managing teams of 30+ people. The insight that keeps proving itself is simple: clear communication is the only skill that matters in both domains.

FAQ

Does prompt engineering make you a better manager?

It makes you a clearer one. Both jobs fail on vague instructions, missing context and a missing feedback loop. Practicing specificity on models forces you to say the things you used to leave implicit with people.

What should a good delegation brief include?

Context for the situation, the decision the work feeds, a definition of done, the boundary cases where the person should come back to you, and how you will check the result. The same fields make a good prompt.

How do I know when to stop refining a prompt or a process?

When the output meets the acceptance test you wrote before you started, and the misses are edge cases instead of basics. Keep a log of the misses and revisit when they repeat. Perfection past that point is procrastination with extra steps.