Jason Schaller

I’m Not a Micromanager

by
/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.

He’s Buffering: When AI Stops Assisting and Starts Thinking for You

by
A /null comic about AI decision-making showing an executive waiting for AI to generate a response before answering a colleague.

There is a new kind of pause showing up in meetings. Someone asks a question that requires a recommendation, an opinion, or maybe just a little judgment, and instead of getting an answer, everyone waits. It is not necessarily the normal pause of someone considering the problem. The person who was asked the question may be looking at a screen while a meeting transcript catches up, an AI tool processes what was said, and a response begins taking shape. Eventually, the person speaks. The whole process may only take a few seconds, but once you recognize what is happening, the pause becomes difficult not to notice. He’s buffering.

In the last article, I came back to one of the oldest principles in computing: garbage in, garbage out. AI may be far more sophisticated than the systems that gave us GIGO, but the basic problem never disappeared. What we put into a system still influences what comes out of it. The quality of the information, the assumptions behind the question, the context we provide, and even the way we frame the problem can influence the answer we receive. We used to worry primarily about what bad input would do to the computer. With AI, I think we also need to pay attention to what repeated dependence on the output may be doing to us.

I use AI extensively, so this is not an argument for retreating from the technology. I use it for research, analysis, testing assumptions, finding gaps, organizing information, experimenting with ideas, and automating work that does not deserve the amount of human time traditionally spent on it. Some of the systems I am building now would have required considerably more time, people, or money only a few years ago. I have no interest in giving that capability back simply because humanity immediately discovered that AI can also generate terrible emails at industrial scale. What interests me is where we draw the line between using AI to extend our ability to think and using AI so that we do not have to.

When the Tool Moves Upstream

Most AI dependence probably does not begin with someone deciding to outsource their judgment. It begins with reasonable uses of a useful tool. You ask AI to summarize a long document, organize notes from a meeting, clean up something you wrote, compare information, or help research a subject. These are exactly the kinds of tasks technology should make easier, and there is nothing inherently valuable about spending two hours doing something a tool can accomplish in ten minutes. If technology can remove mechanical work while leaving more time for analysis, experimentation, and decision-making, that seems like a pretty good trade.

The relationship changes when the tool begins moving upstream in the decision process. Instead of asking AI to organize the information, we ask it what the information means. Instead of using it to challenge a recommendation, we ask it to create the recommendation. Instead of bringing our judgment to the tool and asking it to test our thinking, we bring the problem to the tool and wait to see what we think. Each step can be perfectly reasonable on its own, which is part of what makes the transition difficult to notice. There is no warning asking whether we would like to outsource a portion of our judgment. The workflow simply becomes a little easier each time until the AI is no longer supporting the thinking. It has become part of the path the thinking must travel through.

Meetings make this particularly visible because conversation normally exposes at least part of how people think. Someone asks a question, another person considers what they know, and they respond. They may ask for clarification, offer an initial opinion, explain their reasoning, or admit that they do not have enough information to make a recommendation yet. None of those responses represents a failure. In fact, knowing when the evidence is insufficient can tell you considerably more about someone’s judgment than hearing a confident answer to every question.

Insert AI between those two people and the interaction changes. The question can be captured, interpreted, combined with other information, and turned into a polished response before the person answers. That response may be better than whatever would have come out spontaneously, and sometimes taking a moment to consult the available tools is exactly the right thing to do. The concern is not the pause itself. The concern is whether the person is consulting the tool as part of their thinking or waiting for the tool to provide the thinking. We have spent decades trying to remove latency from computers. It would be an impressive bit of human engineering if we finally got the machines fast enough only to introduce latency into ourselves.

Competence Debt

Technology has always changed which skills we exercise. Calculators reduced the amount of arithmetic we perform manually. GPS reduced the need to memorize routes. Search engines changed how we retain information because knowing where to find something became almost as valuable as remembering it. Those technologies did not eliminate the need for human knowledge, but they changed what we practiced regularly. AI extends that relationship into more interesting territory because the work being handed over can now include analysis, interpretation, and judgment.

Judgment develops through repetition. We encounter a problem, gather information, determine what matters, make assumptions, choose a course of action, observe what happens, and adjust what we know. Sometimes the decision works. Sometimes reality provides a fairly direct performance review. Both outcomes become part of the experience we bring to the next problem. Over enough repetitions, we begin recognizing patterns, asking better questions, noticing missing information, and understanding which details matter before we commit to a decision.

If AI performs more of that process for us, we should pay attention to what happens to the capability we are no longer exercising. I think of this as competence debt, and it behaves a lot like the technical debt familiar to anyone who has spent enough time around technology. Technical debt is not automatically bad. Sometimes accepting it is a rational choice because solving today’s problem matters more than building the perfect solution. The trouble comes when years of individually reasonable shortcuts accumulate into something expensive, fragile, poorly understood, and somehow critical to the operation of the business.

Competence debt can accumulate the same way. Every time we hand part of a task to a tool, we gain efficiency, but we may also stop practicing some portion of the skill required to perform that task ourselves. That trade is easy to justify when we are automating mechanical work. I have no desire to calculate a thousand-row spreadsheet by hand just to prove civilization still remembers arithmetic. The calculation changes when what we are handing over is the part that requires understanding why the numbers matter, deciding whether they can be trusted, and determining what should happen because of them.

That distinction is important because AI can increase human capability just as easily as it can replace pieces of it. If AI removes repetitive work and gives someone more time to investigate, analyze, compare alternatives, and make decisions, the technology has increased the amount of human judgment available to the organization. If AI gathers the information, performs the analysis, recommends the decision, writes the explanation, and produces the talking points used to defend it, we have created a very different workflow. The human may still be sitting in the chair, but it becomes reasonable to ask what part of the process is actually making that person better at the job.

A Better Answer Still Needs Someone Who Can Recognize It

One of the things that makes generative AI useful is also what makes dependence on it difficult to recognize. It is remarkably good at producing plausible answers. The response can be organized, articulate, appropriately formatted, and confident enough to survive several layers of an organization before anyone asks whether the underlying reasoning is sound. People have always been capable of producing bad recommendations with impressive confidence, so AI deserves no credit for inventing that particular feature. What it changes is the speed and scale at which polished reasoning can be produced.

That makes expertise more valuable, not less. When I use AI in an area I understand well, I have something against which to compare what comes back. I can recognize when the model misunderstood the problem, ignored an important constraint, relied on a questionable assumption, or produced an answer that sounds much better than it would work. I can challenge the response, add context, ask for evidence, change direction, or throw the result away. The AI is useful because it can help me cover more ground, but I do not have to trust the output simply because it arrived with bullet points and a reassuringly professional tone.

The relationship becomes more dangerous when someone does not understand the subject well enough to evaluate the answer. A polished response can be difficult to distinguish from a correct one when there is nothing in the person’s own knowledge pushing back against it. The reasoning appears coherent, the terminology sounds appropriate, and the recommendation may contain enough detail to create the impression that something substantial happened. The less judgment someone brings to that interaction, the more judgment they may unintentionally assign to the machine, and the machine has no awareness that this transfer of responsibility has occurred.

This is why I think some of the discussion about prompt engineering misses part of the problem. Better questions, better context, and better instructions can absolutely produce better results, and learning how to interact effectively with AI is becoming a useful skill. But prompting is only one side of the interaction. The harder skill is deciding whether the answer deserves to survive. That requires understanding the environment in which the recommendation will be used, recognizing assumptions, identifying missing information, considering consequences, and knowing what evidence would cause the conclusion to change. A beautifully constructed prompt cannot replace the ability to evaluate what comes back.

Using AI to Exercise Judgment

The most useful interactions I have with AI are often not the ones where I ask it what I should think. I get more value when I already have an idea, a hypothesis, or a direction and use the technology to make that thinking survive contact with something other than my own assumptions. I can ask it to identify weaknesses in an argument, find evidence I may have overlooked, make the strongest case against my position, compare alternative approaches, or identify what would have to be true for my conclusion to be wrong. That gives me more opportunities to exercise judgment rather than fewer.

There is real value in being able to challenge an idea quickly. Humans are remarkably talented at finding evidence that supports something we already believe, particularly after we have invested enough time, money, or reputation in believing it. Organizations add another layer because titles, politics, deadlines, and ownership can all influence how aggressively an idea gets challenged. AI does not eliminate those problems, but it can provide a relatively cheap way to attack an assumption before reality gets the opportunity to do it at considerably greater expense.

That only works if we are willing to use the tool that way. Asking AI to manufacture support for a decision we have already made is not analysis. It is confirmation bias with better formatting. The goal should be to come out of the interaction understanding the problem better than when we entered it, even if that means discovering that the idea we were trying to defend was wrong.

A simple test is to close the AI window and explain the recommendation to another person. You should be able to explain why you think it is the right decision, what evidence supports it, which assumptions you made, what alternatives you considered, what risks remain, and what information would cause you to change your mind. You do not need to reproduce the AI-generated response from memory because memorizing generated text proves very little. You need to understand the decision well enough that the generated response is no longer required to explain why you made it. If reopening the AI conversation is necessary to discover why you supposedly believe what you just recommended, something more fundamental than drafting assistance has been outsourced.

The Human Still Has a Job

As AI gets better, this distinction will probably become harder to see rather than easier. Models will have more context, better access to organizational information, stronger analytical capabilities, and deeper integration into the tools we already use. Their recommendations will become more useful, which means relying on them will become easier to justify. A mediocre tool constantly reminds us that it is a tool. A very good one can make us forget where its capabilities end and ours begin.

I do not think the answer is to use AI less. Avoiding a powerful technology because dependence is possible makes about as much sense as throwing away a calculator because someone might forget long division. The better approach is to become deliberate about what we are asking the technology to do and which responsibilities we are unwilling to surrender to it. AI should remove work that does not deserve human attention, help us explore more information than we could reasonably process alone, expose blind spots, challenge assumptions, accelerate research, and automate repetition. Those capabilities can make experienced people substantially more effective.

What AI should not become is the place where our judgment lives. That matters for anyone making decisions, but it matters particularly when those decisions affect other people, systems, customers, or organizations. Experience is valuable because when information is incomplete, priorities conflict, and there is no obvious correct answer, someone can still understand the situation well enough to make a decision and accept responsibility for what happens next. AI can contribute to that process, and in many cases it probably should, but responsibility does not transfer to the model simply because part of the reasoning came from it. When the recommendation fails, nobody is putting the chatbot on a performance improvement plan.

That brings me back to the pause in the meeting. Someone asks a question, the transcript catches up, the AI processes the conversation, and a few seconds later the person begins explaining a recommendation. Maybe the recommendation is excellent. Maybe the AI surfaced something nobody else considered, challenged an assumption, or provided information that produced a better decision. If the person can explain that recommendation, challenge its assumptions, adapt it when new information arrives, and make the decision when the AI has nothing useful to offer, then the technology is doing exactly what I want it to do. It is extending human judgment rather than replacing it.

The part worth watching is what happens when that is no longer true. We built AI to reduce the distance between a problem and useful information, and I think it can do that extraordinarily well. The risk is not simply that AI becomes capable of producing better answers. The more immediate risk is that we become comfortable exercising less judgment because something else can produce an answer faster. AI should make capable people more capable, expose weak assumptions, and give us more information with which to make better decisions. It should not become the place where the decision actually lives. If someone asks what you think and the answer cannot begin until the model finishes generating, the technology may no longer be assisting your judgment.

You may just be buffering.

It Learned From You? AI, Judgment and Competence Debt

by
/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.

by
/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.

We’ve Updated the Process

by
/null holding a coffee mug and phone at an airport as a boarding process is described as improved.

There is a particular kind of improvement that shows up everywhere now.

“We’ve updated the process.”

Usually there is an app involved.

Or a QR code.

Or an account you need to create.

Or a phone that now needs to be charged, connected, updated, authenticated, and available to accomplish something that previously required handing another human a piece of paper.

The new process may genuinely be better.

But there is another question worth asking.

Better for whom?

Moving Work Around

Systems do not always eliminate work when they become more efficient.

Sometimes they move it.

A task that used to be performed by an employee becomes something the customer performs.

You enter the information.

You scan the item.

You print the label.

You download the app.

You troubleshoot the account.

You navigate the menu.

You provide the device, connectivity, battery, and increasingly the technical support required to complete the transaction.

From the organization’s perspective, that can be an enormous improvement.

Less labor. Faster transactions. Better data. More automation. Lower operating costs.

Those are real benefits.

They just do not automatically mean the experience improved for everyone using the system.

Convenience Has Dependencies

A paper ticket is primitive.

It also has an interesting feature.

Once you have it, it does not need a battery.

A digital ticket can be far more convenient. It can update automatically, live inside something you already carry, and eliminate another object from your pocket.

But it also introduces dependencies.

  • The phone has to work.
  • The battery has to last.
  • The application has to function.
  • The account has to be accessible.
  • The screen has to be readable.
  • The system on the other end has to recognize it.

That does not make the digital system bad.

It makes the digital system a system.

And systems should be evaluated by their dependencies as well as their features.

Optimization Depends on Where You Stand

This is where words like better, easier, and more convenient become interesting.

They sound like descriptions.

Often they are conclusions drawn from a particular point of view.

A process can reduce staffing requirements while increasing the amount of work performed by customers.

It can reduce transaction time on average while making exceptions considerably harder to resolve.

It can make the experience easier for most users while creating a significant barrier for someone without the expected technology.

All of those things can be true at the same time.

Which is why “the new process is better” tells us surprisingly little.

Better is not a measurement until we know what was measured.

Follow the Work

Whenever a process is redesigned, I like a simpler question.

Where did the work go?

If automation actually eliminated unnecessary work, good.

If technology made something faster and easier for everyone involved, even better.

But if the work merely moved from one side of the transaction to the other, that should be part of how we describe the change.

The same applies to risk.

And cost.

And complexity.

Moving something does not make it disappear.

Someone announces:

“We’ve updated the boarding process.”

/null looks at the ticket on his phone.

“So I need to use MY phone instead of a ticket?”

Maybe the new process really is better.

Just remember to ask who got the improvement.

They Chose the Best Candidate

by
/null holding a coffee mug as a manager says, “They chose the best candidate,” and /null replies, “I’m sure they did. Again.”

There are words that sound more objective than they really are.

“They chose the best candidate.”

Maybe they did.

But that raises a more interesting question.

Best according to what?

We tend to talk about hiring and promotion decisions as though there is a single scale somewhere measuring every candidate from worst to best.

There isn’t.

There is a selection system.

That system decides what information matters, how that information is collected, which qualities are rewarded, who gets to make the decision, and ultimately what “best” means.

Best Is a Measurement

Consider two candidates for the same position.

One may understand the work better.

Another may interview better.

One may have a stronger record of solving difficult problems.

Another may have more visibility with leadership.

One may challenge assumptions.

Another may feel like the safer choice.

None of those qualities automatically makes someone the right or wrong candidate.

But they are not the same qualities.

So when an organization says it selected the best candidate, what it really knows is that it selected the candidate who performed best against whatever criteria its process actually rewarded.

Those criteria may be deliberate.

They may also be largely invisible.

The Process Creates the Outcome

A hiring process is a system.

So is a promotion process.

Like any other system, the design influences the result.

If interviews dominate the process, people who interview well gain an advantage.

If previous visibility matters, people who have worked closely with decision-makers gain an advantage.

If credentials are heavily weighted, credentials gain value.

If managers are punished heavily for a bad selection, familiarity and predictability may become more attractive than uncertainty.

Again, none of those things necessarily means the process is unfair.

It means the process has incentives.

And incentives shape outcomes whether we acknowledge them or not.

What Are We Actually Measuring?

This is where the question becomes useful beyond hiring.

Whenever a system claims to identify the best person, product, idea, or solution, it is worth asking what the system actually measured.

  • What characteristics were considered?
  • Which characteristics were ignored?
  • How was the information collected?
  • Who decided what mattered?
  • What behavior did the process reward?
  • What assumptions were built into the decision?
  • What constraints affected the available choices?

Those questions do not prove the decision was wrong.

They tell us what the decision actually means.

Then Measure the Decision

There is another part of selection systems that interests me even more.

Organizations can spend enormous amounts of time evaluating people before making a decision.

Applications.

Interviews.

Panels.

References.

Assessments.

Scoring systems.

Then the decision gets made.

What happens next is more important.

Does anyone go back and determine whether the selection process actually predicted the outcome they wanted?

If the person succeeds, what did the process correctly identify?

If the person struggles, what did the process miss?

If the same kinds of candidates keep getting selected, do they consistently produce the desired results?

Without that feedback loop, an organization can repeat the same selection process for years without knowing whether it is particularly good at selecting people.

The process becomes proof of itself.

We chose the best candidate because our process chose them.

And we know the process works because it keeps choosing the best candidates.

Someone says:

“They chose the best candidate.”

/null considers the evidence.

“I’m sure they did. Again.”

The interesting part isn’t whether he believes them.

It’s the word again.

Because repeated outcomes tell us something about a system.

The question is what.

We’re Like a Family Here.

by
/null holding a coffee mug as a coworker says, “We’re like a family here,” and /null replies, “So... nepotism or incest.”

There are phrases we hear so often that eventually we stop asking what they mean.

“We’re like a family here.”

It sounds good.

Trust. Loyalty. People looking out for one another.

Then /null takes it literally.

“So… nepotism or incest.”

And suddenly the metaphor has a problem.

What Does “Family” Actually Mean?

The interesting part isn’t whether the phrase is stupid.

The interesting part is why organizations use it.

Usually they’re trying to describe something positive. Trust. Commitment. Loyalty. Shared responsibility. People willing to help each other when things go sideways.

Those are good things.

But a workplace isn’t a family.

A family relationship exists whether it is productive or not. A working relationship exists because two sides are exchanging value.

You provide time, judgment, knowledge, and effort.

The organization provides compensation, opportunity, resources, and an environment where you can hopefully do useful work.

That doesn’t make the relationship cold.

It makes it honest.

Watch What the System Does

I’ve spent most of my career working with systems.

Technology. Security. Organizations. Processes. Teams.

One lesson transfers remarkably well between them: don’t judge a system only by what it says it does.

Watch what it actually does.

A company can call itself a family.

Then the company has a bad quarter.

Budgets get cut.

Projects disappear.

Departments get reorganized.

People get laid off.

That doesn’t automatically make the organization bad. Sometimes those decisions are necessary for the organization to survive.

But nobody announces at Thanksgiving that Grandma has been eliminated because her position no longer aligns with the family’s strategic priorities.

At least not at the better Thanksgivings.

So maybe “family” isn’t describing the system very well.

Ignore the Poster on the Wall

If you want to understand an organization, look at its incentives and behavior.

  • What behavior gets rewarded?
  • What behavior gets punished?
  • What happens when resources become scarce?
  • Who absorbs the cost when something fails?
  • What happens when someone delivers bad news?
  • Do the actions match the stated values?

A poster on the wall can say PEOPLE FIRST.

The operating system underneath it might say something completely different.

The operating system wins.

Every time.

Build the Relationship You Actually Want

None of this means people shouldn’t care about the people they work with.

They should.

Some of the strongest relationships I’ve built came from working beside people through difficult problems.

Trust gets built when someone does what they said they would do. When they tell you they screwed up before you discover it yourself. When they share what they know. When they challenge you when you’re wrong. When they show up when things go sideways.

None of that requires pretending we’re related.

Maybe the better model is simpler.

We have a job to do.

We depend on one another.

We treat people fairly.

We disagree without destroying each other.

We share credit.

We take responsibility.

And when circumstances change, we tell people the truth.

That doesn’t sound as warm as “we’re a family.”

But it describes something worth building.

Question the Abstraction

Language matters because language creates assumptions.

Once an assumption becomes familiar enough, we stop examining it.

That’s where bad abstractions survive.

Sometimes the easiest way to test one is to strip away the comfortable meaning and ask what the words actually describe.

Organizations don’t need to pretend employment is something it isn’t.

They need to build relationships people don’t have to pretend to believe in.

“We’re like a family here.”

/null: “So… nepotism or incest.”

Powered by CookieAdmin