I’m Not a Micromanager

/null responds to a manager who says his team does not need him looking over their shoulders: “No. But occasionally, you need to manage.”

I have heard a lot of managers describe themselves as not being micromanagers. Usually they mean it as a good thing, and most of the time I agree with what they are trying to say. I do not want someone looking over my shoulder, checking every decision, or asking for updates just so they can feel involved. I do not manage people that way either. If I trust someone to do a job, I want them to have enough room to actually do it.

What bothers me is when “I’m not a micromanager” becomes an explanation for why the manager is barely involved at all. There is a pretty wide gap between controlling everything someone does and having no idea what is happening around them. Not living in somebody’s inbox, calendar, ticket queue, or project plan does not automatically mean you have mastered the art of empowerment. Sometimes it just means you are not paying attention.

I tend to give people a lot of room, but I can only do that effectively if I know who I am giving that room to. I need to understand what someone knows, where they are strong, where they need development, and how they approach problems. I also need to know what happens when things go wrong. Someone who consistently demonstrates good judgment should not have to keep proving they can make routine decisions. At some point, continuing to hover over them stops being management and starts becoming interference.

You Have to Know When to Get Out of the Way

I have spent a lot of my career around technical people, and one of the fastest ways to frustrate a good technical person is to hire them for their expertise and then insist they do everything the way you would have done it. At that point, I am not sure why you hired them. You could have saved everyone some time and just given yourself another job.

When I work with someone, I want to understand how they think and how they approach their work. That takes time. You learn it by working through real problems together, seeing what they do when the obvious answer does not work, and finding out whether they know when they have reached the edge of what they know. They are learning the same things about me. Eventually, we have enough history that neither of us has to guess how the other person will respond every time something changes.

As that relationship develops, I should need to be involved less. If someone demonstrates that they can make sound decisions, I do not need them coming back to me every time another decision appears. If they become better than I am at something, even better. I have never understood managers who seem threatened when somebody working for them becomes the expert. Developing people who can operate without you constantly touching their work is not losing control. It is one of the things you are supposed to be doing.

I still manage this way today, although it does not always happen through a traditional reporting relationship. I work across teams where I may not be the person who signs someone’s performance review, but we still have to solve problems, make decisions, challenge each other, and figure out who needs to own what. You cannot fall back on the org chart every time you need something done in those relationships. People have to know how you operate, and you have to give them a reason to trust your judgment.

For me, being hands-off is not really a management style. It is what becomes possible once I understand the people around me and trust them to handle what they own.

Sometimes the Problem Changes

Years ago, I had an engineer who took over responsibility for our firewalls. I had originally managed that environment myself, but as my role changed, I needed to stop being the firewall guy and let her become the firewall engineer. Over time, that is exactly what happened. They became her firewalls. She knew the environment, she made the technical decisions, and I had no interest in standing over her telling her how I would write a rule.

Eventually, those firewalls reached the end of their support lifecycle and we had to replace them. She engineered the replacement. When the new equipment arrived, I handled some of the work at the data center. I traced and labeled cables, racked equipment, and got things ready so she and one of our analysts could handle the actual cutover. I was perfectly happy doing the grunt work because she owned the technical implementation. My title did not suddenly make me the best person to configure the new firewalls.

The cutover date moved a couple of times. Initially, I let it move because there was room to move it. Then we reached the actual deadline. The existing equipment was about to lose vendor support, so delaying again was no longer just a scheduling decision. The risk had changed.

The weather was not particularly good, and she was about two and a half hours from the data center on a good day. She wanted to move the cutover again. I told her no. We had an outage scheduled in twelve hours, she had twelve hours to get there, and she should drive slowly.

I did not suddenly start telling her how to replace the firewalls. That was still her job, and by then she knew that environment better than I did. We were no longer deciding how to perform a technical migration. We were deciding whether the organization was going to knowingly run unsupported security infrastructure because we moved the deadline again.

That decision was mine.

After that, I did not take the technical work back from her. There was no reason to. She still owned the firewalls. I had stepped in because the decision had moved into my part of the job, not because I suddenly needed to become involved in hers. That distinction is a big part of how I think about management.

What Do You Owe People?

Over the years, I have worked with people who needed almost no involvement from me once we established what they owned. Others needed more coaching or clearer expectations before I could give them that much room. People also change. Someone who needed a lot of help a year ago may not need much today, while someone who normally operates independently can run into a problem where having me involved actually helps.

If I manage all of those people exactly the same way because I have decided that I am a “hands-off manager,” then I am making them adapt to me instead of managing the people actually in front of me.

What I owe them equally is respect, although respect does not look the same in every situation. I can respect someone’s experience by staying out of work they clearly know how to handle. With someone who is still learning, respect may require more of my time. There are also times when someone recommends an approach I would not have chosen myself, and unless I have a good reason to override it, they need room to make that decision. Giving people ownership while quietly requiring them to make every decision exactly as I would have made it is not much of an improvement over doing the work myself.

I expect people to own their mistakes, and I would much rather have someone come to me and tell me they screwed something up than discover it from somebody else after the problem has had a few days to mature. For that to work, they need to know that bringing me a problem starts a conversation about what we do next. I still expect them to own what happened, but I am much more interested in dealing with the problem than staging a corporate production about blame.

People are going to make bad calls occasionally. So am I. Trusting someone enough to give them authority does not require pretending otherwise. Humans have been testing that particular feature for thousands of years, and the results remain mixed.

None of this gives me a formula for exactly how involved I should be. I don’t think one exists. There are days when adding myself to a problem would accomplish little beyond increasing the number of people discussing it. Other problems land squarely in my lap, whether I particularly wanted them there or not. Knowing the people and staying connected to the work gives me a decent chance of recognizing which one I am dealing with.

Occasionally, You Need to Manage

I want capable people around me, and I want them to have enough room to become more capable. If somebody becomes better than I am at part of the job, that is not a problem I need to solve. If every meaningful decision still has to come through me, however, I have not built much of a team. I have built a queue with my name on it.

Getting out of that queue does not mean disappearing. Eventually, even people who normally need very little from me are going to run into something that lands on my side of the line. When that happens, my job is not to take their work away from them. My job is to handle my part of it.

That is what gets lost when “I’m not a micromanager” becomes an entire management philosophy. I agree that your team probably does not need you looking over their shoulders.

But occasionally, you need to manage.

It Learned From You? AI, Judgment and Competence Debt

/null sits in a corporate AI presentation as a presenter says, “We're using AI to make better decisions,” and /null replies, “It learned from you.”

I have spent most of my career watching technology change how people work. Some changes were incremental. Others eliminated entire categories of work almost overnight. In nearly every case, the interesting part wasn’t the technology itself. It was what happened to the people, processes, decisions, and assumptions around it.

Artificial intelligence is no different, although the speed and reach certainly are.

I use AI regularly. I experiment with it, build workflows around it, test different models, and look for places where it can remove friction or help me approach a problem differently. I think the technology is extraordinary. Used well, it can compress hours of work into minutes, expose relationships buried in information, challenge assumptions, and give an individual access to capabilities that once required several different specialists.

That kind of leverage is difficult to ignore. It is also exactly why I think we need to understand what happens when the person using the tool begins depending on it for more than leverage.

There is a point where AI stops helping someone think and starts thinking in place of them. The transition can be surprisingly difficult to see because productivity may actually increase. More documents get produced. Analysis appears faster. Emails become more polished. Presentations acquire summaries, recommendations, and carefully organized bullet points. From the outside, it can look like capability increased because output increased.

I’m not convinced those are always the same thing.

The Problem With Output That Looks Finished

Traditional technology often tells you when something has failed. Bad code throws an error. A network path stops passing traffic. An authentication system denies access. A mechanical component starts making a noise that strongly suggests your afternoon plans have changed.

Generative AI introduced something different into everyday knowledge work: failure that can look remarkably polished.

An AI system can produce an answer that is grammatically clean, logically structured, professionally written, and functionally useless. It can misunderstand the problem while describing its misunderstanding beautifully. It can provide technically accurate information that has almost nothing to do with the decision that actually needs to be made. In some ways, that is harder to detect than an obvious failure because nothing looks broken.

Fluency and competence are not the same thing, but modern AI is good enough at the first that it can create the appearance of the second.

When I use AI in an area I understand well, I have a reference point. I can recognize when an answer doesn’t fit the environment. I can see an assumption that shouldn’t be there, notice an important dependency that has been ignored, or recognize that the answer is technically correct but operationally useless. I know enough about the subject to push back.

Sometimes that means the AI was wrong. Other times it means I was wrong, which is considerably more valuable. I can ask it to challenge my reasoning, argue another position, identify missing evidence, find weaknesses in an approach, or explain why a conclusion might fail. Then I can take those results back through my own experience and judgment.

That’s an extremely powerful working relationship because neither side of the interaction has to be treated as infallible.

The trouble starts when I don’t know enough to recognize the difference between an impressive answer and a useful one. If I lack the underlying knowledge, I have fewer ways to evaluate what comes back. The terminology may sound right, the recommendations may seem reasonable, and the structure may create confidence that the substance hasn’t earned.

That doesn’t mean people should only use AI in fields where they are already experts. That would throw away one of its greatest benefits. AI can be a remarkable learning tool precisely because it allows us to explore things outside our existing knowledge. But using AI to learn about something you don’t understand is very different from using AI to make decisions you don’t understand.

That distinction matters.

Assistance and Substitution Are Not the Same Thing

I keep coming back to two very different relationships with these tools. In one, I am asking AI to help me think. In the other, I am asking it to think for me. Both can end with a document on the screen, so the difference isn’t always obvious if we measure only the output. It becomes much clearer when we look at what happens to the person using the technology over time.

When AI helps me think, I still own the problem. I bring context into the conversation, challenge what comes back, verify important claims, and reject recommendations that don’t fit the environment. I can ask why a conclusion was reached or what assumptions would have to be true for it to work. Sometimes the process reveals that my original question was poorly framed and I need to start over.

The tool accelerates the process, but I remain responsible for understanding it.

When AI starts thinking for me, the objective changes. Understanding the problem becomes less important than obtaining an answer. That is an attractive trade because answers have suddenly become incredibly cheap, while understanding remains expensive. Understanding still requires context, experience, curiosity, skepticism, and enough humility to recognize that the first answer might not be the right one.

In a real organization, that understanding includes things that may never appear in a prompt. There are dependencies between systems, historical decisions, regulatory requirements, budget constraints, personalities, competing priorities, technical debt, institutional knowledge, and dozens of other factors that affect whether an otherwise reasonable recommendation will actually work. Anyone who has spent enough time solving problems in complex environments eventually learns that the documented system and the system that actually exists are rarely identical.

AI can help us reason through that complexity, but only if we give it enough context and retain enough judgment to evaluate what comes back. It cannot relieve us of responsibility for understanding the environment in which the decision will be made.

A Human in the Loop Isn’t Enough

We hear a lot about keeping a human in the loop when AI is involved in important decisions. That’s sensible, but I think the phrase can give us more comfort than it should. Having a human somewhere in the workflow does not guarantee that human judgment is actually being applied.

If an AI system generates a recommendation and a person accepts it without understanding the reasoning, the organization technically had a human in the loop. If someone copies an AI-generated analysis into a presentation, changes a few words, and presents it to leadership, there was human involvement. If a decision moves forward because the output sounded reasonable and nobody in the room knew enough to challenge it, there were probably several humans in the loop.

The better question is what those humans added.

The value of keeping a person involved isn’t the biological presence of a person somewhere between input and output. The value comes from context, experience, domain knowledge, skepticism, institutional memory, accountability, and judgment. Without those things, the human can become little more than an approval mechanism. We preserved human involvement while quietly removing most of the reasons we wanted it in the first place.

This becomes particularly important in leadership because decisions rarely exist in isolation. A technically reasonable recommendation can still be the wrong decision because of timing, resources, dependencies, organizational capacity, regulatory requirements, or risks that were never represented in the information given to the AI. A model can only reason from the problem and context available to it. Leadership is still responsible for understanding the problem the organization actually has.

That responsibility can’t be delegated simply because the resulting document looks convincing.

The Feedback Loop Can Run Both Ways

This is where AI becomes especially interesting to me from a systems perspective. Useful systems depend on feedback. We make a decision, observe what happens, learn from the result, and carry that information into the next decision. Over time, those individual cycles can produce something much larger than any single improvement.

Jim Collins’ flywheel concept has influenced the way I think about this. I believe strongly in building momentum through accumulated progress, both professionally and personally. Make the best decision you can with the information available, pay attention to what happens, keep what worked, correct what didn’t, and begin the next turn with more knowledge than you had before. It isn’t dramatic, but neither is most meaningful progress.

AI can make that flywheel spin much faster. I can start with something I know, use AI to examine it from several directions, discover something I missed, investigate that discovery, test the result, and finish the process knowing more than I did when I began. The next time I approach the problem, I bring that additional knowledge with me. My capability increases along with the capability of the tool.

That’s leverage.

But feedback loops don’t have a preference for improvement. They reinforce whatever the system allows them to reinforce, and the same basic mechanism can operate in the opposite direction.

Someone begins with limited knowledge of a subject and asks AI for an answer. The answer is plausible, but the person doesn’t have enough domain knowledge to evaluate it deeply, so the result is accepted. The next time, relying on AI feels natural and a little less independent analysis takes place. Fewer assumptions get challenged, less knowledge gets developed, and the tool becomes a larger part of the decision process. As dependence grows, the person’s ability to recognize weak output can decline with it.

The uncomfortable part is that the person may produce more work during this process. Reports get completed faster. Responses appear sooner. More material moves through the organization. If we are measuring output alone, the system may look like a success even while the relationship between the human and the technology is becoming less healthy.

Output can increase while independent capability decreases.

Eventually the human may be providing weaker questions, weaker context, and weaker evaluation to a system they increasingly depend upon for answers. The resulting output becomes less useful, which encourages even more reliance on the tool to explain, rewrite, expand, and repair it. Nothing in that loop guarantees that either the human or the decision is getting better.

The technology didn’t necessarily fail. The feedback loop did.

Competence Debt

Technology people understand technical debt. Sometimes we take a shortcut because delivering something today is more valuable than building the perfect solution. There is nothing inherently wrong with that decision. The problem comes when temporary compromises accumulate until yesterday’s shortcuts begin determining tomorrow’s options.

I think AI creates the possibility of something similar: competence debt.

Every useful tool allows us to exchange effort for leverage. That’s why we build tools in the first place. I have no interest in manually doing something a machine can reliably do better, faster, and cheaper simply to prove that I still can. Independence doesn’t require deliberately making life difficult, and efficiency isn’t evidence of intellectual laziness.

Outsourcing work and outsourcing understanding, however, are different transactions.

If AI creates a first draft that I then evaluate and develop, I gained leverage. If it summarizes a large amount of information so I can identify where deeper analysis is needed, I gained leverage. If it gives me alternatives I hadn’t considered or forces me to defend an assumption I had been treating as fact, I gained leverage. In each case, the technology reduces friction while I remain engaged with the substance of the work.

The trade changes when I stop understanding the work because the tool can produce something that looks like the work. At that point I am no longer simply saving effort. I am borrowing capability from the tool.

Like technical debt, competence debt may be a completely rational trade in the short term. Nobody needs to maintain every skill at expert level, and organizations have always depended on specialized tools and outside expertise. The bill arrives when we need to evaluate something the tool produced and discover that we no longer have enough independent knowledge to do it.

There is an even more difficult version of that problem. Someone who knows they don’t understand something can compensate for the gap. They can research it, find expertise, ask better questions, slow the decision down, or acknowledge the uncertainty. Someone who mistakes polished output for understanding may not realize there is a gap to compensate for.

That is a much harder risk to manage because confidence can increase at the same time competence is declining.

The Test I Care About

I don’t think the most useful measure of AI adoption is how many employees are using it or how many hours an organization believes it has saved. Those numbers can tell us something about adoption and efficiency, but they tell us very little about what is happening to the capability of the people using the technology. An organization could produce more work in less time and still be losing something important in the process.

What I want to know is whether people become better at their work after using AI for a year. I would expect someone using a powerful knowledge tool every day to develop a better understanding of the problems they solve, ask more sophisticated questions, recognize weak assumptions sooner, and become more effective at evaluating possible solutions. Their experience with AI should add to their own experience, not replace it. If that is happening, then the organization isn’t merely getting more output from the same people. It is developing people who are more capable than they were before.

That distinction matters because productivity can hide declining competence for a surprisingly long time. Someone who once spent two hours developing an analysis might produce one in twenty minutes with AI. On a dashboard, that looks fantastic. If the person can still explain the analysis, defend its assumptions, identify its limitations, and recognize when it doesn’t apply, then the organization has probably gained real leverage. The tool removed effort without removing understanding.

The picture looks very different if the person becomes increasingly unable to produce or evaluate the work without the tool. The same productivity numbers might still look impressive, but the organization has exchanged internal capability for external dependency. That may even be a reasonable trade in some circumstances. We make that trade with technology constantly. What concerns me is making it without realizing that we made it.

There is also an organizational risk hiding inside that dependency. When enough people stop understanding how an answer was developed, accountability begins to blur. A recommendation moves through a meeting because the analysis looked convincing. A strategy makes its way into a presentation because the supporting language sounded reasonable. Eventually someone asks why a particular decision was made, and the explanation becomes some variation of, “That’s what the analysis showed.”

But analysis doesn’t make decisions. People do.

The standard I would rather use is whether AI leaves the organization with more accumulated knowledge and better judgment. When the technology is unavailable, when the situation falls outside the normal pattern, or when the AI produces an answer that conflicts with experience, there still needs to be someone in the room who understands the problem well enough to recognize that something doesn’t fit.

That is where I see the real value of the flywheel. Each interaction with the technology should leave something behind in the person using it. Maybe that’s new knowledge, a better question, a corrected assumption, or a faster way to recognize a familiar pattern. Whatever it is, some of the value needs to remain with the human after the window closes.

If all of the accumulated capability remains inside the tool, we haven’t built the flywheel I want. We’ve built dependence.

It Learned From You

None of this makes me less interested in AI. It makes me more interested in using it well.

I don’t want AI to preserve the way I already think. I want it to challenge me. I want it to find the assumption I missed, expose the weakness in an argument, automate work that doesn’t require my judgment, and give me more time for the work that does. If I am wrong, I want the interaction to help me discover that. If the AI is wrong, I want to understand the subject well enough to recognize it.

Most of all, I want to leave the interaction more capable than when I entered it. That seems like a reasonable standard for any tool, particularly one powerful enough to become part of how we think and make decisions.

So when someone tells me, “We’re using AI to make better decisions,” I’m interested in much more than whether AI was involved. I want to understand the system around it. I want to know whether the people using it understand the problem, whether they can challenge the output, whether important conclusions are being verified, and whether the organization is learning from what happens after the decision is made. I also want to know what happens when experience and the machine disagree, because that moment tells us a great deal about whether we built a decision-support system or simply found a more sophisticated way to outsource judgment.

Putting a human in the loop isn’t enough. The human has to add something to the loop.


Someone in the meeting says:

“We’re using AI to make better decisions.”

The presentation promises more efficiency, better insights, faster decisions, and a stronger future. Somewhere at the table, /null is holding a coffee mug and listening.

“It learned from you?”

That’s either a compliment or a warning.

The system will tell us which.

A Bold New Direction. Again.

/null enters a corporate restructuring meeting after leadership announces a bold new direction and responds, “Again.”

Organizations love a fresh start.

“We have a bold new direction.”

Maybe.

New leaders arrive. Priorities shift. Departments merge. Reporting lines move. Someone inevitably creates a slide containing arrows pointing toward something called the future state.

Sometimes those changes are necessary.

Organizations have to adapt. Markets change. Technology changes. Strategies that once worked stop working.

But changing the organization and changing the system are not necessarily the same thing.

Move enough boxes around an organizational chart and everything looks different.

The more useful question is whether anything underneath it actually changed.

Follow What Actually Changed

Structure matters.

Reporting relationships, responsibilities, authority, staffing, and resources can all affect how an organization performs.

A poorly designed structure can create duplication, slow decisions, hide accountability, and give people responsibility without the authority to act.

Changing that structure can solve real problems.

But structure is only one part of the system.

The incentives may still be the same.

The information may still flow through the same bottlenecks.

The same decisions may still require the same approvals.

The same behaviors may still be rewarded.

The same assumptions may still drive the same decisions.

And the problem that justified the restructure may still be sitting underneath all of it.

So before being impressed by how much changed, I want to know what changed in the system.

Change Can Become a Loop

Jim Collins described two useful ideas in Good to Great: the Flywheel and the Doom Loop.

The flywheel is the one I believe in and try to build on, both at work and in my own life.

The basic idea is simple.

Progress does not have to come from one enormous breakthrough.

You make a good decision. You learn from the result. You make the next decision a little better. You keep what works. You correct what does not. Then you push again.

Each turn builds on the last.

Eventually those individual improvements begin reinforcing one another.

That applies to organizations, technology, careers, skills, finances, relationships, and just about anything else worth improving.

It is not particularly dramatic.

That is part of why I like it.

Activity creates motion. Learning creates momentum.

The Doom Loop works differently.

A problem appears.

A new direction is announced.

The organization restructures.

The restructure creates disruption of its own.

Results take longer than expected.

Confidence fades.

Another new direction arrives.

And everyone pushes a different flywheel.

The organization can be incredibly busy while accumulating very little.

Did It Work?

This is the part of organizational change that interests me most.

What happens after the announcement?

If we knew what problem justified the change, we should eventually be able to determine whether the change affected it.

  • What outcome were we trying to change?
  • What changed in the system?
  • What happened afterward?
  • What did we learn?
  • What are we keeping?

Those questions create a feedback loop.

They allow the next decision to start with what the organization learned from the previous one.

That is how the flywheel keeps turning.

Without that feedback, change can become its own justification.

The restructure proves something needed to change.

The disappointing result proves something still needs to change.

And another restructure becomes evidence that the organization is responding.

There is plenty of motion.

Whether there is momentum is another question.

Build on What You Learn

This is why the flywheel has stuck with me beyond organizational strategy.

It is how I prefer to approach work and life.

Understand where you are.

Make the best decision you can with the evidence you have.

Pay attention to what happens.

Keep what worked.

Change what did not.

Then start the next turn with more knowledge than you had before.

That does not mean never making a major change. Sometimes the evidence tells you that a major change is exactly what the system needs.

But even a major change should become part of the next turn, not erase everything that came before it.

The goal is not constant change.

The goal is accumulated progress.


Leadership announces:

“We have a bold new direction.”

The presentation explains the vision.

Transform.

Optimize.

Realign.

Future state.

Then /null finally enters the room.

“Again.”

Sometimes one word is enough to identify the pattern.

The question is not whether the organization is changing.

It is whether this turn builds on the last one, or starts the same loop all over again.