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. And once you see the pattern, you can't unsee it.
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. If anything, working with AI made me better at managing people because it forced me to articulate things I'd been doing intuitively.
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. More documentation. More meetings. None of it helps if the core instruction is vague.
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. Fewer documents, clearer instructions, specific milestones. When I redesigned our onboarding curriculum, I cut the content in half and doubled the retention.
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.
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. We tracked which leads converted and which didn't. We reviewed the data weekly. We adjusted the qualification criteria. We iterated.
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. "This filter is too aggressive, we're losing good leads. That one's too loose, we're wasting time on bad ones." The system improved because the feedback loop was built in.
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. They got better because the evaluation process created a feedback loop between the output and the input.
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
Here's 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. The skill is recognizing "good enough."
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. Every client call had to be pre-approved. She was capable of running the team independently, but the system didn't let her.
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. For anything involving a client complaint, always include me. Everything else, run with it."
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.
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. You don't ask the creative person to do the data entry, and you don't ask a creative writing model to do structured data extraction.
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. The skills you've already built are more transferable than you think.
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. Everything else is implementation detail.