If you are the person who gets called every time something breaks, the problem is not your availability.

The judgment lives in one place

Somebody calls at two in the morning. A system is down. Which system, how bad is it, who owns that area, is this the kind of thing that waits until morning, who is on vacation this week.

Those questions get answered by whoever holds the whole picture. In most small companies that is one person, and every call routes to them because no alternative path exists.

The person on the receiving end usually reads this as a workload problem and tries to solve it by being more available. Availability is not the constraint. The absence of a written rule is.

Every call came to me

The warehouses ran 24 hours a day, seven days a week, all year, excluding Christmas and a couple of other holidays.

An operation like that needs somebody to call at three in the morning. Not somebody who might answer. Somebody whose job at that moment is to answer.

For a long stretch, that was me. Every call came to me, and I decided who got contacted, who got woken up, and what could wait. Every time, for anything.

I was not doing anyone a favor by absorbing it. I was the single point through which every night-time decision had to pass, and a single point that needs sleep is a design flaw rather than a virtue.

A form and somebody paid to follow it

We set up a help desk, run by US Technical Services. Somebody there answered the call, worked through a routing form, and contacted the right person directly.

This system failed, that system failed, here is who gets called. Not a platform, not an on-call product, and certainly not anything with intelligence in it. A form, and a person following it at three in the morning.

I stopped being woken for every small error, and the person who could fix the problem got contacted first rather than second.

One page, less than people expect

Less than people expect. The failure types you see in practice, which is a shorter list than anyone believes before they write it down. Who owns each one. Who gets called if that person does not answer. What can wait until morning and what cannot.

It fits on a page. The hard part is admitting how few distinct situations there really are, because the person holding the judgment experiences each night as unique.

They are not unique. Most on-call decisions repeat, and the exceptions are rare enough that a form can say escalate to the manager for anything not listed.

The costs nobody counts

More than the sleep, and the other costs are the ones nobody counts.

Every call routed through one person adds delay, because the call reaches a hop before it reaches a fixer. At two in the morning that delay is the difference between an incident and an outage.

It also means nobody else learns to make the decision. The judgment stays in one head, and the longer it stays there the harder it becomes to write down, because the person holding it stops noticing they are applying rules at all.

And it hides the pattern. When one person absorbs everything, nobody sees that the same three systems generate most of the calls, because there is no record.

Start with the last ten calls

Write down the last ten calls you took and who should have taken each one. That takes an hour and produces the first draft of the form.

Most people are surprised by how much repetition appears, and by how many of those calls had an obvious owner who was not contacted.

Then add the two or three cases that really are yours. Those exist and should be named, because a form that pretends the manager is never needed will be ignored the first time it is wrong.

The goal is not to remove yourself from every call. It is to be called for the ones that need you, which turns out to be a small fraction of what currently arrives.

The full article is on my site: https://thewritingking.com/the-manager-as-routing-layer/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

If you cannot fill a technical role, the problem may not be your pay or your posting.

Three problems that get treated as one

People apply and none of them are suitable. That is a screening problem, and it usually means the posting describes something different from the job.

Suitable people apply and decline your offer. That is a compensation or a company problem, uncomfortable and fixable.

Nobody applies at all. That is a supply problem, and no amount of rewriting the posting will change it.

The third is misdiagnosed most often, because it looks like the first two from inside.

Nobody applied

I needed database administrators and I could not find them anywhere in the United States.

That surprised me. I assumed database administrators existed in a country this size, and that finding them was a matter of looking properly.

Nobody was putting in an application. Not unsuitable applications. None.

So I started looking at sponsored hires from outside the country. My boss did most of the work setting the program up and managed it. I found the people.

None of that was about cost. I was not seeking cheaper labor and there was no policy telling me to do it. I had roles I could not fill and a domestic market producing no candidates.

The sponsorship sequence, step by step

The employer petitions, not the worker, and that is the first thing most people get wrong.

The main route for specialty roles requires the company to file on behalf of a specific person for a specific job, typically requiring at least a bachelor’s degree in a related field.

Most positions fall under an annual cap, which means a lottery. Registration happens during a window each spring, and if registrations exceed the cap, selection is by draw.

After selection comes a certified labor condition application, then the petition, then consular processing for many applicants.

Every step has a fee and a waiting period, and the lottery sits in the middle of it. You can do everything correctly and simply not be selected.

Everything about it has changed since

Enough that anyone using my experience as a guide would be badly out of date.

Selection is no longer a straight draw. It is weighted by wage level, which favors higher-paying positions and disadvantages smaller employers competing for the same people.

A separate six-figure payment applies to certain petitions for workers currently abroad, introduced in late 2025. Expedited processing costs more. Automatic work-authorization extensions were eliminated and site visits expanded.

Verify the current rules before acting on any of it, because this area changes faster than almost anything else in hiring.

Ten thousand dollars and up, before anyone works

That is a fair planning figure for a typical employer, counting government fees and legal help. Smaller employers pay somewhat less, since some fees are reduced or waived below a certain headcount.

Somewhat less is still five figures, which is the band a company with forty people is planning against. Then add the possibility that the lottery does not select you, in which case the money bought you a place in next year’s draw.

Half is a good hit rate

Two of the people I sponsored worked out well. One later left and started his own company. Another stayed for many years and moved on to a new company where he is doing well.

The other two did not work out.

Nobody says half out loud, because every article about hiring implies a good process approaches certainty, and mine across thirty-three years is roughly half.

What I will not do is explain why the two did not work out, because I do not know with any confidence. The reasons a hire fails are usually specific and unglamorous, and the manager rarely has the full picture.

The number that matters is the one nobody prints. An expensive, slow, legally involved process produced the same odds as ordinary hiring.

Count the applications first

Count the applications before spending money on anything. Suitable candidates declining means compensation or the role. Unsuitable candidates means the posting. An empty inbox means the people do not exist in your market.

For a supply problem the options are sponsor, contract, or grow it internally over a year or more. None is easy, and the shortage is not going to resolve. Specialists take years to make and nobody is making them.

The full article is on my site: https://thewritingking.com/the-specialist-shortage/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

A tested system and a proven system are different things, and most companies say covered when they mean tested.

Built without a budget

Building a disaster recovery site was one of the main reasons I was hired, and it became my first major responsibility. There was no budget for it.

I had money for machines. I had nothing for people, and I could not hire anyone to do the work.

So I sent the people I already had out to the site periodically to build a piece of it. A trip here, a trip there, across years.

There was never a project. Never a headcount request, never an approval for the thing as a whole, never a line item anyone could point at and cut.

It existed because somebody kept sending people out there.

That is how resilience usually gets built

The vendor version is a program with a start date, a budget, and a completion milestone. The version that happens is a person who decides it matters and keeps chipping at it.

No single trip needs approval, so no single trip gets refused.

That approach depends entirely on one person continuing to care. It also survives budget cycles, because there is nothing on the budget to cut.

Forty miles was the limit, not a preference

The site sat about forty miles from the main computer room. That distance was as far as we could go and still keep the systems copying properly.

Connectivity started as a few circuits, became a faster one, and eventually became something much faster. Bandwidth was the binding constraint on how good the copy could be.

Today distance is nearly free. A company can put a copy of its data anywhere, and because the tradeoff disappeared, almost nobody reasons about it. When a constraint is forced, people think about it. When it vanishes, they stop.

Twenty desks

Ours had a duplicate machine running, receiving data, building logs. That part gets all the attention and it is the part everyone plans.

It also had laptops, computers, and a full twenty-desk setup, ready to go.

A disaster that takes out a computer room usually takes out the building the computer room is in, and the people who run the business need somewhere to be. A recovery plan that restores the systems and leaves forty people with nowhere to sit has solved half the problem.

We tested it. We never failed over live.

The testing was real. Systems were exercised, the copy was verified, the equipment was checked. That work was not theater and it caught things.

What never happened was the business running on it. No day where the main site was gone and the company operated from forty miles away.

My word for that is fortunately, and I mean it.

Testing establishes that the parts work under known conditions. A live cutover establishes that the whole thing carries real load, real users, and real decisions made under pressure by people who have never done it before. Only the second is proof, and almost nobody has it.

The version that works for a smaller company

A genuine failover test means taking the business down deliberately, accepting that something might not come back, and having somebody authorize a self-inflicted outage on a normal Tuesday.

The narrower version: fail over one system rather than everything, during a quiet period, and have the people who would run the recovery do it rather than the person who designed it.

That last detail matters most. A recovery executed by its designer proves the design. A recovery executed by whoever is on duty proves the documentation, and the documentation is what you will have.

Telling a board the truth about readiness

We have a recovery site and we test it regularly is accurate and honest. We are covered implies something stronger.

Saying it plainly costs nothing and changes the conversation. A board told that the parts are tested and the whole has never been exercised will usually ask what a full test would take, which is exactly the question you want asked.

The full article is on my site: https://thewritingking.com/tested-is-not-proven/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

When a vendor has been working on your problem for a week without a theory, that is your signal to bring in somebody else.

The layer nobody watches

Monitoring shows software, load, and data volume, so that is where everyone looks first. Those three are visible and everyone knows how to talk about them.

The floor underneath is invisible by comparison. Cables, ports, controllers, links, and the physical arrangement of equipment do not appear on any dashboard, and they can change the behavior of everything above them.

A team can spend a very long time examining the visible layer while the answer sits in the layer nobody is instrumented to see.

The mirror and the forty miles

Our production system copied its disks continuously to an identical system at a disaster recovery site about forty miles away.

The copying ran asynchronously, which means production wrote its data, carried on working, and the copy caught up shortly afterward. Production never waited.

The alternative is synchronous, where every write waits for confirmation that the remote site has it too. Synchronous gives you a perfect copy at every instant. It also means every single write pays the cost of the distance.

Over forty miles, that cost is significant. Asynchronous was the correct design and it worked for years.

A thousand percent slower

Everything went slow at once. Operations that took minutes were taking hours. The business could not function at that speed, and nothing about the software had changed.

The cause was a bad cable.

That cable had pushed the mirror from asynchronous to synchronous. Every write to production was now waiting for a confirmation from a site forty miles away, and the system was doing exactly what its configuration told it to do.

The software was fine. One failed piece of copper at the bottom of the stack had changed how the entire business behaved.

A week with no theory

I called in a consulting firm first. They looked at it, and looked at it, and could not work it out. A week went by with no answer and no hypothesis.

I want to be fair to them. The cause was unusual and it lived in a layer most people do not examine. They were not lazy and I have no complaint about their effort.

But a week of effort with no theory is information. A team that knows a system produces a hypothesis early, tests it, and either narrows or discards it. A team without one produces activity, and activity looks like progress from the outside.

Ask what the current theory is. Ask what has been ruled out. If neither question has an answer after several days, the issue is not effort.

Three hours, no invoice

Somebody recommended a second firm, US Technical Services, so I called them. I told them plainly that I had a disaster, that I was stuck, and that the firm I had already hired was not helping. No positioning, no defending the earlier decision.

They came in with their whole team, about five people at the time. They worked for a few hours. Then they pointed at a cable and said that is the problem, switch it over.

I asked what it would cost. He said nothing.

I asked what he meant, because the answer made no sense to me. He said that when your neighbor’s house is on fire, you come and put the fire out. You do not charge them for it. You just put out the fire.

He became my consultant of choice permanently. That firm went on to run our private cloud, operate the computer room, take the overnight calls, and eventually rebuild the entire room to triple redundancy without taking anything down.

Years of work came out of a decision not to send an invoice for three hours.

Procurement will not find these

Every company has a list of approved suppliers selected on price, references, and a scoring matrix. That process produces adequate vendors, because it is built to avoid bad outcomes rather than to find exceptional ones.

Ask your network who they call when something has gone badly wrong. That question gets a different answer than asking who they use.

The full article is on my site: https://thewritingking.com/one-bad-cable/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

A hard constraint will hand you a solution you would never have picked from a list of options, and the solution is often better than what you would have chosen freely.

Free choice produces the obvious answer

Give a group unlimited time and budget and they will schedule the outage, move the systems, do the work, and move them back. That is a fine plan and it requires no thought.

Remove the outage from the table and something different happens. The obvious answer is gone, so the team has to look at the actual problem rather than at the standard procedure for problems of that shape.

Most good engineering I have watched came out of somebody being told they could not do the normal thing.

A tile that was buckling

The consultant running our computer room came to me one day. A raised floor tile under the main cabinet was buckling. Not cracked, not worn. Buckling, which meant it could give way at any moment.

Above that tile sat the cabinet holding eight machines running the business.

This had to be fixed immediately, so we took the next weekend. A week to plan, a weekend to execute.

Both answers disappeared

Move the workloads elsewhere, take the cabinet down, replace the tile, bring it back. That is what anyone would propose and it is what I would have proposed.

We did not have the spare capacity to relocate eight machines. We moved a few and could not move the rest.

Then my boss added the constraint that settled everything. Zero downtime. The business would not stop for this.

Now the standard answer was unavailable, and so was the fallback. What remained was one option nobody would pick from a menu.

Lift the cabinet while it was live and running. Replace the tile underneath it. Set it back down.

A bladder, bracing, and a clipboard

I walked into the computer room and there was an enormous inflatable bladder under the cabinet, with bracing everywhere.

It looked like a nightmare. It was also clearly not going to fall over, which is the impression good rigging gives you.

They lifted it. They replaced the tile. They set it back down. It went very well, and it was expensive.

Nothing about the operation was improvised. The firm was US Technical Services, and the people doing the work were ex-Marines and ex-special forces. They had clipboards. They had a written plan and they followed it exactly.

A dangerous operation was boring to watch, which is what competence looks like from the outside.

Procedure beats skill under pressure

The people lifting that cabinet were highly capable, and that is not why it worked. It worked because somebody had written down the sequence, everyone knew their part, and nobody had to make a judgment call while several tons of equipment sat on an air bladder.

The failure mode in this kind of work is never the risky operation. It is the risky operation performed by people improvising, where two competent people each make a reasonable decision that contradicts the other.

Most companies have never written down what happens during their equivalent moment. They find out how well they improvise while the thing is already buckling.

The three or four pages worth writing

Not a binder. A page each for the things that would hurt. Restoring from backup. Failing over to a second site. Bringing the business up after an extended outage. Handling the discovery that something physical is about to fail.

Each page says who does what, in what order, and who decides. Writing one takes an afternoon.

The value is not the paper. The value is that writing it forces the decisions in advance, when there is time to think.

Keeping my boss out of the room

He wanted to watch the lift. I told him no.

He asked why, and I told him the truth, which was that watching it would probably upset him. He accepted that and stayed out of the computer room.

I did not hide the operation. He knew what we were doing, he had set the constraint that shaped it, and he had approved the cost. What I declined was the viewing.

There is a version of managing upward that means controlling what the person above you knows, and that version ends badly. This was different, and he trusted the judgment.

The full article is on my site: https://thewritingking.com/constraints-produce-solutions/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

The first time you outsource a capability is usually the last decision you get to make about it.

The question the business case leaves out

Somebody has to operate the thing. The proposal covers the purchase, the migration, and the benefit, and assumes operation as a background condition, the way it assumes the building will have electricity.

Operating a new platform is a skill that either exists on your team or does not, and if it does not, somebody has to acquire it during a period when they are already fully committed.

Eight hosts and three hundred machines

After the first virtualization rescue worked, I made it a directive to virtualize everything. I left the first host running only that one system, because virtualization was new to us and I was not confident adding workloads would leave it fast.

So I bought a second host and put around thirty systems on it. Then another. Then another. By the end we had eight hosts.

Those eight replaced roughly three hundred old machines, which we sold off as used equipment.

Every system got faster and the gains were large rather than marginal. Security improved, because workloads sat inside a managed layer rather than on individual boxes scattered around a building. Availability improved.

By any technical measure the project was a success, and that success created the problem.

They wanted to learn it

My team wanted to learn it. Nobody objected, nobody dragged their feet, and nobody argued the technology was a bad idea.

They had no time. They were running the middleware, the databases, the applications, and everything else, and those systems did not pause while a new platform arrived.

The classes existed. Training was available and I was willing to pay for it. Taking a class means days away from work that has no cover, and the work would still be waiting afterward with a few days added to it.

They would not do it outside normal hours either, which is a fair position and I have never held it against anyone.

Training requires slack. My team had none, and no amount of willingness substitutes for hours that do not exist.

So I hired the firm

The private cloud was running production systems and needed competent operation immediately. My people wanted the skill and could not get to it. Waiting was not available.

So I hired US Technical Services, the same people who had already proven themselves several times over.

It worked exceptionally well. The platform ran properly, the systems stayed up, and the technical outcome was everything I had wanted.

My team did not like it. They were right to feel that way and I would make the same call again, and both of those are true.

The door locks behind you

My team never got the skill back. The vendor ran that platform from then on, permanently, and nobody ever decided that. It arrived as a consequence.

The mechanism is simple once you see it. The reason to learn a technology is that you need to operate it. Once somebody else operates it, the reason disappears, and the hours that were unavailable when the reason existed are certainly not going to appear now that it does not.

Each year the gap widens. The platform advances, your people fall further behind, and bringing it back in house becomes a bigger project than the original migration.

Nobody makes that decision. It is made by the absence of a decision.

Three paths, and only one is a failure

If you intend to bring the capability in house eventually, say so before signing. Name who will learn it, put shadowing in the agreement, and set a date for reviewing whether it happened.

If you have decided to outsource permanently, that is a legitimate choice and deserves the same clarity. Know what your exit would involve and be honest with your team.

The failure is the third path, where nobody chooses, everyone assumes the skill will come back later, and it never does.

The question before signing is not whether the vendor is good. It is what happens in five years if they are still doing it, because for a capability like this, they will be.

The full article is on my site: https://thewritingking.com/outsourcing-a-skill-is-permanent/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Before you fund a project to modernize an aging system, find out whether the failures are coming from the software or from the hardware underneath it.

Two decays that look identical

Software decays in a specific sense. Dependencies age, assumptions stop holding, and the people who understood it move on. That decay is real and rewriting is the only cure.

Hardware decays in a physical sense. Components fail, capacity that was generous becomes tight, and a machine that ran a workload comfortably in year three struggles in year nine.

Both produce the same symptom, which is a system that breaks more than it used to. Almost every modernization proposal assumes the first cause without checking for the second.

Telling the two decays apart

Software failures cluster around behavior. A specific function fails, a particular data condition breaks something, the same error appears under the same circumstances. There is a pattern you can describe.

Hardware failures cluster around load and time. Things get slow when the machine is busy. Failures happen at no consistent place in the code. Restarting helps for a while.

When somebody describes a system as breaking all the time and being slow, without being able to say what it breaks on, that is usually the machine.

We moved it and the problem went away

We had a large business system on old hardware. It broke constantly and it was slow.

Upgrading the software was not on the table. The system was old enough that we believed touching it would break it, and that belief was reasonable given what we knew.

Working with a consultant, I proposed a different approach. Virtualize it. Put the same software, unchanged, onto a virtual machine running on modern hardware.

The theory was that the software would run faster and stop failing because the failures were coming from underneath it rather than from inside it.

We moved it, and it ran like a bat out of hell. It stopped breaking, because the hardware under it was now stable. And it stayed there, working, for about six years.

Nobody wrote a line of code. Nobody paid down a line of technical debt. The problem went away because the floor got replaced.

Buy more capacity than the job needs

When I bought the host for that project, I bought a big one. The single system did not require it.

The effort of an approval is roughly fixed. The same meetings, the same justification, the same finance conversation, whether the number is small or large. What changes is the number, not the work.

And if it gets cut, a request sized with room to spare gets cut back to something still workable. A request sized exactly to the need gets cut into the bone.

That oversized host is why one rescued system turned into a virtualized computer room. Nobody approved that outcome, because nobody could have described it at the time.

Owning hardware, twenty years later

The answer has shifted twice in twenty years. When I built that private cloud, running your own was the only real option. Then everything went to hosted infrastructure. Now a significant share of companies are moving workloads back.

The reason is unglamorous. Steady-state workloads that do not vary much never needed elastic capacity, and they look expensive once somebody measures them against owning the equivalent.

The test is variability. A workload that spikes unpredictably belongs somewhere elastic. A workload that runs at roughly the same level all year is a candidate for hardware you own, and that describes a lot of what a forty-person company runs.

Ask what is breaking before you decide what to build

Plenty of old systems do need rewriting, because the business has changed or the rules are trapped in code nobody can read.

But the diagnosis gets skipped constantly. A system breaks, somebody proposes replacing it, and the proposal is approved without anyone establishing what was breaking or why.

Six years of stability came out of moving something instead of rebuilding it.

The full article is on my site: https://thewritingking.com/moved-not-fixed/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Every platform purchase has a gap between signing and working, and nobody plans for what happens inside it.

Buy versus build is a question about time

The argument gets framed as a permanent choice. Buy for speed and support, build for control and fit. Both cases are reasonable.

What the framing misses is time. A purchased platform does not start working the day the contract is signed. It gets configured, integrated, tested, and adopted, and that takes months.

During those months the business still needs the thing done. Nobody puts that period in the business case.

Enterprise software arrives configured for nothing

Because the product is general and your business is not. Enterprise software is built to serve many companies, which means it arrives capable of a great deal and configured for nothing.

Add integration with what you already run, data mapping between formats never designed to meet, testing against real volumes, and training for people who did not ask for a new tool. Months disappear into those four things.

None of that means the purchase was wrong. It means the purchase was the beginning of a project rather than the end of one.

DataSlide

We were in the middle of the second transformation, moving off a declining database onto a new platform. Part of the plan was enterprise middleware that would move data between the old systems and the new ones.

The middleware was not ready. The migration was.

So a programmer on my team built a set of programs that slid data from one system to another. Extract it, convert it, load it somewhere else. He named it himself.

It worked. It moved the data while the purchased platform was still being brought up, and the migration kept moving because of it.

Building the interim version anyway

The objection is obvious. You are building the thing you just paid somebody else to provide.

Three things make it worth doing anyway. The interim version only has to handle your cases rather than every company’s, so it is far smaller than the product. It can be built by people who already understand your data. And it can be thrown away without regret, because it was never meant to last.

That last condition is what separates a good interim solution from a problem. Build it knowing it dies, keep it small, and do not let it grow features.

The failure mode is the interim tool quietly becoming permanent because it works and nobody wants to finish the migration. Set a date for retiring it when you build it.

Marble floors and a nine-figure exit

The middleware company we bought from had a headquarters within walking distance. Beautiful building, obviously overbuilt, marble floors. Built to impress buyers.

They wanted to sell the company, and they did. A major technology firm acquired them for around three hundred and eighty-seven million dollars in 2005.

My boss loved that company. The building did its job.

None of that made it a bad purchase. The product was real and the acquisition proved somebody else agreed. What the building told us was about the vendor’s ambitions, and a buyer should know which signals are about the product and which are about the sale.

One question, in writing

When will this platform be doing real work for us, and what are we doing between now and then?

A vendor who has implemented for companies your size will answer specifically. They will describe the phases, name what typically slips, and tell you what other customers did in the meantime. A vendor who answers with a fast onboarding timeline and no discussion of the gap has told you something too.

Then plan the gap deliberately. Keep the old system running longer, which costs money and buys certainty. Build something small and temporary, which costs engineering time and requires the discipline to kill it. Or accept the business does without, which is sometimes fine and should be a decision rather than a surprise.

Any of those beats discovering in month four that nobody thought about it.

The purchased platform had marble floors and a nine-figure exit. The interim tool had a programmer and a deadline. Both were part of the same successful migration, and only one appears in any account of how these projects work.

The full article is on my site: https://thewritingking.com/buy-versus-build-in-the-gap/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Modernization gets sold as an opportunity and it almost never arrives as one. It arrives as a bill.

The version in the sales deck

A new platform makes new things possible, the business grows into it, and the investment pays for itself. Somewhere that happens.

In practice most modernization projects start when a support contract ends, a database vendor loses a market, hardware can no longer be expanded, or a compliance requirement lands that the current system cannot meet.

None of those are opportunities. They are deadlines with a cost attached, and the cost was set by somebody who does not work for you.

The ground moved underneath us

About eight to ten years after the first transformation I ran, we had to do it again.

The first one took a year and moved the company off paper onto a large minicomputer running a database called Unidata. It worked, and it ran the business for the better part of a decade.

Then Unidata was clearly losing the database wars. The platform was in decline, and my recollection is that we had reached the point where we could not upgrade further.

Neither of those facts had anything to do with us. Our systems worked. Our people knew them. The business was running.

The decision arrived from outside anyway, and the only question left was whether we moved on our schedule or on somebody else’s.

People, processes, technology, in that order

Nobody used that phrase at the time and it is what we did. Start with what the people needed. Then work out how the process would run inside each department. Then handle the technology.

That order matters more when the technology is already fixed than when it is open. We were moving to a specific platform and that part was settled, which meant technology was the least negotiable item in the entire project.

It still went last. Most teams invert this. They pick the platform, design the process around whatever the platform does easily, and then tell the people. Then they are surprised when adoption is poor.

Bigger capability, bigger project

By the second transformation we had high-capacity circuits to the stores and satellite communication, neither of which existed for us the first time. The scope grew to match. Accounting, human resources, merchandising, and eventually warehousing.

Better tools produce a bigger project rather than an easier one. That pattern catches people.

Three signals that show up years early

Hiring is the earliest signal. When people with skills in your platform become hard to find and expensive, the market has already made a decision that has not reached you yet.

How often the product ships is the second. Something releasing maintenance updates and nothing else is being maintained rather than developed.

The third is the vendor’s own behavior. When they stop sending anyone to see you, when their conferences shrink, when the account team turns over repeatedly, the platform is not where their attention is.

None of those are secrets and all show up years before an end-of-support notice.

A forced migration costs bargaining power

Bargaining power, which converts directly into money.

A company that starts early can evaluate options properly, negotiate from a position where walking away is real, and stop if something better appears. A company on a deadline set by a vendor gets none of that.

The technical work is identical in both cases. What differs is the price and the number of compromises.

The discipline that is affordable

Not replacing everything on a schedule somebody sold you. Know which of your platforms is in decline, and start planning for the one closest to the end.

Not migrating. Planning. Understanding what the move would involve, what it would cost, and roughly how long it would take.

That planning is cheap and it is the entire difference between a project you run and a project that runs you.

The full article is on my site: https://thewritingking.com/nobody-chooses-to-modernize/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Every transformation vendor sells alignment, and alignment is not for sale.

The failure nobody sells a product for

Before anything can be built, a large number of people have to agree on what gets built, and they will not.

Every vendor in this market sells a framework that promises alignment. Workshops, discovery phases, stakeholder maps. Those produce documents. What they do not produce is agreement, because the disagreement is real and no process dissolves it.

A pallet of paper a day

When I arrived at a major national retailer in the mid-1990s, the company ran on paper. Paper in the accounting room. Paper manifests at the warehouses. Accounting, human resources, everything, done by hand.

The printers produced hundreds of reams a day. My recollection is a pallet of paper, every single day, and I do not think that is an exaggeration.

The accounting equipment was a set of old machines I only saw a couple of times. Strange devices that reminded me of an abacus.

My job was to put my arms around the project and manage the pieces, alongside the development person, the store person, and the network person. Nobody called it a digital transformation, because the phrase did not exist yet.

Everyone was reasonable and nobody agreed

Hundreds of people across departments that had never needed to agree on anything suddenly had to agree on how the company would work. Accounting wanted one thing. The warehouses wanted another. The stores wanted a third. Every one of those positions was reasonable from where the person stood.

They were not being difficult. Each department had built its process around what paper allowed, and each had legitimate reasons for its own way of working.

What I learned is that unanimous agreement is not available at that scale. You reach a consensus quickly and then you decide. Sometimes you override people and sometimes you go along with them, and usually it is a bit of both.

Set a date and say it out loud

The date is what makes the rest work. A discussion with no end runs until somebody with authority loses patience, and the decision that comes out of that is worse and lands harder, because it arrives as an interruption rather than as a scheduled event.

Announce the date at the beginning. Say plainly that every department will be heard, that not every department will get what it asked for, and that the decision happens on that day.

Then hear people properly. Being overridden after a real hearing is survivable. Being overridden by somebody who never listened is what produces the quiet non-cooperation that sinks the rollout six months later.

Overriding the department that optimizes for itself

Whoever is protecting their own department at the expense of the whole.

That is easy to write and hard to identify, because nobody experiences themselves that way. The warehouse manager arguing for warehouse requirements is doing his job.

The test is whether the request survives the question of what it costs everyone else. Ask it out loud, in the room, and let the person answer. Some requests survive and get adopted. Most get modified. A few do not, and the person on the receiving end has at least seen why.

The cost in trust is real

Every override spends a little of the relationship with the person overridden. Enough of them, made carelessly, and a project acquires people who will not sabotage it and will not help it either.

A small company feels this more sharply. At forty people there is no distance to absorb it. Everyone knows who got overruled, and the person who lost the argument is sitting across the table at lunch.

Explain the reasoning privately and specifically rather than announcing the outcome to a group. And give ground where the cost to the whole is low, since a leader who has never conceded anything is not making decisions, they are issuing them.

Strip away thirty years of vocabulary and a transformation is a coordination problem wearing a technology costume. The technology part is the part you can buy.

The full article is on my site: https://thewritingking.com/consensus-you-cannot-get/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

The best job I ever had came from doing unglamorous maintenance work well for somebody who was watching without either of us thinking about it. No application, no resume, no search.

The spoken signal carries more now

Somebody who has watched you work says your name in a room you are not in. That has always been true and it has become more true, because every other channel has degraded.

Application volume exploded once submitting took seconds. Resumes are generated. Screening is automated on one side and worked around on the other. When the written signals stop carrying information, the spoken ones carry more.

A recommendation from somebody with firsthand knowledge is one of the few pieces of evidence still expensive to fake.

Which means the useful career question is not how to write a better resume. It is who has seen your work closely enough to describe it.

Keeping the computers going

At the consulting firm where I spent the late 1980s and early 1990s, part of my job was managing our managed services clients. One was a company called US Growers.

The work was not glamorous. Keep their computers going. When something failed, fix it. When they needed an upgrade, handle it. Me and my team, on a normal schedule, for years.

Nobody was auditioning. I was not building a network and they were not evaluating me for anything. They had systems that needed to run and I ran them.

What that produces over several years is a group of people who know exactly how you work. Not how you describe yourself. How you behave when something breaks at an inconvenient time.

Written down years later

Ralph Newton worked at US Growers during that period, and in 2015 he wrote it down.

He describes developing custom applications to update their warehouse management system so it would work with their largest customer. He calls the work dedicated and reliable, and singles out understanding their needs as the thing that mattered.

Then the line I still find remarkable. The applications had worked so well that many of the programs they were running at the time of writing were updated versions of the same ones.

Nothing about that is about cleverness. The reason he gives is that I understood what they needed, which is the part any competent person can do and most do not bother with.

Interviewed without knowing it

US Growers recommended me to the vice president of MIS at a major national retailer. He started bringing me in to talk. Several times, across weeks.

I had no idea he was looking for a hire. I thought we were having conversations, so I behaved like somebody having conversations, which in hindsight is the best possible preparation.

Eventually there was a formal interview. I dressed up for that one. He liked me and then had to sell me to the president of the company.

They hired me on the spot as director of technical services. That job lasted twenty years.

A referral answers a different question

An application tells a hiring manager what somebody claims to have done. A referral from a person who watched them tells the manager how they behave over time, under pressure, when nobody was assessing them.

Behavior over time is what every hiring manager is trying to buy, and no interview format reliably produces it.

Which is why the shortcut works from both directions. If you are hiring, the highest-value question you can ask your network is who they have watched work.

Building the network without networking

Do the work and be findable.

Deliberate networking has a poor reputation for a reason. Somebody you met once at an event cannot describe how you handle a failure at two in the morning.

The people who can are the ones you have worked alongside. Vendors, clients, contractors, the counterpart at the company you integrate with. Those relationships form as a byproduct of doing a job.

Ralph wrote his account decades after the work. Both the vice president who hired me and the president who approved it have passed away. The systems outlasted them and the reputation outlasted the systems.

The full article is on my site: https://thewritingking.com/how-referrals-actually-work/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

The best hire I made in thirty-three years produced no story. The resume was accurate, the interview matched it, the background matched the interview, and the work matched all three.

Nothing went wrong, which is why almost nobody writes about hires like this, and why most managers cannot describe what a good one looks like from the inside.

Every source of evidence agreeing

A candidate has a resume, an interview, a background, and references. In most hiring, one of those is impressive and the others are thin, and the impressive one carries the decision.

A clean hire is different. Nothing carries anything, because nothing needs carrying.

When that happens, managers tend to feel uneasy, because there is no puzzle to solve and hiring is supposed to be hard. The absence of a puzzle is the finding.

Elvis Niba

Elvis came to work for me during my years running computer operations, and he is one of the most competent people I have met in my entire life.

He is from Cameroon. His mother was impressed by Elvis Presley, and that is how he got the name. That is the story he told me, anyway, and I have always liked it.

The hire itself was uneventful. He had the qualifications. The interview went well. His background was strong. Everybody who met him liked him.

Then he started, and things stopped breaking.

Measured by what stops happening

Elvis took over his area and there was never any real problem after that. Anything that did come up, he fixed. That is the entire performance record and it is the highest praise available in operations work.

Consider what that looks like on a performance review. No incidents to point at. No dramatic recoveries. No firefighting, because there were no fires.

Meanwhile somebody in the next chair is visibly saving the day twice a month, and getting noticed for it, and half of those emergencies exist because of decisions that person made earlier.

Doing this work well is invisible by its nature. The reward structure in most companies is built around visible effort, so the people producing the best outcomes are frequently the quietest in the building.

Bad hires generate events, good ones generate quiet

A bad hire generates events. Meetings, decisions, a difficult conversation, a departure, a rebuild. All memorable, because all of it happened.

A good hire generates a stretch of time where nothing needed your attention. There is nothing to remember.

So managers accumulate a detailed library of what goes wrong and almost none of what goes right, then design their hiring process around avoiding the failures they can recall. That is a filter rather than a search, and a process built only for the first will reliably produce adequate people.

Verification is not suspicion

I have written elsewhere about a hire I got badly wrong, where a resume claimed a language the person had never written a line of. That story has a lesson and the lesson is trust but verify.

Elvis is the other half of the same lesson. Most candidates are telling the truth, and a process built on the assumption that everyone is exaggerating will insult the people you most want to hire.

Verify because you cannot tell which case you have, not because you expect the worst. When the evidence all lines up, believe it.

Keeping somebody like that

Give them the whole job and stay out of the way. Elvis owned an area, not a slice of it, with the authority to fix what needed fixing.

Highly competent people leave when the job shrinks. Somebody adds a layer of approval, splits the ownership, or asks for a status update on work that has never once been late. None of those individually looks like a reason to quit, and together they turn a good job into an ordinary one.

A small company has an advantage here it does not always use. There is no layer to add.

The full article is on my site: https://thewritingking.com/the-most-competent-person-i-hired/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Some software products come from research. Somebody studies a market, finds a gap, writes a plan, gets it funded.

Others come from an engineer who was annoyed. The second kind never appears on a roadmap, because a roadmap is a list of things somebody decided to do.

Both produce real products. Only one can be planned, so companies build processes around that one and quietly eliminate the conditions the other needs.

Performance work has nothing to demo

A successful performance project has nothing to show at the end. New features demo. Integrations demo. A dashboard demos. Performance work produces the absence of a problem, which is the hardest thing in technology to get paid for.

Ask for two weeks to make something faster and the question comes back: faster by how much, and what does that buy us. Both are fair questions and neither has an answer before the work is done.

So the work does not get approved. And then somebody does it anyway, on their own time, because they have to use the thing every day and it is driving them out of their mind.

Two engineers and a slow machine

At the consulting firm where I spent my early career, Steve Davis and another engineer built a disk defragmenter for the operating system we all worked on.

No company mandate. Nobody assigned it, nobody scheduled it, and it did not appear in any plan. They did it on the side, because disks got fragmented and everything slowed down and they were tired of it.

Performance before and after was not marginally different. It was different by orders of magnitude.

Then somebody looked at what they had and realized it was a product.

The strategy came second

The original tool served the operating system our clients ran. The firm judged the larger opportunity to be on the other major platform of the era, so it turned into a port and a plan.

I led that side. We also decided to bundle rather than ship a single utility, so it became a set of disk tools. One person handled the defragmenter, another the directory program.

None of that was possible before the side project existed. The thing came first and the strategy was assembled around it afterward, which is the opposite of how the story usually gets told.

Slack is unassigned capacity

Unassigned capacity. Hours not allocated to anything in particular.

Slack is the first casualty when budgets tighten, and cutting it is easy to justify. Every hour is now attached to a deliverable and the numbers improve immediately.

What disappears is invisible, because it was never on a list. Nobody writes down the products that were not built because nobody had a spare afternoon.

I am not arguing for a formal program. Twenty percent time is a large-company answer to a large-company problem and it usually decays into another meeting.

The small-company version is simpler. Do not schedule every hour. Leave a margin, do not ask what it produced, and accept that most of it produces nothing.

Adoption without promotion is the test

Somebody built it without being asked, and then other people started using it.

That second half is the test, because adoption without promotion is hard to fake. When a tool spreads through a team because it is useful, the market research has already happened.

Ask two questions when you find one. Who else has started using this, and what were they doing before. If the answer to the second is something slow and painful, you may be looking at a product.

The mistake is the other reaction. A manager who discovers unapproved work and asks who authorized it will not get told about the next one, and there is always a next one.

Protect the exception. It costs a margin of unassigned time and the discipline to not ask what that margin produced. Cutting it looks free on a spreadsheet, and what you cannot see on the spreadsheet is the product nobody got around to building.

The full article is on my site: https://thewritingking.com/work-nobody-approved/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Before you commission a technical assessment, find out what decision it is going to be used in.

Companies commission them for three reasons and only one is the reason people give. To learn something nobody knows. To create a record, usually because a decision has already been made and needs support. Or to win an argument with a counterparty who disagrees about money.

All three produce real work. Only the first one is a question.

Water goes down

On the night of October 15, 1984, a four-alarm fire broke out at 475 L’Enfant Plaza in Washington DC, the building housing both the US Postal Service headquarters and PBS. It started on the ninth floor shortly after eleven and burned through the upper floors. Around 190 firefighters brought it under control in about an hour.

The water went through the building and into the computer room in the basement.

PBS put preliminary damage to its property above twelve million dollars, and a spokeswoman listed broadcasting equipment, tape and editing machines, and computers. Insurance investigators toured the building the next day.

An insurance company hired one of the Big Five, and that firm hired us. The question was whether the computers still worked and, more to the point, whether they were still accurate.

Working and correct are different questions

Nobody had done this before as far as anyone knew. We designed programs from scratch that ran the equipment and compared output against known good results. Most in the general-purpose language of the era, my portion in assembler because I was fast in it and it needed to be quick.

The hard part is the reference. Something has to establish what the right answer looks like, and the machines that would normally tell you are the ones in question.

The deeper problem is that damaged equipment does not fail cleanly. A machine that will not turn on is easy. A machine that turns on, runs, produces output, and is wrong once every few thousand operations is what ruins a company.

Every restore from backup after a ransomware incident faces the same question and almost nobody asks it. The system came back. Nobody checked whether the data came back correct.

Twenty percent, and months of assessment

The insurance company wanted to pay a certain amount. PBS wanted new computers. Our project existed to establish whether refurbishing cost more than replacing, and to establish it straight.

The difference between the two positions was around twenty percent.

Nobody was deceived. The client told us plainly what the project was for. We knew from the beginning and we did honest work anyway. The engineering was real, the findings were real, and the project was still an instrument in a negotiation between two parties who each wanted a particular answer.

Neither side wanted it to end

When two sides are using an assessment to argue, neither is in a hurry for it to finish. The work continued for a long time. We never really finished it, and I left without learning the verdict.

From my seat it was a good assignment. Real money to spend, the best hotels in Washington, and a visit to the Smithsonian. It remains the only time I have been to DC.

Meanwhile the flooded computers sat there and the argument kept running.

The insurance company eventually said buy the new computers. They paid considerably more than the original settlement would have cost, after months of assessment work on top.

Both sides behaved rationally the entire time and the combined outcome was worse for everyone than an early agreement.

Four questions before you commission one

What decision does this report feed into. Who else will read it, and do they have a position already. What happens if the finding goes the other way. And what is the difference between the two positions, in money.

The last one gets skipped. If an assessment costs a meaningful fraction of the amount being argued over, it is not a way to save money.

The full article is on my site: https://thewritingking.com/assessment-as-a-negotiating-instrument/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

A resume and an interview tell you what somebody says they can do. Neither one tells you what they can do.

Every signal a hiring manager relies on has become cheap to produce. Resumes are written with AI. Cover letters are generated in seconds. Application volume has climbed past the point where reading everything is possible, so companies filter with software that candidates work around using more software. Interview answers get rehearsed against the same tools.

None of that makes candidates dishonest. Most are not. It means the evidence you were using to sort them no longer sorts them.

The hire I got wrong

Early in my time at a consulting firm we were building a set of disk utilities as a product. One piece was a directory program. The version shipping with the operating system was painfully slow, and our bet was that rewriting it in C would make it much faster. That bet was correct.

I needed somebody who knew that language. The person I hired said on their resume that they knew it inside and out. They interviewed well. Confident, articulate, easy to talk to.

I was a baby manager at the time. I had the title of vice president of consulting and no training in interviewing whatsoever. Nobody had ever taught me how to run one and I had never thought to ask.

So I hired on a resume and a good impression.

The tell was in the output

The program ran slower than the one we were replacing. Not slightly. Far slower than the version shipping with the operating system, which was the thing we had set out to beat.

I read the code and it was awful. Not stylistically awful, structurally awful, in ways that told me the person writing it did not understand the language.

I sat down with them and asked hard questions. After a while they admitted they had never programmed in that language in their life. Their background was somewhere else entirely.

I let them go and the project finished without them.

I already knew better

My own first real job came from an interview in Rick Shirley’s apartment, where he sat me down and had me write programs on the spot. He did not ask what I knew. He watched me do it.

That is how I got hired with almost no experience and a background nobody would have shortlisted. The demonstration was the whole application.

Then I became a manager and hired somebody off a resume and a good conversation. I had experienced the right method personally and still defaulted to the easy one, because the easy one is what everybody does and nobody had told me otherwise.

Trust but verify. I learned that phrase the expensive way.

A short paid work sample, then an explanation

A small piece of actual work, an hour or two, from your real problem domain. Not a puzzle, not a whiteboard exercise, not an algorithm nobody uses. Something resembling what the job involves on a normal Tuesday.

Then have them explain what they did. Why this approach, what they would change with another day, where they were unsure. Somebody who did the work can answer those questions for as long as you keep asking. Somebody who did not will run out quickly.

Pay them for the time. A few hundred dollars against a mistake that costs months, and candidates worth hiring will decline unpaid work from strangers.

The honest ending

We never made that directory program fast. The bet on the language was right, the code was not salvageable, and what we shipped was tolerable rather than good.

Not every story ends with a recovery. Some end with a system that works well enough and a lesson that cost more than the system was worth.

I have hired a great many people since, and I have never again taken somebody’s word for what they could do.

The full article is on my site: https://thewritingking.com/trust-but-verify-hiring/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Software that keeps customer rules in code has a ceiling, and you find the ceiling at the worst possible time. Software that keeps them in a table has no ceiling at all.

Integrates with everything means the connection works

It means the connection works. Connection is the part vendors demonstrate, because connection demos well. Data goes out of one system and arrives in another and everybody nods.

The connection was never the hard part. The hard part is that the receiving system wants the data arranged its own way, on its own schedule, with its own exceptions, and the next customer wants something different.

Multiply that by every customer you have and you have the actual project. Nobody sells you that half.

Four hundred newspapers over modems

In the early 1980s I led a project for National TV Log, and their entire business model depended on solving exactly that.

The idea was clever. Reach into a newspaper’s computer, take the file, insert small boldface advertisements, and put the newspaper back. Fully automated, no humans in the middle.

Around four hundred newspapers, each dialed up over a modem, because modems were what existed. Grab, insert, return, hang up, move to the next one.

Then the part that made it real work. Every newspaper had its own rules about where the advertisements went and how they were formatted. Four hundred customers, four hundred sets of rules, no two the same.

The ceiling arrives without warning

The obvious solution is to handle the differences in code. The first customer is easy. The second is easy. By customer five you have branching logic. By customer forty you have a system nobody can safely change, because every change risks all forty.

The modern version hides behind better words. Per-tenant configuration. Customer-specific business logic. Feature flags. Same problem, and the same teams hardcode the first three customers and discover it at the fortieth.

The rules lived in a table

Outside the code, in a table the program read.

Building that table was not trivial, because no databases existed to put it in. No structured query language, no commercial database engines available to us. We built the table and everything around it ourselves.

With no tools and no prior art, the design was still right. One program, and adding a newspaper meant adding a row rather than writing code. Four hundred was what they happened to have. The design had no number in it at all.

Teams today have databases, configuration frameworks, and rules engines available for free, and a great many of them still put the customer differences in the code.

Three signals the logic needs to come out

A conditional statement that names a customer. The moment code says if this is customer Jones, the rules have leaked into the wrong layer.

A deployment required to onboard a customer. If adding a customer means shipping code, every new customer carries the risk profile of a release.

A change nobody wants to make. When a small adjustment for one customer requires regression testing everybody else, the differences are entangled with the logic.

Doing it at customer five is a morning of work. Doing it at customer forty is a project.

Losing the account to your own success

The code was finished and delivered and the system worked well for them. Then somebody from my team took a job at National TV Log and took the work over. We lost the account.

That outcome is fine, and I mean it. They got a good product and the person who understood it best was now inside their building rather than billing them.

A consultancy that builds something durable and documents it properly will sometimes lose the work to its own success. The alternative is staying indispensable by leaving the thing half explained, which is worse for everyone.

Anyone hiring a consultant should ask what happens when the engagement ends. A good answer describes how the knowledge transfers. A bad answer explains why you will always need them.

The full article is on my site: https://thewritingking.com/rules-belong-outside-the-code/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Asking for something is not the same as verifying you got it, and the gap between those two costs more project time than any other mistake I have watched.

This failure has not changed in forty years. It has only found new places to happen. A vendor sends a specification that does not match what their interface returns. A migration runs against documentation nobody updated. An AI tool gets pointed at a branch that no longer reflects production and confidently rewrites code that is not there anymore.

In every one, somebody asked, somebody answered in good faith, and the answer was wrong.

A port that should have been simple

A company that made the nails for roofing trusses gave their customers a free program. You fed it inputs and it designed a roof truss. The nails are flat pieces of metal with sharp points that hold the wood together, and that was the whole business.

The program ran on an older machine and they wanted it on the personal computer becoming standard at the time. A straight port. No new features, no redesign.

I was not the project lead. I was the interface to the client, which means the files came through me.

We asked them for the sources. They sent them. Nobody skipped a step and nobody was careless.

Then the port would not work. The team tried, and tried differently, and burned weeks on a job that should have been simple. Eventually we got the right sources, and it worked immediately.

The sources we started with were not the ones in production. The person who pulled the files believed they were current. They were not, and nobody in the building knew.

The step that takes an hour

Build what you were handed, run it, and check the output against the version customers are using.

If they differ, you have found the problem on day one instead of week three. Skipping it cost us weeks, and there was no way to detect the difference from outside. Same file names. Same structure. Same everything except behavior.

The same test applies to almost any handoff. Run the vendor’s example against their interface and compare it with the documentation. Take one record through the process the runbook describes and see whether the runbook is accurate.

The 2026 version arrives in seconds

An AI tool reading a stale branch produces work that is internally consistent and externally wrong. It refactors functions removed months ago. It updates calls to an interface that changed. It writes tests for behavior nobody ships.

None of it looks wrong. That is the difficulty. Bad output from a confused tool arrives formatted, commented, and plausible.

Nobody to blame, which is why it keeps happening

The client believed they sent the right files. The person who pulled them believed the folder was current. We believed what we were given. Every individual acted reasonably and the project still lost weeks.

The failure lives in the handoff itself rather than in either party.

I sat in that handoff. I asked correctly and I received what I asked for. Doing my job properly was not enough to keep the wrong thing out. Anyone who sits between a vendor and their own team occupies the same position, because the engineers cannot verify what they were handed when they are not the ones talking to the people who have it.

Three questions before you start

When was this last used in production, and by whom. Where did you get it, and is that the same place the running version comes from. Is there another copy anywhere, and do the two match.

None of those is an accusation. They are the same questions you would ask about a used car.

Then run the thing and compare it against reality. The questions establish provenance. Running it establishes truth, and only one of those is evidence.

The full article is on my site: https://thewritingking.com/asking-is-not-verifying/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Every security vendor now sells anomaly detection with AI in the name. Some of it is new. A good deal of it is a statistical baseline with better marketing, and telling the two apart is worth money to anyone signing the contract.

Three things, whatever the label says

Nearly all of it computes the same three. What normal looks like for this specific customer, user, or device. How far the current behavior sits from that normal. Whether the distance is far enough to act on.

A baseline, a deviation, and a threshold. Modern systems may build the baseline in more dimensions and update it faster. The shape of the answer has not changed.

Ask a vendor to describe it in those terms. A good one will explain how their baseline is built and where the threshold comes from. A weak one will say the model learns.

The system we built in the late 1980s

I worked at a consulting firm that built fraud detection for phone cards. The client sold the cards, people used them, and some of those people were not the people who bought them.

My idea was to give every customer a profile describing what normal looked like for that person. Where they called from, when, how often, for how long.

Then every call got measured against that profile using standard deviation. Not a rule saying calls from Guatemala are suspicious, because plenty of legitimate customers call from Guatemala. A measure of how unusual this call was for this particular person.

A man who lives in Florida makes several calls from Guatemala at two in the morning. Outside his profile, but within tolerance, because he might be on vacation.

Then a call comes in from New Orleans. Now the pattern is not just unusual, it is impossible, because a person cannot be in both places. The flags accumulate and the card gets cut off.

No model, no training run

It had a profile per customer, a deviation measure, and a threshold. It caught fraud, the client was happy, and the firm turned it into a product.

I am not arguing nothing has improved since. Modern systems handle far more signals, adapt faster, and find patterns a person would not think to look for. Those are real gains.

The argument is narrower. A great deal of what gets sold as AI detection is the older method with more dimensions, priced as though it were new.

The threshold is the whole product

Set it tight and you block real customers. Every legitimate person who travels or has an unusual week becomes a support call and an angry email. Set it loose and fraud walks through.

Our design required accumulation rather than a single event. One odd call moved a number. It did not cut anyone off. The card stopped only when the pattern had built past the point where an innocent explanation still fit.

That approach is available to any company running any kind of detection today, and it has nothing to do with the technology. Decide what a single anomaly is worth, decide what the total has to reach, and write both numbers down.

Four questions for a vendor, none of them technical

What does the system compute, described without using the words AI or learning. How is normal established for a new customer with no history. What happens when the system is wrong, and who finds out. Who can change the threshold, and does that require the vendor.

A vendor with a real product answers all four in a few minutes. A vendor selling a label will move to case studies.

The last one matters more than it looks. A threshold you cannot adjust is somebody else’s risk appetite running inside your business.

Nobody called any of this intelligence in 1990, and nobody would have paid extra for the word.

The full article is on my site: https://thewritingking.com/what-anomaly-detection-computes/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Developers using AI tools merge far more code than they used to and their organizations ship at about the same rate. One large study found pull requests nearly doubling while review time rose almost as much and delivery stayed flat. A controlled trial found experienced developers slower with AI assistance while believing they were faster.

Something is absorbing the gains. I think a large share of it is people fixing generated code instead of throwing it out and asking again.

Nobody deletes, and the reason is sunk cost

Because rewriting feels like admitting the last three days were wasted. They were already wasted. The only question left is whether you spend three more.

That is the sunk cost trap, and knowing the name of it does not stop anyone at hour forty, when you are close, when the next idea is going to be the one. The next idea is never the one. If it were, you would not be at hour forty.

Generating a fresh version now costs almost nothing. The economics that justified grinding on broken code are gone. The instinct that grew out of them is still here.

Weeks on a bug that was not mine

Early in my career I was the lead developer on a system for a rivet company. Rivets were the entire business, and they were among the biggest in the country doing it. We built their accounting and merchandising systems from nothing and delivered them.

Then I hit a bug I could not find. The program crashed hard and dumped a full screen of garbage. Not diagnostics. Garbage.

I spent weeks on it. I read my code, rewrote sections, tested pieces in isolation, and got nowhere. Every day I was sure I was close.

The bug was in the compiler.

I proved it, which took a good part of those weeks, then opened a ticket with the vendor. That ticket was never resolved. As far as I know it is still open somewhere.

Being right did not ship the system

Steve Davis came in and fixed the project. He did not find the bug.

He took the modules I had been fighting with, threw them away, and rewrote them. That was the entire intervention. The rewritten code did not hit the compiler defect, the system worked, and the project moved.

I was right about the cause. Steve shipped the system. Only the second one mattered to the client.

I had confused winning the argument with the vendor for delivering the work. Those are separate projects, and only one of them is the job.

The same trap with AI-generated code

When you debug code you wrote, you are working with a model of it in your head. When you debug code a machine wrote, that model does not exist. You are reverse engineering a stranger’s work in order to repair it, and reverse engineering is slower than writing.

Independent analysis has found rising code churn, meaning more lines written and then quickly changed again. One review reported a substantial increase in security defects in AI-assisted code. That is the shape of work accepted before it was understood.

The alternative takes a minute. Throw it out, change what you asked for, generate again.

Two habits that cost nothing

Set a limit before the work starts. Half a day, one day, whatever fits. When the limit is reached, somebody else looks at it. Not because you failed, because that is the rule. Competent people do not ask for help because they are competent, and that belief is what keeps them in the hole.

And when work has resisted you long enough, delete it and build it again with what you now know.

One more thing I still think about. Steve Davis never chewed me out. He explained what had gone wrong and we moved on. No lecture about the weeks. Forty years later I am writing about it, which tells you which approach lasts.

The full article is on my site: https://thewritingking.com/when-to-delete-instead-of-debug/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.

Nine out of ten enterprise AI agent pilots never reach production. That number comes from Deloitte’s 2026 research, and companies that did deploy have started pulling their agents back out.

Every explanation blames the model. Not enough context, bad prompting, wrong framework, wait for the next release. I think the real cause is older and simpler. Nobody decided, before the build, what the thing was supposed to do when it was on its own.

Autonomy is not a feature you buy

A system is autonomous when somebody has written down what it may decide alone, what it must wait for, and what it does when waiting is not an option. A capable system with no such document is not autonomous. It is unsupervised.

The industry has spent three years on capability and almost none on permission.

A water system that ran alone for entire winters

In the 1980s I led a project for a water district in New Haven, Connecticut. Several thousand remote devices across the region. Sensors reading levels and flows, mechanisms that opened gates and dams and drained tanks, all reporting to a central server where operations staff made the calls.

New Haven gets a lot of snow. Communications ran over phone lines, because that was the entire list of options, and everyone understood those lines would go down in winter. Not might. Would.

And the water still had to flow. So we had a system that would routinely lose contact with every human responsible for it, for weeks and sometimes months, and could not stop working during that time.

The answer was to give every remote station a profile of its own behavior, built from the previous few years of water flows and weather at that specific location. When the line dropped, the station stopped waiting and started deciding from that picture. What to let flow, what to hold, what to open.

No model. No training run. No learning of any kind. A profile, a set of parameters, and a decision table.

The system was not intelligent by any standard. It was still autonomous, because somebody decided in advance what it could do alone.

The boundary, decided before any code

Under normal conditions the operations staff decided. The stations decided only when the staff could not be reached, and what they could decide was bounded by the profile, which meant they could act inside the range of normal and could not invent anything new.

The station was not trusted to be clever. It was trusted to keep doing the ordinary thing while nobody was available to ask for something unusual.

Compare that with an agent handed broad system access, a general-purpose model, and no written boundary. That agent is being trusted to be clever. Some night it will be clever about the wrong thing with nobody there.

The question worth asking this week

Ask what your agent does when a service it depends on is unavailable. Most of the time nobody knows.

The agent calls a service. The service was there in testing and in the demo, so everybody moved on. Then one day it is not there, and the agent retries, retries differently, produces a confident answer built on nothing, or loops until somebody notices the cost.

The New Haven design started from that condition rather than discovering it in production. We built the failure mode first and the normal mode second. I have not seen an AI project do that.

One page beats a governance platform

A large enterprise has a governance function and a committee. A company with forty people has neither, and gets told constantly to move fast and sort it out later.

The smaller company has one advantage. One person can keep the entire picture in their head, so the decision about what an agent may do alone can be made by somebody who understands the business, in an afternoon, on a single page.

That page is worth more than any governance platform on the market. Almost nobody writes it, because writing down limits feels like slowing down.

The companies that skip the page are the ones filling out the ninety percent.

The full article is on my site: https://thewritingking.com/autonomy-is-a-design-decision/. It runs longer, carries the diagrams, and answers the questions readers ask most.

These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.