You Were Great at Your Job. Then You Got Promoted
You were good at your job. Really good. And the company noticed. You knew the work, and you solved problems. Nobody had to keep telling you what to…

Very few employees come to work in the morning thinking, “How badly can I screw things up today?” Most people come to work intending to do a good job.
For years, when I taught process improvement, I told people that roughly 85% of the problems we manage are process problems, and about 15% are actually people problems. The exact percentages aren’t as important as the philosophy behind them.
When something goes wrong, management has a tendency to look for the person associated with the mistake. The employee touched the product. The employee operated the machine. The employee made the decision. Therefore, the employee must be the problem. Thirty-five years in manufacturing taught me to start somewhere else.
When an employee makes a mistake, I want to know which of three situations occurred: there was no written process; there was a written process, but it was wrong, incomplete or outdated; or there was a correct written process, the employee understood it, and the employee simply didn’t follow it. Only one of those three begins as an employee problem. That distinction sounds simple, but learning it changed the way I managed people and processes.
Early in my manufacturing career, I was an assistant department manager. One day, an experienced employee made a decision that resulted in a loss — product was wasted, material was wasted, production time was lost. My department manager ripped into him. The employee had been with the company for about ten years, and the basic message was one that many experienced employees have probably heard at some point in their careers: you’ve been here long enough to know better.
At the time, I didn’t have a management theory explaining why the situation bothered me. I was young. I just knew something didn’t feel right. I knew this employee — I had worked with him for more than a year. He was experienced, and he was well liked by the people around him. I was one of those people.
So over the next couple of days, I made a point of spending a little extra time talking with him. At first, I heard, “Sorry for screwing up.” And I watched his behavior change. He became gun-shy. Decisions that previously wouldn’t have caused him much hesitation suddenly seemed different. It looked like he had begun questioning himself: maybe I did screw up, maybe there’s something wrong with the way I think, maybe my judgment isn’t as good as I thought, maybe I shouldn’t be making these decisions. He didn’t want to cost the company money again.
From management’s perspective, that might even look like success — we corrected the employee, and now he’s being more careful. Except think about what we had actually done. The company had spent roughly ten years building experience into this employee: ten years of seeing problems, understanding the equipment, learning the product, recognizing situations that a less experienced employee might miss. And with one badly handled incident, we were beginning to teach him not to use it.
Then something else happened. The self-doubt started turning into resentment. A day or two later, I heard something very different: “This is how you treat someone with ten years of experience.” Now we had another problem. And because this employee was well liked, that problem wasn’t staying with him. I started hearing conversations around other employees — “Did you hear what management did to…?”
The original production mistake involved one employee, one decision, some wasted material, some wasted product, and some lost production time. That event was over. The material was already gone. The product was already gone. The production time was already gone. But something else was growing. At the time, I didn’t call it a hidden cost — I didn’t have that terminology yet. I just knew what was happening was wrong.
The visible cost of the original mistake was easy to calculate. How much material did we lose? How much product was scrapped? How much production time did we lose? Accounting could put numbers beside those things. But where was the line item for an experienced employee who was now afraid to make decisions?
What happens the next time that employee encounters something unusual? Before this incident, he might have used his experience and made the correct decision. Now he stops. He finds a supervisor. Production waits. The supervisor stops whatever he or she is doing and gets involved in a decision the employee previously could have handled on his own. Now we’re paying two people to make a decision that one experienced employee had been perfectly capable of making — and the same thing repeats for the next decision, and the one after that.
Then there was the second cost: resentment. What happens when an employee with ten years of experience decides those ten years don’t mean anything to management? Maybe productivity changes. Maybe cooperation changes. Maybe the willingness to go beyond the minimum changes. Maybe the employee stops pointing out problems that aren’t technically his responsibility — instead of saying, “Hey, something doesn’t look right over there,” he thinks, “Not my problem.” And what happens when that employee is respected by his coworkers? The resentment spreads. Now one badly handled corrective action isn’t affecting one employee — it’s affecting culture.
None of that appears on the original waste report. The paperwork may show that management identified the problem, corrected the employee, and closed the incident. But the most expensive part of the incident may have just started.
I went back to the department manager and explained what I had been seeing and hearing. This wasn’t a bad manager — that matters to the story. When we talked through what had happened, he listened. He had handled the situation the way he had been taught to handle situations like it. Upper management expected documentation whenever product, material, or production time was wasted, and that isn’t unreasonable. If a company loses money, management should understand why.
The supervisor needs an explanation. The department manager needs an explanation for upper management. Upper management needs an explanation for the plant manager. The plant manager may need an explanation for corporate. Corporate reports results to the board. The board ultimately answers to stakeholders. At every level, somebody is asking some version of the same question: why did this cost us money instead of making us money? That’s a legitimate question. The problem is what happens when nobody in that chain expects the answer to point upward.
Responsibility naturally moves down the organization. Each level looks below itself for the explanation, and eventually there isn’t anywhere else to go. At the bottom is the employee — below the employee, you’re basically left with a bad machine or bad material. The employee is management’s eyes and hands on the production floor. He touched the product, operated the machine, made the decision. He becomes the easiest answer. But the easiest answer isn’t necessarily the correct answer.
When we went back and looked at what had happened, the more important question became: did this employee have everything he needed to make the correct decision? That led to the three questions that eventually became fundamental to how I looked at mistakes — was there a process, and if so, was it correct, complete, and current, and if it was correct, did the employee follow it?
In this situation, we had started at the end. We corrected the employee before determining whether the employee was what needed correcting. Once the department manager understood what was happening, he went back and talked with the employee, and they worked it out. But the lesson didn’t stop with that employee. Over time, the company began changing the way it looked at mistakes, and that three-part approach — no process, a bad or outdated process, or a correct process that wasn’t followed — became part of how problems were evaluated. Sometimes the answer was the employee. Sometimes it wasn’t. That’s what accountability should do. Accountability isn’t about finding someone to blame — it’s about identifying what has to change so the same problem doesn’t happen again.
There is another hidden cost that comes from handling mistakes incorrectly: we write another procedure. Something goes wrong, there isn’t a clear, pinpoint answer, and eventually somebody says, “We need a process for that.”
I’ve spent decades working with quality systems, SOP manuals, and process documentation, and I believe strongly in documented processes. But I can also tell you that a tremendous amount of what gets written into SOP and quality manuals probably shouldn’t be there. After all my years working with processes, I would estimate that as much as 30% of some manuals is wasted space — not because somebody intentionally wrote a bad procedure, but usually the opposite. Somebody was trying to prevent a problem. Good intentions became a rule.
A mistake happened once, so we created a procedure to make sure it could never happen again. Another mistake happened, so we added another step. Someone found a potential problem, so we added another approval. Someone asked how we could guarantee something would never happen again, so we added another signature. Years later, the organization has thousands of instructions, exceptions, approvals, signatures, and rules. Employees are expected to know them all. Supervisors are expected to enforce them all. QA is expected to maintain them all. Management assumes that because something has been documented, the problem has been controlled.
But every process has a cost. Every additional step takes time. Every approval requires someone’s attention. Every form has to be completed. Every SOP has to be trained. Every revision has to be communicated. Every controlled document has to be maintained. And every unnecessary rule makes the rules that actually matter a little harder to find. That’s another hidden cost of good intentions.
There is another cost buried inside those thousands of procedures: someone has to maintain them. Every SOP has an owner. It has to be reviewed. Changes have to be approved. Revisions have to be controlled. Old versions have to be removed, new versions distributed. Employees may have to be retrained, and the training has to be documented. QA may have to audit compliance.
Now compare two companies again. One has thousands of SOPs and quality procedures. The other has hundreds. The first company may need significantly more QA and administrative manpower simply to maintain its documentation system — more people reviewing documents, more people tracking revisions, more training hours, more audits, more management time, more systems to prove that everyone has read and understood all those processes.
And here’s the irony: some of that additional overhead exists to maintain procedures that never needed to be written in the first place. The organization isn’t spending that money making the product better — it’s spending the money maintaining the system it created to manage the product. That cost becomes part of the price of everything the company produces. Meanwhile, the competitor with hundreds of well-designed, necessary processes may be producing the same product with less administrative overhead. The company with the bigger quality manual may look more controlled. The company with the smaller one may actually understand process control better.
The problem gets larger as the organization gets larger. The employee answers to the supervisor. The supervisor answers to the department manager. The department manager answers to upper management. Upper management answers to the plant manager. The plant manager answers to corporate. Corporate answers to the board. The board answers to stakeholders. The stakeholder may be the only person in that entire chain who escapes the internal blame process — their wallet is affected, but everyone else has to explain why.
That can create an organization where each level begins protecting itself from the level above. Information becomes defensive. People document decisions to protect themselves. They add approvals so someone else shares responsibility. They copy more people on communications. They create forms, require signatures, hold meetings, write procedures — not necessarily because any of those things improve the product, but because the organization has taught people that when something goes wrong, somebody will be looking for someone to blame. The system begins creating processes designed to protect people from the organization instead of processes designed to help the organization perform.
And resentment isn’t limited to hourly employees. Imagine a supervisor repeatedly held responsible for results while being denied the authority necessary to change the process — resentment can grow there. Imagine a department manager repeatedly explaining failures created by a policy that only corporate can change — resentment can grow there too. Imagine a plant manager who knows a particular metric is driving the wrong behavior but is still required to report it every month. The hidden cost can exist at every level, and the larger the company, the more places there are for those costs to accumulate.
Imagine two companies manufacturing essentially the same product. One has an SOP system containing thousands of procedures. The other has hundreds. Which company has better process control? The natural reaction might be the company with thousands — they’ve documented everything. But documentation volume isn’t process control.
The better system may be the company with hundreds, because that organization understands something important: not every event deserves an SOP. A good process gives people what they need to consistently produce the intended outcome. A bad process tries to anticipate every possible human decision. There is a point where additional documentation stops reducing variation and starts creating it. Employees can’t remember thousands of rules. Supervisors can’t consistently enforce thousands of rules. QA can’t keep thousands of rules current without substantial resources.
Eventually people develop workarounds. Some procedures are followed. Some are ignored. Some are technically followed but not practically followed. Some haven’t reflected reality for years. And now management has another problem: when something goes wrong, there is almost certainly a procedure somewhere that somebody can point to. That creates the illusion that the system was correct and the employee failed. But if the system contains so much documentation that employees cannot reasonably navigate it, understand it, and apply it, then the volume of documentation has become part of the problem. More SOPs do not automatically mean more control — sometimes they simply mean more places for hidden costs to live.
This matters because manufacturing companies don’t operate in isolation. Your competitor may be selling to the same customer. They may be purchasing material from the same vendors, using similar equipment, hiring from the same labor market. Both companies have to remain competitive on price. So where does one company find an advantage? Inside the operation.
How efficiently does information move? How quickly can experienced employees make good decisions? How much time is spent creating value versus documenting, approving, waiting, and protecting? How much management time is spent solving problems versus assigning responsibility for them? How many processes exist because they improve the product, and how many exist because something happened once and somebody said, “We need a rule for that”?
Companies spend enormous amounts of money improving machine efficiency. They measure uptime, scrap, labor, throughput. They calculate material utilization down to fractions of a percent. Those things matter. But many organizations don’t measure the cost of unnecessary processes with anything close to the same discipline. A machine that wastes 5% of its material gets management’s attention. A management system that wastes 5% of everyone’s time can survive for decades. Both cost money. Only one is easy to see. That’s why hidden costs matter.
I’ve spent about 35 years of my career in manufacturing and the last 15 in the nonprofit world. The products are different. The process problems aren’t nearly as different as people might think.
If anything, good intentions can be harder to challenge in the nonprofit world, because the intention is directly connected to the mission. Everyone is trying to help, and questioning how the help is being delivered can sound like you’re questioning whether people should be helped. You’re not. You’re asking the same question I learned to ask on a manufacturing floor: is the process producing the outcome we intended?
One of the places I see hidden costs in the nonprofit world is our tendency to operate in silos. An organization encounters a need and decides it should create a program to meet that need. The intention may be completely genuine — we serve these people, these people need clothing, therefore we should have a clothing closet. It sounds logical. So the organization finds some space, puts out a call for donations, someone buys racks, someone finds bins. Staff or volunteers begin accepting clothing. Someone sorts it, organizes it, maintains it, deals with donations that can’t be used, tries to figure out what to do when there are twenty pairs of one size and none of another. None of those things may have anything to do with the organization’s core mission. But now they’re part of the operation. Good intentions created another process.
Then someone needs a medium shirt. The organization doesn’t have one — it has an extra-large. What happens? “I know you wear a medium, but this is what we have.” Think about that. The entire process may have been created because we wanted to help preserve someone’s dignity. The donor gave the clothing with good intentions. The volunteer sorted it with good intentions. The organization dedicated valuable space to the program with good intentions. The case manager is trying to help with good intentions. And at the end of that entire chain, we hand someone clothing that doesn’t fit because that’s what happens to be available. Our good intentions just damaged the very dignity we were trying to protect. That’s a hidden cost.
The clothing closet is only an example. The larger issue is the belief that every organization has to provide every service its clients may need. It doesn’t. In fact, I would argue that it shouldn’t. Organizations have limited resources — limited money, people, space, and management capacity. Every hour spent operating a program outside your core competency is an hour that isn’t being spent becoming better at the thing your organization was created to do. Every square foot dedicated to storing something another organization could provide is a square foot unavailable for your primary mission. Every dollar spent recreating infrastructure that already exists somewhere else in the community is a dollar that can’t be spent where your organization has expertise.
We keep adding. Another need appears, so we add another program. Another gap appears, so we add another service. Eventually an organization that started because it was exceptionally good at solving one problem is trying to solve twelve. The intentions are still good — the organization is just becoming average at all twelve. I would rather be known for doing one thing exceptionally well than for doing a dozen things adequately, and then find eleven organizations that are exceptionally good at the other eleven. That’s not weakness. That’s process design.
This leads to an uncomfortable question: why do we believe we have to own the solution? Sometimes there is a legitimate reason. Maybe another resource doesn’t exist. Maybe the service is so closely connected to the organization’s mission that providing it internally makes sense. Maybe the organization truly has developed the expertise and infrastructure to do it exceptionally well.
But sometimes we need to ask ourselves whether we’re building something because the community needs another version of it, or because we want to be the organization providing it. The motivation may be good intentions. It may be organizational history. It may be fear of depending on someone else. And yes, sometimes ego may be part of it. We don’t necessarily need to know the motivation to measure the result.
In manufacturing, if another department already had the equipment, people, and expertise to perform a process better and cheaper than mine, I would have had a difficult time justifying the capital investment necessary to duplicate it simply because I wanted control of it. I didn’t need to own that process — I needed access to it. There is an important difference. If another part of the company could perform that function better and at a lower cost, I could essentially make that operation a vendor to my department. Now my product line could offer more without my department having to build, staff, and maintain another operation. Corporate was happy because we could offer more services while keeping our costs down. My department could remain focused on what it did best. The other department could remain focused on what it did best. And the customer received the benefit of both. That’s not giving up control — that’s designing a better system.
Yet in the nonprofit world, duplication can sometimes be treated as growth. More programs, more services, more people served, a larger budget — all of those can look like success. But if five organizations are separately raising money, collecting clothing, finding storage, managing volunteers, and maintaining small inventories to provide essentially the same service, are we really increasing community capacity? Or are we dividing the same community resources among five duplicate systems?
Duplication doesn’t come free. Each organization needs money to operate its version. Each needs space, people, management, volunteers, systems — and each needs donors. Many of those organizations are approaching the same community for those resources. They may seek funding from the same foundations, approach the same corporations for sponsorships, recruit volunteers from the same population, ask the same individual donors for money. Then we wonder why people sometimes feel as though nonprofits are constantly asking them for money.
From the donor’s perspective, they may not see a community of specialized organizations working together. They see organization after organization asking for another donation to solve what appears to be the same problem. That perception has a hidden cost too: trust. When donors begin wondering why so many organizations need money to provide similar services, we shouldn’t automatically assume they don’t understand the nonprofit world. Maybe they’re asking a legitimate process question — why are we paying for the same infrastructure over and over again? That’s a question worth answering, because every dollar spent duplicating something that already exists is a dollar that isn’t available to create additional impact. The donor may never see the duplication. The organization may never measure it. But the community still pays for it.
This is one of the biggest lessons I carried with me from manufacturing into the nonprofit world: being a nonprofit doesn’t suspend the laws of economics. We still have limited resources. We still have labor costs, facilities costs, transportation costs, technology costs, and opportunity costs. If two organizations build separate systems to accomplish something that one shared system could accomplish, there is a cost associated with that decision. Calling both organizations nonprofits doesn’t make the duplication free. Having good intentions doesn’t make the duplication free. And serving people who genuinely need help doesn’t make the duplication free. Someone is paying for it — usually the donor, ultimately the community.
The difference is that in manufacturing, inefficiency eventually shows up in profit. In the nonprofit world, inefficiency consumes mission. Every dollar unnecessarily spent maintaining duplicate infrastructure is a dollar that cannot be spent helping someone. Every hour a case manager spends maintaining a program outside the organization’s expertise is an hour that cannot be spent doing the work that case manager was hired to do. Every square foot being used to store something that another organization could provide is space unavailable for the organization’s primary mission. Those costs don’t disappear because nobody is earning a profit. They simply show up somewhere else.
None of this is an argument against helping more people. It’s an argument for being much more deliberate about how we help them. Good intentions should make us want the best possible outcome. They shouldn’t make us believe we have to personally provide every part of that outcome.
Know what you’re good at. Build excellent processes around it. Measure them. Improve them. Become exceptionally good at what you do. Then look around your community — who is exceptionally good at the things you’re not? Partner with them. Refer to them. Use them. Share infrastructure where it makes sense. Let another organization provide that part of the solution when they can do it better and more efficiently than you can. You don’t become less valuable because someone else performs one part of the process better than you. You become more valuable because you can provide a better overall result without consuming resources unnecessarily. A community doesn’t become stronger when every organization tries to become an entire community by itself. It becomes stronger when organizations understand how they fit together.
When I think about that employee from early in my career, I realize the lesson was much bigger than I understood at the time. Everyone involved had good intentions. The employee was trying to do his job. The department manager was trying to hold someone accountable. Upper management was trying to control waste and understand why the company had lost money. Nobody woke up that morning intending to damage trust. Nobody intended to make an experienced employee afraid to use ten years of knowledge. Nobody intended to create resentment among his coworkers. Nobody intended to add another unnecessary rule to an SOP manual. Those were unintended consequences. Hidden costs.
The problem wasn’t that people didn’t care. The problem was that caring wasn’t enough. We needed a process capable of distinguishing between an employee failure and a system failure. Once we understood that, the question changed. Instead of “who made the mistake?” we could ask “what allowed the mistake to happen?” Was there a process? Was the process correct? Was the process followed?
Those questions don’t eliminate accountability — they make accountability useful. Sometimes the answer will be the employee. Sometimes it will be the supervisor. Sometimes it will be management. Sometimes it will be an outdated SOP. Sometimes it will be a process that should never have existed in the first place. And sometimes the answer may be that we’re doing something ourselves that someone else could do better.
Good intentions matter. I would much rather work with people who care than people who don’t. I would rather see a nonprofit trying to solve a problem than ignoring it. I would rather see a manager trying to prevent mistakes than accepting waste. But good intentions can’t be where the analysis stops — they have to be where it begins.
Because good intentions can create unnecessary rules. Good intentions can create bloated SOP manuals. Good intentions can create layers of approvals. Good intentions can turn experienced employees into people afraid to make decisions. Good intentions can create resentment. Good intentions can create duplicate programs. Good intentions can create organizational silos. Good intentions can waste money. And sometimes good intentions, delivered through the wrong process, can hurt the very person we intended to help.
The question isn’t whether our intentions are good. Most of the time, they probably are. The question is whether the system we’ve built around those intentions is producing the outcome we intended. That’s where the hidden cost lives.