Control Disguised as Help

Where I'm Coming From#

Three experiences have shaped how I think about leadership and management:

• Serving 10 years in the U.S. Army—finishing my tenure as a Platoon Sergeant
• Completing Harvard Business School Online's Management Essentials course
• Navigating my own neurodivergence across both military and civilian workplaces

When I say leadership and management, I don't mean the org-chart version. I mean the actual mechanics: how decisions are made and who owns them; how processes either create value or manufacture busywork; how language and tone shape psychological safety, particularly for neurodivergent people like me; and the difference between what a manager is genuinely accountable for and what they simply prefer. The list goes on.

One thing I learned from my experiences is that a lot of what gets called managing is personal preference with a title attached to it. Years later, I still see it everywhere—even with more awareness about neurodivergence and more AI tools lowering the barrier to knowledge. It shows up especially in the assumptions managers make about how people should learn, work, communicate, and use tools.

Access Isn't Competence#

I've experienced the military and civilian workplaces treat access to information, a process, or a system as if it were enough to produce competence in an individual or a team. It isn't. Competence requires context, practice, support, and, most importantly, an opportunity to apply knowledge in the work itself to start a feedback loop.

In the military, we were often expected to read technical manuals and be tested on the material daily or weekly, sometimes without an opportunity to rehearse or apply it beforehand. In civilian roles, I've seen people expected to become productive in unfamiliar systems immediately—even when they lack the access, documentation, context, and structured onboarding needed to succeed.

If this has happened to you, you already know the feeling. If it hasn't, keep reading anyway. What follows is how a difference in working style gets turned into a deficiency you supposedly need help fixing through manufactured capability gaps. That is, when someone treats a difference in working style as proof of a deficiency, then creates a process with "coaching" to fix a problem that was never actually there.

Same Tool, Different Role, Different Value#

From what I've observed, the easiest place to watch this happen is with AI. It's new enough that nobody's workflow is settled, which makes it easy to mistake different for behind. So let's talk about AI use cases.

Managers use their AI tools the way their job needs them used: status summaries, Miro boards, meeting notes, an AI template that transforms scattered week notes into something presentable to higher-ups. This is legitimate managerial work and is part of the actual deliverable.

Now think about how you use those same tools in a different role. If you're a software engineer, much of your AI use happens locally: exploring code paths, testing implementation ideas, generating edge cases, or comparing solutions against one another. You may use temp branches and unit tests to validate work, but most of it never shows up in a weekly summary—only the outcome does. If you're a recruiter, you might use AI to draft outreach, summarize interview feedback, organize candidate notes, and track active pipelines in an ATS. Most of that work is only visible in the outcome as well: a stronger pipeline, a filled role, or a clear hiring update. Although the means used to reach an outcome may not be visible, that doesn't make the work any less legitimate.

So when managers look for their AI workflow in yours, they might not find it. Instead of concluding that your jobs are different, they conclude that you're behind. Their way becomes the standard because it's the only one they know how to evaluate. They focus on whether you work like them, not on whether your role is producing the results it's supposed to produce.

Then Comes the "Help"#

This is where it stops being an opinion and starts costing you time. The gap gets named (e.g., you aren't using the system to maximize your output), and the solution shows up right behind it. Sometimes it comes in these forms:

• "Use this template"—even when the format doesn't improve the work or fit the task.

• "Send the plan to me for approval before you start"—requiring approval for decisions already approved in meetings the manager missed.

• "Show up to the knowledge session"—treating attendance as development, regardless of whether the session addresses a real gap or applies to your work.

• "Redo XYZ"—not because the result was broken or wrong, but because it doesn't match a preferred format or process.

None of that is help. It's overhead disguised as help—a way to control the team's processes rather than support the team.

The issue isn't templates, planning, tracking, or knowledge sessions themselves. Those are useful in the right environment. The problem begins when they become mandatory rituals that delay work, replace judgment, and prioritize a manager's preferences over the outcome.

Your time isn't free. You're being paid to do planned work—design validation, implementation, risk analysis, stakeholder alignment—not to absorb busywork, unnecessary coaching, and lengthy processes that don't create value. Nobody adds hours to your week to make room for you to waste time.

The Loop#

Here's the part you need to be aware of.

The added processes create delays. They create confusion about who makes the decisions. They create dependence on someone other than the people with the expertise and judgment needed to do the work. Now you can't move without sign-off from someone who can't evaluate the work at the level required.

Then those delays become the evidence that you needed the help from the get-go. For example:

• "This is why I need to stay close. You all need the extra help."

• "I'm just trying to help you all level up. You want to look good to the higher-ups."

This looks supportive. It isn't. The loop feeds itself: the process creates the delay, the delay becomes the proof, and the person who built the process gets credit for spotting a problem that wasn't a problem until they showed up. Meanwhile you look slower and less autonomous than you were before any of the helping started.

What Management Is Actually For#

A manager owns the outcome, the constraints, and the measure of success. Not the method. The method belongs to the people doing the work.

If the conversation is genuinely about adopting a tool or a process, the questions are answerable ones:

• Does this improve quality, delivery speed, documentation, reliability, or decision-making?

• Does it meet the security, privacy, legal, and compliance requirements we already have?

Those have evidence attached to them. "You don't use it the way I use it" has no evidence attached to it at all.

The Specificity Test#

So what do you do when it happens to you?

Don't argue about whether you're good with the tool. That's their frame, and you'll lose inside it because it was built to be unwinnable. Ask for specificity instead.

Ask these questions directly, and put the questions in writing when you can.

A real concern survives these four questions. Read that again. If the concern is real, everyone leaves with something concrete to fix. A manufactured concern doesn't survive these questions. It gets vague, changes shape, and turns into more busywork.

This is the same mistake from the top of this article wearing a different outfit. Handing someone a tool doesn't make them competent, and it doesn't make them deficient when they use it differently than you would. Competence comes from context, practice, and room to apply the work. So does trust.

Remember, "help" you didn't ask for, measured against a standard that doesn't fit your role, isn't help. It's control with better manners.