The Lab Was Never the Point
What TekForge taught me about following the problem farther
A few months ago I wrote that, looking back over my career, I did not really see a ladder. I saw a continuous thread. The tools changed, but the instinct was pretty consistent: figure out how something works, figure out why it does not, and see whether there is a better way to do it.
TekForge has made that thread a lot easier for me to see. I originally thought I was building a home lab. Turns out I was mostly building a place where I could keep following the problem.
The problem kept getting bigger
I came up through support work. Early on, the problem in front of me was usually pretty well contained. Somebody could not log in. A workstation stopped working. An application threw an error. A piece of hardware did something it was not supposed to do. You troubleshoot it, figure out what failed, fix it, and move on.
Except the longer I worked in IT, the less often the problem stayed inside the box it arrived in.
The application problem might actually be an account problem. The account problem might lead into Active Directory. The server might be fine, but the user still cannot reach it. A problem with a manufacturing system can turn into a production problem very quickly.
At Brunswick, troubleshooting bowling systems could mean following the problem through a server, a database, point-of-sale equipment, communications hardware, workstations, and specialized scoring equipment. Sometimes the easiest way to understand what a customer was seeing was to reproduce their environment in the lab and make it fail in front of me. Later jobs added virtualization, Citrix, telecom, office moves, vendors, remote sites, identity, networking, and manufacturing infrastructure.
Regulated environments added another lesson: knowing how you could change something is not the same as deciding that you should. The technical answer has to fit the environment around it. Risk, documentation, validation, ownership, and the consequences of disturbing a working system are part of the problem too.
I never sat down and decided that I wanted the problems to get larger. I just kept following them.
Then I built an environment where there was nowhere to hand the problem off
That is probably the biggest thing TekForge changed for me. At work, every environment eventually has a boundary around your responsibility. Maybe there is a network team, an application owner, a vendor, a database administrator, or somebody else who owns the next layer. TekForge does not give me that escape hatch.
If an application is not working because DNS is wrong, DNS is also my problem. If the network design makes identity harder to manage, I own both sides of that decision. If a backup succeeds but I cannot restore the service, I do not get to close the ticket because the backup job was green.
That has changed the way I troubleshoot. A service running is useful information, but it does not mean the problem is solved. An open port tells me something is listening. A configuration file can look perfect and still describe a system that is behaving differently in the real world. What matters is whether the entire path works.
That sounds simple, but TekForge has given me plenty of opportunities to prove myself wrong. I have chased what looked like a missing service only to discover the functionality was already embedded somewhere else. I have found network paths that were doing exactly what they were configured to do, while the configuration itself represented the wrong assumption. I have hardened systems and then discovered that the hardening broke something farther down the path.
Some of my older architecture plans also had more servers, more separation, and more symmetry than the environment actually needed. Actual use corrected that. Some things never got built because the workload that was supposed to justify them never appeared. Other things changed roles. Some designs became simpler.
I have become a lot less interested in building something just because I can. A system should solve a problem worth owning afterward.
Most of my projects are really friction problems
That may be the other thing TekForge has made obvious: I tend to notice friction.
Sometimes the answer is infrastructure. Sometimes it is automation. Sometimes it is an existing product that just needs to be used differently. Sometimes I end up writing software because I cannot find anything that fits the problem closely enough.
The MDM work came from a real device-management problem. Norn came from being dissatisfied with the way the tools I was using handled different kinds of information. Tasks, long-term knowledge, inventory, health information, purchases, and financial activity all behave differently. Treating them as interchangeable created more friction than it removed.
I have already written plenty about Norn, so I will skip the tour this time. The important part is where it is now. What started as a collection of local tools has a functioning shared backend that I actually use across devices. The interesting work is no longer proving that it can synchronize. It is refining what happens when multiple clients can create and change real data, cleaning up assumptions from earlier versions, improving recovery, and making the system more dependable.
That feels very different from building a demo. It also feels familiar: the first version solves the obvious problem; using it teaches you what the real problem was.
SKALD is doing it again
The current AI work is following almost exactly the same pattern. Running a language model locally is cool. It is also not particularly useful by itself. The interesting problem is reducing the friction involved in operating everything around it.
If SKALD is eventually going to help me understand what changed, find information in Norn, investigate a service problem, or coordinate work across other systems, then it needs more than a model. It needs context. It needs to know which information is authoritative. It needs tools. It needs identities and access boundaries. It needs a way to distinguish between understanding a problem and being allowed to change something.
And suddenly the AI project is a networking project, an identity project, an automation project, a security project, and an application-integration project. Which feels about right.
I have no idea yet exactly how capable SKALD will become. What I do know is that I am much more interested in making it useful than making it impressive. If it eventually becomes something like an operational right hand, that will happen because the pieces underneath it work together well enough to earn that role.
I think that is what changed
For a long time, I thought of myself primarily as the person who could figure things out. Give me the broken thing. Give me the weird issue nobody can reproduce. Give me the system that worked yesterday. I still like that work.
The difference is that somewhere along the way I stopped only fixing the thing in front of me. I started asking why the problem existed there in the first place.
- Could the systems communicate differently?
- Could the process be simpler?
- Could something repetitive be automated?
- Does this component need to exist at all?
- What happens to the system around it if I change it?
That is a much larger boundary around essentially the same instinct I had when I started in support—and, apparently, the same instinct I had long before that. TekForge did not turn me into somebody different. It just gave that instinct room to run all the way through the stack.
I started the lab because I wanted somewhere to build things. The longer I operate it, the less I think the building was ever the interesting part. The interesting part was learning how the pieces affect each other, where the friction comes from, and what happens when you keep following a problem instead of stopping at the edge of the system you were originally looking at.
The lab was never really the point. The problem was. And then the system around it.