Sometimes the work that looks inefficient is actually where the value is being discovered.
“You can’t standardize this.”
That was the immediate reaction. There were too many variables. Every client was different. Every website was different. The work was creative. It was art.
This was probably about ten years ago. I was sitting with a project manager, a designer, and a couple of developers, trying to understand whether we could create a more repeatable process for building websites. The team was not excited about the idea.
Their position was basically this: You don’t work with these clients every day. You are not the one dealing with all the decisions, technical problems, changes, approvals, and late-night troubleshooting. You do not understand how complicated this is.
There was something else underneath it too. They were worried I was going to take the part they cared about most, the magic of it, and turn it into an assembly line.
Honestly, that was not an unreasonable concern.
There are plenty of owners who step into a process they do not understand, look at the hours, and immediately start cutting things. They remove the very work that made the product valuable because they cannot easily see or measure it. The fear was that I would make the work faster, but worse.
They were not completely wrong.
The Work Started in People’s Heads
When we started building websites, there was not a clear playbook for the kind of work we were doing. Traditional advertising agencies often treated a website like one more item on a creative services list. Technical companies treated it like an IT project.
We were trying to connect digital marketing to direct response, leads, customer acquisition costs, lifetime value, and actual revenue. That is common language today. It was less common then, particularly among the small and midsized companies we served.
We were figuring it out as we went.
In the beginning, one person might carry nearly the entire project in their head. They understood the client, the strategy, the design, the code, the content, and the reasoning behind hundreds of small decisions. That person would dig deeply into the client’s business, follow paths that did not work, try different designs, rethink the structure, struggle with the messaging, and keep working until the pieces started coming together.
It was not efficient, but it was where a lot of the magic came from.
As we grew, one person became two. Two became four. We added specialists, but the expertise still lived largely inside individual people. Designers had their way of doing things. Developers had theirs. Project managers knew which questions to ask because they had learned them through experience.
Much of that knowledge had never been documented or even discussed. The work was good, but it was hard to transfer.
Some Inefficiency is The Cost of Learning
Websites could take us six to eight months to complete. We went down rabbit holes. We spent hours solving problems that would take us minutes today. We tried things that never appeared in the final product.
Looking back, some of it was clearly waste, but not all of it.
There is an important difference between waste caused by learning and waste caused by repeating a problem you already know how to solve. If your team is making the same preventable mistake for the tenth time, that is waste. Fix it. If your team is working through a problem nobody has solved before, testing different approaches and discovering what works, that is research and development.
It may look exactly the same on a time report.
That is what makes it difficult for owners. You see the hours, the margin, and the missed deadline, and your instinct is to put a process in place immediately. Sometimes that is the right response. Other times, you are trying to standardize something before you understand it.
Had we created a rigid website checklist on day one, we probably would have built average websites more efficiently. We also would have standardized our early assumptions, including the bad ones.
We needed to do the work the hard way for a while. We needed designers to struggle through layouts, developers to solve strange technical problems, and project managers to learn why clients stalled and where projects fell apart. That work allowed us to discover what really mattered.
It also helped us separate judgment from habit. There were things we did because they produced better work. There were other things we did because that was simply how one person had always done them. You cannot always tell the difference until you have enough experience.
Owners Often Systematize Too Early
I understand why owners want to eliminate mess. Mess is expensive.
You are paying for the hours. You are listening to employees explain why the project is late. You are watching the schedule slip while the client becomes impatient. The natural reaction is to tighten everything up.
But sometimes the company is still learning how the work should be done. The process has not matured because the expertise has not matured.
That does not mean you tolerate endless experimentation. It means you ask a better question: Are we learning something valuable, or are we repeating something we already know?
That is a judgment call. There is no dashboard that can make it for you.
I am going through this same process right now with AI. I am spending nights, weekends, and parts of vacations testing tools and trying to understand what they can actually do. A lot of it does not work.
Some tools look impressive for fifteen minutes and become useless once you apply them to a real business problem. Some approaches work once but cannot be repeated. Some ideas are interesting but will never be worth the effort.
That is okay. I am not trying to make the work efficient yet. I am trying to understand where the value is.
There will be a time to document it, streamline it, and build systems around it. But doing that before we understand what works would only help us repeat the wrong things faster.
Do It The Hard Way First
When a company is building something new, there has to be room for people to explore. They need time to go deeper than the immediate task, permission to try things that might not work, and enough ownership to care about the result.
That is often where the best ideas come from.
But there was another side to the way we built websites. The work was good, but it was fragile. It depended too much on individual people, projects took too long, and too much of the magic stayed trapped in people’s heads. If someone left the company, took a vacation, or simply got overloaded, the work could come to a stop.
That is not a scalable business.
The team was right that careless process could damage the work. I was also right that we could not continue doing everything the way we had always done it.
Doing it the hard way helped us understand the work. The next challenge was figuring out how to make it repeatable without making it ordinary.
That is when you build the system.