The purpose of a good system is not to replace judgment. It is to stop wasting it.
Once we understood where the magic lived, the next question became fairly simple. What could we standardize without damaging the work?
The answer turned out to be quite a lot.
That did not mean the team immediately agreed with me. They had already told me that websites were too different to systematize. There were too many variables. Every client had different goals, customers, content, products, and technical requirements.
All of that was true.
So instead of arguing about whether the entire process could be standardized, I started asking smaller questions. What was unique about setting up the staging server? Not much. What was different about installing the basic tools we used on almost every site? Usually nothing. What was unique about asking the client for their logo files, brand standards, photography, and existing content? Again, not much.
We had been treating the entire process as custom because parts of it required judgment. That was the mistake.
Separate Judgment From Motion
The valuable part of the work was never installing a plugin. It was deciding what the website needed to accomplish.
It was understanding the customer, organizing the information, determining what belonged on the home page, designing something that represented the company well, and making dozens of judgment calls that could not be reduced to a checklist.
That was the work our clients were paying for.
The rest of it still had to happen, but it did not deserve the same amount of mental energy. The juice was not worth the squeeze. A talented designer should not have to remember the same setup steps on every project. A developer should not rebuild something from scratch when the underlying pattern already exists. A project manager should not need years of experience to remember which basic materials to request from a client.
That does not protect their craft. It burns it.
With the developers, I used an idea they already understood from object-oriented programming. You build reusable components. You identify patterns. You do not write every line of code from nothing just to prove that each project is unique.
With the designers, we talked about the reality of building in WordPress. We were not hand-designing fifty completely unrelated pages. A site might have a home page layout, a product page layout, a resource layout, and several other repeatable patterns.
The content and design decisions were unique. The underlying structure often was not.
Once we separated those two things, the conversation started to change.
Start With One Small Piece
We did not attempt to document and rebuild the entire website process in one meeting. We started small.
Let’s standardize how we set up a site. Let’s improve one landing page process. Let’s agree on the questions we ask during kickoff. Let’s document one handoff.
It was a little like the old Karate Kid movie. Wax on, wax off. One movement at a time.
The team did not always see where I was going with it. Sometimes they grumbled. Sometimes they thought I was overcomplicating things. Then the individual pieces started connecting.
We created clearer phases so an approved decision could not be casually reversed three steps later without discussing the impact on cost and schedule. We allowed design, development, and content to move in parallel when it made sense, rather than forcing every part of the project to wait in a single line. We introduced testing stages so we could isolate problems instead of discovering five different types of problems at the same time.
We also developed a shared language around the work. That mattered more than I expected. People could finally discuss the process as a whole rather than viewing only the part sitting directly in front of them.
One of the most practical changes involved copy approvals. We used to send a client an entire website, sometimes fifty pages, and ask them to review and approve all the copy. Then we wondered why it sat on their desk for weeks.
The project manager would follow up every Monday. The client would promise to get to it. Another week would pass.
Looking back, the problem was obvious. Approving fifty pages is a major project. Nobody wants to be responsible for giving one giant final approval, especially when they still have a company to run.
So we broke it into smaller pieces. Review three or four pages. Approve those. Then move to the next group.
Nothing about the copy became less thoughtful or less customized. We simply made the approval process manageable.
That one change helped projects keep moving. A lot of process improvement works that way. It is rarely a grand transformation. More often it is just noticing where work keeps stalling, then changing the size or sequence of the request.
We Were Not Turning People Into Cogs
At one point, someone objected that they did not want to become a cog in a manufacturing process.
I understood what they meant. They took pride in their work. They did not want creativity reduced to production.
But the comment also bothered me.
My father spent his career doing blue-collar work. So did my brother. There is nothing demeaning about being part of a system that produces something useful. Most businesses could not function without people doing reliable, repeatable work.
More importantly, I was not trying to turn creative people into cogs. I was trying to identify the parts of their jobs that were already mechanical.
Setting up servers is mechanical. Collecting logos is mechanical. Reminding a client for the fifth time that you need their photography is mechanical.
Pretending those tasks are art does not elevate the employee. It consumes time and energy they could be spending on the work that actually requires their talent.
The principle is similar to what Toyota became famous for: identify and remove unnecessary motion, waiting, rework, and inconsistency. Not because people do not matter, but because their time does.
The Results Were Measurable
Over time, our website schedules moved from roughly six to eight months to something closer to three or four months. That mattered financially. It improved capacity, reduced project overruns, helped clients get to market faster, and lowered the stress caused by projects that seemed to drag on forever.
But the biggest improvement was visible in the team. People were no longer repeatedly solving the same basic problems. They had clearer expectations. Handoffs improved. Fewer things fell through the cracks.
The work became easier to manage without becoming less thoughtful.
That was the outcome I had been trying to create, but getting there cost us something. It cost trust.
I was the “suit.” I was the owner asking questions about work other people understood better than I did. The developers were cautious around me. Team members sometimes heard my questions as criticism, even when I was genuinely trying to understand the process.
I was also stepping into areas that other people had owned for years, including my business partner. From their perspective, things were working. The company was producing good websites. Clients were happy. Then I arrived and started asking why everything was done a certain way.
I understand why that felt threatening.
What was hard for me was feeling they did not trust my intentions. I knew they were better designers, developers, and project managers than I would ever be, and I was not trying to prove otherwise. I just believed I could help them see the work from a different altitude, across the whole company, where one person’s work became the next person’s problem.
But good intentions do not automatically earn trust. You have to demonstrate them.
The trust eventually came back. Then, when I became involved in another area, some of it reset and I had to earn it again. I used to find that frustrating. Now I think of it as a trust tax.
Any time a leader enters someone else’s area and starts asking questions, people wonder what is really happening. Is my job at risk? Does the owner think I am doing bad work? Has a decision already been made?
You cannot talk people out of those concerns in one meeting. They have to watch what you do.
Paying that trust tax is part of leading change.
Eventually, the new way becomes normal. The team begins saying things like, “I cannot believe we used to do it that way.” They feel the difference. The work is clearer, the unnecessary stress is lower, and they have more time for the parts of the job they enjoy.
They remember the improvement as their victory.
That is fine. That is right – because it is their victory.
They did the work. They improved the process. They built the new habits and made the system usable. My role was often closer to a coach asking for extra laps. Nobody enjoys the extra laps while they are running them. Later, when they are stronger and faster, the reason becomes clearer.
There is usually a moment when someone says, “Okay, now I see what you were trying to do.”
That is enough.
Then Build the System
The same pattern is playing out with AI.
First, we do the work manually and messily enough to understand it. Then we separate the repeatable steps from the decisions that require judgment. Only after that should we automate.
Automating a bad process does not create a good process. It allows the bad process to run faster and at a greater scale.
The goal is not to remove people from the work. The goal is to remove unnecessary work from people.
That gives them more time to solve problems, make decisions, communicate with clients, and apply the experience that no tool can fully replace.
People will still be nervous about it. Every meaningful improvement changes someone’s routine, and sometimes how they see their own value. Leadership means being honest about that while continuing to move forward. A company cannot freeze in place because the current way feels familiar.
Doing the work the hard way helps you understand what matters. But once you understand it, continuing to do everything the hard way is no longer craftsmanship. It is stubbornness.
The system should protect the decisions that require judgment and strip out the repeated work around them. Done well, it takes nothing away from the creative work. It gives your best people more time and energy for it.
That is the sequence.
First, do it the hard way. Then build the system.