Welcome to the first issue of Patterns in Practice.
The name is a promise about the contents. I’ve spent thirty years inside technology decisions, first as an engineer, then as a CTO, now as a fractional CIO for companies that mostly can’t justify a full-time one. The same problems keep showing up in different buildings, and after enough repetitions you stop seeing incidents and start seeing patterns. This newsletter is where I write those down, along with what I’ve actually watched work. Some weeks it will be immediately useful. Some weeks it will just be interesting. I’ll try to be honest about which is which.
The pattern for this first issue is the one I run into most. Most technology problems aren’t technology problems. They’re decisions, processes, or ownership problems wearing a technology costume. Pull on the costume and something else is underneath.
Let me show you what that looked like on a real engagement.
The slow engineers who weren’t
A CEO called me because his product had gotten slow to change. The company had grown past $14M selling B2B software. Good product, real customers, and he was frustrated. Features that used to ship in days were taking weeks, his roadmap was slipping, and his working theory was that the engineering team had gotten comfortable. He wanted help figuring out which engineers to replace.
I spent the first week reading code and, more usefully, reading the ticket history. The engineers were fine. Their estimates were honest and their work was careful. What I found instead was a three-year trail of one habit: ship it now, decide later.
Three examples, because the specifics are the whole point.
They supported one payment provider. Three years earlier a big prospect had asked about a second one, so support for multiple providers got half-built, then the prospect went away and the half-built version stayed. Everything that touched billing had to step around it, and everything touches billing eventually.
A large customer had asked for a custom approval workflow. Instead of deciding whether that was a real feature or a one-time favor, the team wired it straight into the core product. From then on, every change to approvals had to be tested against one customer’s special case, and most engineers didn’t know why.
And customer data lived in two systems. There had been a plan to consolidate. Nobody ever decided which system would win, so both survived, and a large share of the bugs in the ticket history traced back to those two stores disagreeing with each other.
Multiply those three by a hundred smaller versions and you get what everyone calls technical debt. I used to explain that term with metaphors about loans and compounding interest. I’ve mostly stopped, because the metaphor lets a leadership team file the whole subject under “engineering mess,” and that’s backwards. Most of what was slowing this company down was a stack of business decisions nobody had made. The engineers were paying for each postponement by hand, sprint after sprint.
So we didn’t rewrite anything. Instead we built a list. The method was not sophisticated: we pulled the twenty slowest tickets from the past six months, asked the engineers “what made this one slow,” and wrote the answers on a whiteboard. The same handful of unresolved questions kept coming up, phrased differently each time. That clustering took two afternoons and produced about a dozen open decisions. Then the CEO sat down and answered them. One payment provider, for real, until revenue justified a second. The custom workflow became a flagged exception with an expiration date and a named owner. The duplicate customer store got retired, which took the team about six weeks of dull, unglamorous migration work that nobody will ever put in a case study.
The whole exercise ran about a quarter. By the end, the team had deleted a meaningful slice of the codebase, and feature work that had been taking three weeks was landing in about four days. Nobody worked harder. The product finally knew what it was.
The code was never the debt. The avoidance was.
When it really is the code
I want to be careful here, because this newsletter has a thesis, and it would be easy to bend every story toward it.
Sometimes the code actually is the problem. I have walked into engagements expecting to find postponed decisions and instead found a genuinely bad architecture choice made by a contractor who left years ago. I’ve also found teams that really were underperforming and needed different management, not a decision list. The costume test isn’t “it’s never the technology.” It’s a question you ask first: is there a decision that would make this problem smaller, before we spend money on the technical fix? When the honest answer is “no, the thing is just broken,” fix the thing. That happens. It’s just rarer than the invoices suggest.
The one-month test
One more pattern from recent work, and a way to test for it yourself.
In two separate engagements this month, the operational mess everyone complained about turned out to be absorbed by a single person. In one company it was a finance manager whose personal spreadsheet reconciled numbers that three departments depended on. Nobody upstream knew the spreadsheet existed, because it had never failed. She had built it years ago, maintained it well, and never mentioned it because to her it was just part of the job.
Two cases is two cases, not a law of nature. But the test costs ten minutes in your next staff meeting. Ask each team: if one person were out for a month, no notice, no phone, what would break? Then watch the room. The name people glance toward is a load-bearing wall you didn’t know your building had. Write down every name and every “it depends” you hear. That list is a more honest map of your operational risk than your org chart. And the fix doesn’t take a consultant. It takes sitting with that person, while things are calm, and getting what’s in their head onto paper. Not to replace them. To stop leaning the building on one wall.
A tool, when it’s ready
I’m turning this material into a short self-assessment called the Technology Decision Scorecard. Twelve statements, about ten minutes, and it hands you back a number for how much deferred decision-making your company is carrying. The download isn’t wired up yet. If you want it now, reply to this email and I’ll send it to you directly while I finish that part.
A question for you
Think about the last thing at your company that got blamed on technology. The slow tool, the failed rollout. What decision was actually underneath it, and whose was it to make?
Hit reply and tell me. If you’re not sure, ask whoever complained about it most recently. In my experience they know exactly which decision it was, and they’ve been waiting a long time for someone to ask them. I read every response, and the best ones become future issues, always anonymized. Knowing who’s on the other end of these shapes what I write next.
If this issue was useful, forward it to one leader you know who keeps blaming the software.
See you next week.
Phillip