Your AI pilot went beautifully. The demo was clean, the output was impressive, the room was sold, and the budget for the next phase got approved. That is precisely the outcome you should be most suspicious of, and the reason is not cynicism. It is that a pilot engineered to succeed cannot tell you whether the thing actually works, and most pilots are engineered to succeed. The polished demo that convinces everyone is, more often than not, the least informative result a pilot can produce. This is one of the most expensive misunderstandings in enterprise AI right now, and the numbers around it are stark. Industry research consistently finds that more than 80% of enterprise AI proofs of concept never reach production, and MIT's 2025 work found that the large majority of generative AI pilots deliver no measurable impact at scale. The striking part is what these failures have in common: the pilots usually worked. They demonstrated value in the room. Then they collapsed on contact with ...

Replatforming decisions almost always get made at the worst possible moment, and there is a structural reason why. The conversation about replacing a core system rarely starts because someone calmly concluded, in a quiet quarter, that the time had come. It starts because the pain got loud. A bad close, a failed audit, a growth push the current system could not support, a breakdown that made the limitations undeniable. The pain reaches a threshold, the organization decides it has had enough, and the mandate comes down: fix this, now. That trigger feels like decisiveness. It is actually a trap, because the moment the pain peaks is, with remarkable reliability, the moment your organization is least equipped to execute the fix well. The conditions that make a replatform succeed and the conditions that make the pain unbearable tend to occur in opposite phases. So "now, because it hurts now" is not the responsible answer it feels like. It is the timing most likely to turn a justified ...

"Good enough" is used as an insult. Say a system is good enough and it sounds like a shrug, a settling, an admission that you gave up before you got it right. In most enterprise technology conversations, the phrase is something you defend against, not something you aspire to. Nobody puts "we built a good enough system" on a slide. They put "best in class." This is a costly confusion, because in the disciplines that have studied the question most carefully, "good enough" is not the lazy answer. It is the rigorous one. The pursuit of the perfect system, the endlessly customized, fully optimized, every-edge-case-handled ideal, is one of the most reliable ways to waste money, time, and organizational energy on technology, and what sinks most enterprise software projects isn't a lack of ambition: it's too much of it. Learning when good enough is genuinely the right call, and being able to tell it apart from mere corner-cutting, is a leadership skill worth more than most of the perfection ...

Most decisions a CEO makes are reversible, and the good ones treat them that way. You try a vendor, a market, a pricing change, a hire, and if it does not work you unwind it at a cost you can live with. The reversibility is what lets you move fast. When the downside of being wrong is "we change it back," you should decide quickly, because deliberating at length over a choice you can cheaply undo is just expensive caution. A small number of decisions do not have this property. They are the ones where being wrong is not a matter of changing it back, because changing it back has become prohibitively expensive by the time you would want to. Your core operating and financial platform, the system your company actually runs on, is one of these, and treating it like the reversible kind is one of the more costly category errors a CEO can make. Reversibility is the property that should decide how you decide The reason this matters is not that platform decisions are important. Plenty of ...

There is a moment, early in every ERP implementation, that decides more about the next decade than almost anything on the contract. Someone demonstrates the new system, and a manager says, reasonably, "that's not how we do it here." The platform is flexible, the vendor is eager, the budget is fresh, and so the decision gets made, quietly and many times over, to bend the new system until it works the way the old one did. Every one of those decisions feels like diligence. Together they are often the most expensive mistake in the project, and the mistake is not technical. It is a leadership mistake about what you were buying in the first place. Because here is the uncomfortable reframe. When you buy a mature, standard platform, the thing of value is not that it can be shaped to mirror your existing process. It is that it embodies a standard, tested way of working that thousands of companies have already refined. The standardization is the asset. When you customize it heavily to reproduce ...

Ask most boards how they are overseeing their company's use of AI and you will get some version of the same answer, delivered a little sheepishly: we are not really technical enough to get into that, so we rely on management. It sounds like humility. It is actually an abdication, and an increasingly dangerous one, because it rests on a misunderstanding of what board oversight has ever required. Oversight was never about technical fluency. A board does not need to understand how a jet engine works to oversee an airline, or how a clinical trial is designed to oversee a pharmaceutical company. What it needs is to ensure that management has a system for identifying the risk, competent people accountable for managing it, and a way of surfacing problems to the board before they become crises. That is a procedural duty, not a technical one, and it applies to AI exactly as it applies to everything else the board oversees without being expert in. The "we're not technical enough" excuse quietly ...

Somewhere in your operation there is a job that runs every night while everyone is asleep. It pulls data out of the property system, reshapes it, and pushes it into the accounting system, so that in the morning the numbers line up and the reports run and the day proceeds as if the two systems were one. Most people in the building do not know it exists. The ones who do refer to it by a nickname, or by the name of the person who built it, or simply as "the sync." No line on any org chart mentions it. No one's job description includes it. And if it stopped running tonight, a meaningful part of the company would not be able to trust a single number tomorrow. That job, the integration, the middleware, the scheduled export, the reconciliation script, is worth thinking about carefully, because it occupies a strange and dangerous position. It is one of the most load-bearing things in your operation, and it is almost certainly owned by no one. Load-bearing and unowned is the worst combination ...

Here is a situation you may have already lived through, or will soon. An AI tool produces something for you: a summary, a variance explanation, a draft response to an owner, a number. It looks right. It is well-written, confident, specific. You are busy, it saves you twenty minutes, so you pass it along or act on it. Days later it turns out to have been wrong. A figure was invented, a fact was off, a nuance that mattered was missed. And here is the part worth sitting with: the mistake does not have the tool's name on it. It has yours. This is the asymmetry that most conversations about AI in the workplace skip past, and it is the one that matters most to a manager. When AI works, the organization gets the benefit. When it fails, the individual who used it absorbs the cost. The vendor is not in the room when your regional director asks why the owner got bad information. You are. An AI is a delegation to something you cannot hold accountable Think about what happens when you delegate a ...

When a unit sits empty, the explanation is usually the market. Demand is soft, the comps came down, the season is slow. Sometimes that is true. But it hides a second number underneath it, one that has nothing to do with the market and everything to do with your operation: the days a unit sits vacant not because no one wants it, but because it was not yet ready to rent, or was ready and no one moved it to the next step. Those days are pure operational loss, they are entirely within your control, and most operators never measure them, because they hide in plain sight, one unit at a time, across the whole portfolio. Separating those two kinds of vacancy is one of the higher-leverage things a COO can do, because one of them is someone else's problem and the other one is yours. Put a number on the part that is yours The controllable loss feels small because you never see it in aggregate. You see one unit, empty for a couple of extra weeks, and it does not feel like a crisis. Multiply it ...

There is a well-worn playbook in the property technology sales cycle. The pitch focuses almost entirely on the base license cost, the simple per-unit, per-month fee. The pricing page looks remarkably clean, the initial setup feels lightweight, and the software appears to check all the standard boxes for a fraction of the enterprise alternatives. For an operations director or a finance leader under pressure to preserve margin, it looks like an easy win. But in enterprise software architecture, there is a brutal reality: the sticker price is almost never the total cost. In property management, entry-level, low-cost software options are frequently engineered around what amounts to a hostage pricing model. They win the initial contract with hyper-competitive entry rates, wait for your operations and tenant data to become deeply embedded in their infrastructure, and then systematically monetize your dependency. The cost you avoid on day one is simply deferred, returning over the life of ...