Tech junkie that thrives under pressure.

A lot of my work starts with a short message asking me to look at something. What matters is what happened when those requests stopped becoming one-off fixes and became systems a team could run.

Fourteenth issue July 10, 2026 By Marlon McKinnie

My LinkedIn profile still says it, verbatim, as of July 2026: "Tech junkie that thrives under pressure." It's a little awkward. That's probably why I still like it.

It says the thing faster than a cleaned-up bio would. I like strange tools. I like taking things apart. I also tend to be the person people contact when a problem crosses too many boundaries to fit neatly in one job description.

The request might be an Archibus environment, a workspace that needs a support path, an editor integration, an identity problem, an AI feature, or a release tied to one person's shell history. The technologies change. I keep asking the same question: can I turn what I learn into something the next person can run, inspect, and repair?

The oldest local pieces I can still find are from 2024. I don't trust every file date because I moved the work between development environments several times. The order is still obvious enough. The first pieces are scripts and small experiments around work that was easy to get wrong by hand. They made me faster. They didn't unload anything.

Me

The first serious Archibus research environment started with a hosting question. I needed to know whether the application, database, identity layer, ingress, certificates, and backups could live together in Kubernetes. This was early research, so I worked through most of it directly: Bash scripts, Helm commands, manually applied manifests, and a lot of log reading.

I needed to do it that way. Creating the certificate, applying the manifest, following the login redirect, and repairing the deployment made the dependencies stop looking like boxes in a diagram. I learned which step needed the previous one and how each layer failed when an assumption was wrong.

The first deployment loop was a script: build the image, tag it, push it, change the chart value, run the upgrade, and check the result. It was faster than typing each command from memory. It was still a personal interface. If the script stopped halfway through, I knew what it had done because I had written it. That didn't mean the team did.

For a while, that was the pattern: learn the failure, write a helper, remember what it did, and become the person who could explain it when it stopped. I was automating the steps without giving up much responsibility.

Operating record The work moved from my scripts to a shared platform

The useful change was not a cleaner diagram. It was moving the ritual out of one shell history and into systems other people could inspect, run, and repair.

Too many doors

There wasn't a clean jump from shell scripts to the current platform. I still have a folder called authentikhelm. It's basically a junk drawer for the middle. It has early identity work, Kubernetes manifests, chat prototypes, workspace templates, small tools, and abandoned paths sitting next to things that eventually shipped.

The ism-dev.us domain came out of that phase. I needed real addresses for identity, dashboards, APIs, application environments, Git, chat, and later workspaces. Giving each experiment a stable address made it easier to use and share. It also gave me a hallway full of doors.

I tried an Archibus command-line tool that could generate, list, push, and delete Coder templates. I also tried a desktop-shaped React interface with a Go backend. That version mostly knew how to provision Docker containers. There were terminal chat tools, Streamlit screens, editor experiments, and several attempts at giving the model enough Archibus context to be useful.

None of them became the final interface, but each one narrowed the problem. The CLI named the operations. The builder exposed choices around source code, runtime, databases, backups, and editor setup. By spring 2025, those choices were turning into reusable development environments instead of setup commands.

We started using the infant platform as an internal testbed on several projects in September 2025. We didn't wait for it to look finished. Real project work gave it the version mismatches, odd repositories, database restores, interrupted assignments, and support questions that a clean demo would miss.

The early Console grew out of that use. At first it was closer to a template builder. More services and more users meant we needed one place to create a workspace, find an existing one, manage a backup, see what failed, and continue. The domain gave every experiment a door. The Console became the front desk.

Here, take this ArgoCD

I was still holding too much state, so I started handing it away. Here, ArgoCD, you keep the application pointed at what Git says should exist. Kustomize and ApplicationSets gave the environments a repeatable shape. Branches mapped to deployment lanes. Database restore, migrations, identity, and application startup became ordered parts of the same system instead of notes spread across terminals.

That made the handoff practical. A teammate could read the repository before touching the cluster. The controller could show whether the running environment matched it, and recovery had a known state to return to.

GitOps didn't remove the hard parts. It made ownership visible. Later environments moved from ArgoCD to Flux. The controller mattered less than the habit: declare the desired state, review the change, and prove what reached the running system.

One pipeline change made the handoff clear. The pipeline stopped restarting the workload itself and started asking the deployment controller to reconcile the declared state. It wasn't pure GitOps yet. CI asked for convergence, and the controller owned how the environment got there.

Delivery

The first pipelines mostly automated commands I already knew how to run. Build the image. Run a check. Submit a deployment. That helped. The early history still shows what broke: branch assumptions, weak failure output, jobs running outside their intended scope, database setup, and deployments marked done without proof.

Over time that grew into a release path with a contract. Validate the source. Build an immutable artifact. Update the Git-owned release reference. Let the controller reconcile it. Check the running deployment. Exercise the narrow product behavior that changed. Each step leaves evidence for the next one.

Shared CI came next. One product repository no longer owned all the checks. Downstream repositories could include a versioned contract that created or attached to a workspace, ran validation near the application, focused review on changed files, and returned evidence to the merge request. Each repository kept a thin entry point instead of a copy of the operating logic.

Release moved the same way. A dry-run-first helper could find the affected images, limit GitOps edits to known files, reconcile Flux, and check the rollout. It kept two claims separate: Git changed, and the running product was checked. The Console made workspace and review state visible without someone watching a terminal.

Training

In June 2026, I led an internal training session for the development team. I didn't start with the architecture. I started with day one: pick a repository and branch, pick the runtime and a known database baseline, create a workspace, and get to work. The point was to stop setup from being tribal knowledge.

The questions were practical. What survives when a workspace is deleted? Can developers use their preferred editor? What happens if someone tries to push from the wrong branch? Can the system reset a database, reapply the checked-in changes, and test from a clean baseline? Can a team put its own review rules into CI instead of asking everyone to remember them?

I answered from the system in front of us. A part of the live demo failed to open. I used the error as the next input, explained the likely cause, and kept moving. Another control wasn't ready for everyone yet, so I said so and added it to the work. The session was training, but it was also a fairly honest product review.

The useful proof came from the other developers. They described using separate workspaces for separate assignments, saving team rules in the repository, resetting test data from source, and handing a running environment to someone else for review. The planned hour ran long because the questions kept coming.

It wasn't finished. I said that too. But I was no longer explaining how I personally set up a machine. I was teaching a shared way to start work, preserve it, check it, and hand it to the next person.

Meanwhile

All of this happened while the rest of the work kept moving. Managed workspaces and the Console were one stream. ArchiBotChat was another. Editor tooling and ArchiBot View Studio kept moving too.

Moving more development into agentic workflows let me take on more, but it also raised the cost of private context. Five fast work streams can become five private piles just as easily as one manually operated cluster can. Isolated work, narrow tasks, explicit checks, handoff notes, and a final verification pass kept that speed useful.

The work got faster when the next task stopped requiring a reconstruction of the last one. Repeated deployments became a release path. Repeated setup became a template. Support questions became diagnostics.

Pressure

I don't think pressure means chaos. Most mistakes are ordinary. Most fixes are too. Pressure is taking in work from several directions, deciding what matters now, and leaving enough structure that one project doesn't wipe out the state of another.

That old LinkedIn line still fits, even though I don't want every problem to become an emergency. When a problem repeats, I learn it by hand and fix what's in front of me. Then I make the next round less dependent on the person who already knows the ritual.