Episode 008: The Engineering Was Already There — Part A

JW Designs started with engineering long before it had an Engineering department.

That is probably obvious in hindsight. I am not reselling somebody else’s catalog of products. The things JW Designs sells exist because at some point I had a problem, an idea for solving it, and then had to figure out whether I could actually make that idea work. Before there could be inventory, production, marketing, orders, packaging, or any of the other pieces of the business, there had to be something worth building.

The lids had to be designed. The latches had to work. Frames had to fit. Materials had to be selected. Manufacturing methods had to be tested. Problems had to be solved when the first idea did not quite work the way I expected.

That work was engineering whether I called it that or not.

The funny part is that the dedicated Engineering department inside the Business OS is actually one of the younger formal parts of the system. The work itself may be the oldest continuous function in JW Designs, but for a long time it did not have a department.

I had chats.

Lots of them.

When Every Problem Is Its Own Conversation

For a long time, that was a perfectly good way to work.

I would run into a problem, open a conversation, explain what I was trying to do, work through the possibilities, get to an answer or at least a direction, and then go do something with it. Maybe I was trying to figure out a latch. Maybe I needed to understand why a piece of acrylic was sagging. Maybe I was comparing adhesives, looking at materials, changing a print orientation, or trying to make a part fit differently.

The problem was usually specific, and the conversation was specific too.

There was very little overhead. I did not need a system for deciding where the question belonged. I did not need to file anything before I could start thinking. I had a problem, so I opened ChatGPT and worked on the problem.

And it worked incredibly well.

The problem with the old chats was not that they failed to solve problems. It was that they solved them so well that eventually I had too many useful answers scattered everywhere.

That distinction matters because I do not want to rewrite the history of how I got here and pretend the earlier workflow was somehow wrong. It was exactly the right tool for the stage I was in.

The problem showed up later, after enough of those conversations had succeeded.

A technical question that looked isolated when I first asked it would eventually connect to another one. A material decision affected how a part printed. A design change affected packaging. A failure in the field might send me back into a design question that had originally been discussed months earlier. Something I learned while fixing one product could change how I thought about another.

And every new conversation could start from a blank page, but the engineering problem usually could not.

A new chat can start from a blank page. The next engineering problem usually cannot.

That meant I increasingly had to reconstruct context before I could move forward. What product was I talking about? Which version? What had already been tried? Why had I rejected one material? Which dimension was current? Was the solution I remembered the final solution, or just one of the possibilities I had discussed along the way?

The conversations were still useful. The growing cost was remembering how they connected.

Projects Helped Before the Business OS Existed

When ChatGPT Projects became available, that improved things quite a bit.

Instead of having one giant pile of unrelated conversations, I could start grouping work together. Related chats could live in the same general area. Product development could be separated from other things I was doing. Business work had a place. Learning had a place.

Projects were a meaningful step forward because they answered a question I was increasingly asking: where did I talk about this?

That was useful.

But it was not quite the same as answering a different question: what is true now?

A Project can contain an early idea, three alternatives, a failed test, a later correction, and the final version that actually went into production. All of those conversations may still be valuable. They are part of the history of how the answer developed.

But the business does not need five historically valid answers when somebody needs to know what to manufacture today.

Finding the conversation is not the same thing as knowing which answer became the answer.

That was one of the first places where the limits of simple organization started becoming visible to me.

Organizing conversations made them easier to find. It did not automatically give those conversations authority. It did not tell me whether something was still being considered, had been rejected, had been superseded, or had become the current way JW Designs actually did something.

At the time, I did not have language for all of that. I was just noticing that the information was becoming more useful and more difficult to manage at the same time.

At the Same Time, I Was Learning How to Do All of This

There was another version of the same thing happening outside the products themselves.

I use Fusion 360. I use LightBurn. I use Affinity. I use DaVinci Resolve. None of those started because I decided I wanted to become an expert in a collection of software packages. I learned them because I wanted to do something and discovered there was a gap between what I knew and what I needed to know to do it.

So I asked questions.

Sometimes they were tiny questions. How do I move this sketch? Why will this face not extrude? What setting controls this behavior? How do I make this cut? Why is this operation behaving differently than the one I did yesterday?

At first each question was just a question.

After enough questions, it became obvious that something else was happening. I was not just collecting individual answers anymore. I was building capability.

That led me to create separate e-learning Projects for things like Fusion 360, Affinity, LightBurn, and DaVinci Resolve. Those Projects are not really JW Designs departments because the skills do not belong exclusively to the business. I might learn something for JW Designs, use the same skill at my full-time job, and then use it again for something at home.

The immediate problem belongs to a context. The skill belongs to me.

A lot of the capability inside JW Designs exists because I had to teach myself something before I could build the thing I wanted.

That learning history matters because it is another example of how useful information changes as it accumulates.

One isolated answer does not necessarily need a system around it. Hundreds of answers start becoming knowledge. Repeated use turns knowledge into capability. Eventually that capability becomes part of what makes the business possible.

The same thing was happening with Engineering.

The Oldest Work Became One of the Youngest Departments

By the time the Business OS started taking shape, I had already done a huge amount of engineering work. It just was not called Engineering in any formal sense.

There were old conversations about lids, frames, materials, print settings, latch designs, acrylic, adhesives, reinforcement, tolerances, manufacturing problems, failures, and revisions. Some had clear conclusions. Some represented experiments. Some were useful only because they explained why I had decided not to do something.

As long as the technical questions were short-lived, that was manageable.

It became harder when investigations started lasting longer than a single conversation or a single day. A material could look promising but still be under evaluation. A customer failure could require an immediate operational response even though the technical cause was not fully understood yet. A prototype could work without being ready to become a production standard.

Those distinctions became important.

I could evaluate carbon-fiber-filled PETG without deciding that every future product should use it. I could investigate larger acrylic reinforcement without immediately changing every lid. I could change the print orientation of a retaining component after a failure without pretending that every idea considered during that investigation was now the production answer.

Engineering needed somewhere that uncertainty was allowed to exist.

Operations, on the other hand, eventually needs an answer.

That difference is one of the reasons the dedicated Engineering department finally made sense. It was not because JW Designs suddenly became large enough to imitate a corporate organization chart. It was because the technical work had become persistent enough that I needed a place where an unresolved question could remain unresolved without accidentally becoming the way the rest of the business operated.

Engineering needed a home because the business finally had enough technical history that “something I considered” and “something I decided” could no longer be treated as the same thing.

Giving Engineering a home solved one problem, but it exposed another. It was one thing to have a place where an engineering question could remain open while I tested materials, changed dimensions, investigated failures, or simply tried to understand what was happening. It was another thing entirely to decide when that work was finished enough for the rest of the business to depend on it.

And that is where I am going to stop this one. Not because the Engineering story is finished, but because this turned out to be a bigger part of the JW Designs story than I expected. Next week, Part B picks up right here: with the moment an engineering answer stops being something I am considering and becomes the way JW Designs actually builds something.