The CTO has always kept a junk drawer of known tech debt. A messy but contained space.

But something has shifted. GenAI and low-code tools have made building software cheap and fast. Everyone is now a builder. We’ve traded the difficulty of writing code for the difficulty of managing its consequences. The New York Times named it the ‘AI Mess’ era.

That junk drawer has spilled out into the hallway. It’s blocking the exits. What used to be the CTO’s (well) contained problem is quickly becoming the CEO’s hoarder house.

The CTO’s team can’t see what’s being built and doesn’t know what the intended behavior is. The business leaders who asked for it have moved on to the next priority. The builders themselves don’t know that what they created carries an ongoing operational obligation.

The decision hasn’t been made because most organizations haven’t realized there’s a decision to make.

John Willis, co-author of the DevOps Handbook, argued at the 2024 Enterprise Tech Leadership Summit that we’re going down the same road as Shadow IT, but faster and with more surface area. He’s right. What’s accumulating now is debt that doesn’t know it’s debt. The builder of that customer-facing workflow doesn’t know she’s created something that needs monitoring, maintenance and an eventual retirement plan. And the longer the ownership question stays unanswered, the more expensive the answer gets.

Engineers spent two decades building the discipline of managing what gets created, who maintains it and when to turn it off. Most of those learnings never left the engineering org. They need to.

“You build it, you run it.”

Twenty years ago, Werner Vogels made the case in six words. The DevOps movement turned them into a discipline.

Before Vogels, the model was simple: developers wrote code, threw it over the wall to an operations team and moved on. When the code wasn’t deployed fast enough, developers blamed operations. When it broke at 3am, operations blamed developers for shipping something that wasn’t built to survive outside a test environment. Everyone blamed the other side.

I remember the specific 3am page that broke my patience.

My phone buzzed on the nightstand. I was one of four people with the access rights to resolve a particular type of catastrophic integration failure. We had been trying to manage this known issue with processes and checklists, but one month I had four middle-of-the-night wake ups. I had enough. I called a meeting. We dug into the code and finally introduced validations that prevented the issue in the first place.

Vogels’ “You build it, you run it” philosophy fixed this by collapsing build and maintain into one accountability. When you own what you ship, you build differently. You think about failure modes. You write documentation your future self can actually use. Launch day is no longer the finish line.

The principle isn’t “builders should also do maintenance.” It’s deeper. Separating the people who create from the people who maintain always produces dysfunction. Always. The creator optimizes for shipping. The maintainer inherits problems they didn’t create and can’t fully understand. The feedback loop that would make the next version better never forms.

Now apply that to AI-built artifacts. The marketing analyst who automated a reporting workflow isn’t thinking about what happens when the data source changes, when the logic needs updating, or when someone needs to debug it at quarter-end. She built it. It works. She moved on. The ownership question never occurred to her, because in her world, building has never carried a trailing obligation.

Principle: You build it, you run it.

Translation: Ownership includes the trailing obligation of monitoring and maintenance.

Risk: Someone gets a quick win. The organization gets a lifetime subscription to a bill nobody knows how to pay.

You can’t manage what you can’t see.

Long before I arrived, a sales team at one company contracted with a low-code automation vendor to send files to their customers. Engineering was resource-constrained. Sales needed a solution. But there was no observability. No way to see what was actually happening inside the black box. When a customer didn’t get their file, someone would just send it again.

Over the years, they kept building. The issues got worse. It wasn’t just missing files. It was the right file to the wrong customer. The wrong file to the right customer. The underlying data was sensitive. Customer trust was eroding. Potential fines and legal action.

Then my team inherited the problem.

Charity Majors, a pioneer of modern observability, argues you haven’t truly seen your system until you can interrogate it without knowing what you’re looking for in advance. When my team inherited this mess, our first move wasn’t fixing the code. It was building the ability to interrogate it.

Most organizations cannot currently answer basic questions about their AI-built artifacts. What exists? Who built it? What does it depend on? Is anyone still using it? What breaks if it goes down?

If you can’t answer those questions about your engineering systems (and many organizations can’t, even now), you definitely can’t answer them about the automations, dashboards and workflows being built across every function.

Principle: You can’t understand what you can’t see.

Translation: Ownership means you can’t build a black box.

Risk: You replastered the leak on the ceiling, but never checked the pipes. You won’t know which pipe is leaking until the ceiling falls in.

Build with boundaries, or everything becomes load-bearing.

You know that feeling when you open a spreadsheet and it’s suddenly full of #REF! errors? You’ve opened that tab a hundred times, but this time something upstream changed and now you’re reverse-engineering which cells pointed where and what broke. That’s a dependency chain.

Now imagine the same dynamic, but instead of spreadsheet cells it’s automations and workflows running across departments. Instead of broken formulas it’s processes that fail silently until the impact is too big to ignore.

These connections grow “one quick fix” at a time, until the system develops a shape nobody designed and nobody can see.

Carliss Baldwin showed that how you partition a system determines where change stays possible.

• Build with clear boundaries between components and you can maintain, update and retire them independently.

• Build without boundaries and every piece depends on every other piece, even the parts nobody uses anymore.

Modularity isn’t an engineering concept that only engineers should care about. It’s the principle that determines whether your organization can change its mind later without breaking everything that came before.

Principle: Build with boundaries, or everything becomes load-bearing.

Translation: Partitioning determines where change stays possible.

Risk: A minor marketing tweak becomes a Finance catastrophe. Without boundaries, everything is load-bearing.

Maintenance is not cleanup. It’s part of the work.

Tidy First? reframes the relationship between building and maintaining. The instinct is to build first, clean up later. Kent Beck’s argument: tidying, the small ongoing structural improvements, is a first-class activity. Not something you do when the mess becomes unbearable. Something you do before you build the next thing.

And it’s not just “tidy or don’t.” In his book, Beck maps four choices:

• tidy first (when cleanup makes the next change easier),

• tidy after (when the code works but is harder for the next person to read),

• tidy later (when you’re under a hard deadline and the mess isn’t blocking you), and

• tidy never (when the code works and you’re never going to touch it again).

That framework matters because each of those is a decision. Engineers struggle with this discipline even when they understand it intellectually. For non-engineers building with AI and low-code tools, the decision doesn’t exist at all. They’re not choosing “tidy later.” They don’t know there’s a choice to make.

And then there’s the decision engineers struggle with most: when to turn something off entirely. I’ve never been on a team that did deprecation well. Code that nobody uses stays running for years because turning it off feels riskier than leaving it alone. The surface area for incidents and vulnerabilities grows quietly. The hoarder house gets a shed in the backyard.

If engineers, who understand deprecation and have tools designed for it, still can’t bring themselves to turn things off... what happens when the new builders don’t realize code retirement is a concept at all?

Principle: Tidying now reduces the need for a “deep clean” later.

Translation: Maintenance isn’t cleanup. It’s a structural decision to prevent operational paralysis.

Risk: You live in a hoarder house. You spend 80% of your energy keeping junk alive until there is no room left for actual growth.

The bind

How organizations assign monitoring, deprecation and incident ownership was designed for engineers. Someone who understood that shipping was the beginning, not the end. Nobody designed it for a world where everyone builds.

Setting up the marketing team with an incident management rotation for their AI-generated workflows is overkill. But routing everything back through the engineering org isn’t the answer either. Engineering can’t maintain what they can’t see, didn’t design and don’t understand the business intent behind.

Restricting who can build defeats the point. GenAI and low-code tools have genuinely reduced the cost to create, and the people closest to the problem are often the right people to build the solution. But the cost to create and the total cost of ownership are different equations. Organizations are celebrating the first while ignoring the second.

Nobody has a clean answer to where ownership lives when builders are everywhere. That’s not a gap in the literature. It’s a genuinely new organizational design problem, and anyone who tells you otherwise is selling something. What’s certain is that the question has to get asked now, while the accumulation is still manageable. Because the interim is going to be messy regardless: things will break and nobody will know what broke, when it broke or whose problem it is.

If you allow a team to build a load-bearing process without the obligation to maintain it, you aren’t being agile. You’re just borrowing stability from the future at a predatory interest rate.

The hoarder house isn’t inevitable. But it requires asking the hard question today: If this automation breaks at midnight, who is going to fix it?

A sincere thank you to Gene Kim, Jeff Gallimore and the IT Revolution community. Their years of work translating hard-won engineering principles for a leadership audience long before GenAI arrived gave me the vocabulary to recognize these patterns. They’re the cartographers; I’m just trying to share their map.

I’m Clare Hawthorne. I fix friction at the seam between technology, finance and go-to-market.

Subscribe now

Share

It feels decisive. It looks like progress. It demos well for the all-hands.

But standards in the wrong place produce process theater: everyone follows the process, but the process doesn’t produce anything useful.

Most processes have layers. Think of an egg:

• There’s the egg white. It’s the part that moves information between people and teams. Routing, handoffs, status reporting, dependency tracking.

• And there’s the yolk. That’s the part where people actually figure things out. Prioritization, tradeoff discussions, leadership reviews.

Well-designed processes are a soufflé. You need both parts of the egg, but carefully separated and handled differently.

Standards help coordination. They reduce the cost of moving information by making handoffs predictable and routing legible.

Judgment works when people adapt to what’s in front of them. Standardize it and you replace their context with your template. And your template doesn’t know their situation. You can tell people to use their judgment, but the template is louder.

If you don’t tease apart the layers, you’ll end up with broken yolks and overhead.

A new CTPO needed visibility into initiatives across the technology organization. People asked for a template. I built one: what you shipped, where the CTPO could help, red/yellow/green on your OKRs.

First cycle was great. The CTPO was engaged, pressure-testing, asking hard questions. But after he’d been through each initiative once, the meetings started to drift. Nobody brought anything that didn’t fit the format. The template had gone from guidelines to tight guardrails.

Within a quarter, delivery updates had replaced the leadership review entirely. A perfect example of process theater.

One day a product director Slacked me before her presentation. She’d already shared her updates at a cross-functional SteerCo earlier that week and didn’t know what to present. So I asked: “What’s actually keeping you up at night? You have 30 minutes with the CTPO and his leadership team. What would be the most valuable use of that time?”

She walked in with an extra slide and looked to me for reassurance that it was okay to go off-script (and the fact that she felt she needed my permission says a lot).

What she told the room stopped the meeting cold.

They hadn’t closed a new customer in six months. The team was going to miss their annual revenue target. The roadmap was focused on hardening and scaling, but they hadn’t found product-market fit. Everyone was scared to pivot because it felt like admitting defeat.

For the first time in that meeting, people were thinking together rather than presenting at each other. The CTPO was back to pressure-testing. The VPs jumped in with questions and suggestions. Nobody was looking at their laptop.

The CTPO asked why nobody had raised this sooner. She shrugged. Projects were technically on track. Engineering was shipping on time. But nobody was buying the product.

By the end of the session, her team had thrown out their quarterly plan. Not a tweak. A full pivot to customer acquisition.

And I threw out the meeting template. One question replaced the entire structure.

The room already had the information it needed. But presenters needed permission to surface hard conversations. My template defined what counted as a legitimate topic, and the real problem didn’t fit the format.

That’s the dangerous part about standardizing judgment. It doesn’t blow up on day one. It calcifies. The process works at first, then quietly starts defining what counts as legitimate. The things that don’t fit the format disappear from view. And because everyone’s still following the process, nobody flags it.

The question I should have asked before building that template: is this process moving information, or producing decisions? Mine was producing decisions. I standardized it anyway.

Once you isolate the coordination layer, ask yourself if you’re standardizing costly or cosmetic divergence?

Costly divergence means the inconsistency is causing real operational failures. Requests get lost. Routing breaks. Leadership can’t see across teams. Work falls through cracks.

Cosmetic divergence means the coordination works but looks different across teams. Different sprint start dates. Different dashboard layouts. Different field names for the same status. As long as nobody’s losing requests or missing handoffs, let teams be the special snowflakes they think they are.

I applied this lens when redesigning a product intake system. Requests were going to the wrong team, sitting in limbo. Leadership had no visibility into volume or turnaround. The costly divergence was apparent: requests disappeared into black holes and nobody tracked anything.

My team member leading the implementation knew we had to accommodate team nuance. His plan was to build our “intake domestic policy”: his design would account for different states, but still maintain shared laws and infrastructure.

But as he gathered requirements from each product team, the picture shifted. These weren’t states. They were countries. Different customer types, different definitions of urgency, different triage logic. The shorthand stuck. Every time either of us got pulled toward over-standardizing, the correction was instant: “design for countries, not states.”

So we were surgical about standards: a single entry point, shared routing, SLA tracking that rolled up for leadership. Shared borders and a common currency. And left the judgment local. Each team kept their own intake form, their own triage logic, their own definitions.

We even isolated the cosmetic layer: field ordering, dashboard layout, whether work happened in the original ticket or a linked one. We didn’t have a reason to care, so we let those vary.

Leadership got a rolled-up view without requiring every team to ask the same questions. From above, it looked like one system. From inside each team, it felt like theirs.

Both stories started with a broken process and the instinct to standardize it. In one case the right answer was to strip the standard out entirely. In the other it was to standardize selectively. The difference came down to two questions:

• Is this process moving information or producing decisions?

• If coordination, is the divergence costly or cosmetic?

There’s a reason soufflés earn their reputation as a challenging dish: it’s hard to separate your egg whites from the yolks. But do it carefully, and you’ll design better processes.

Subscribe now

Plus, nobody wants to reinvent how a sprint retro works every two weeks.

I joined a technology organization where the roadmap was roughly 150 projects tracked in a sprawling spreadsheet. Every 4-5 months there would be a new piece of information or a critical customer request that required roadmap reprioritization. The CPO couldn’t digest the laundry list of a roadmap, so he’d have to send a blast email out to the product managers asking them to all share a list of current priorities. This request triggered a fire drill that consumed days – first gathering the projects, then figuring out staffing levels, then normalizing the list. Only at that point could he review the list with his direct reports and make the necessary tradeoff calls.

I built a taxonomy that standardized those projects into about 20 initiatives. The next time we needed to reprioritize, we were ready. He could scan the 20 initiatives, see the resources allocated to each one and discuss tradeoffs in his staff meeting without any additional prep needed from the PMs.

The fire drills stopped entirely. Not because people got better at communication. Because the standard made the complexity legible.

The fact that standards work is part of the problem. Pretty soon you’re holding a process-hammer and every problem starts looking like a standards-nail.

Some problems are fundamentally variable. The inputs change, the context shifts, the required judgment is local. Standardizing these doesn’t streamline, it doesn’t reduce risk, it doesn’t create connection. Applying standards to the wrong problem doesn’t just create overhead, it can create risk.

A company I worked with had change management controls designed around application-layer changes: screenshots showing the environment, a date stamp, test results, all in one image. Reasonable for teams shipping UI features where changes are visible on a screen. The team documented the process narrative and worked with the independent auditor to confirm the control language. They even got a pat on the back for creating one process that everyone could follow.

But the process designers hadn’t accounted for the infrastructure team. They had to adhere to the same standard, even though their changes didn’t produce screenshots in any meaningful sense. The process didn’t fit their context, so they ended up having to choose between contorting their documentation to produce artifacts that didn’t reflect their actual work or failing the control.

Standards are a tool. A powerful one. But if you apply standards in the wrong places, you’re signing your teams up for operational busywork. And if the wrong standard gets codified into your control framework… the standard becomes unfollowable, the control becomes untestable, and now you’ve manufactured your own audit finding.

This week, I’m presenting “Stop Standardizing the Wrong Things” at the PLA Product Ops Summit. In my next post, I’ll share that framework for isolating where standards can help and where they can hurt.

Subscribe now

Now, add one change. Instead of tracking delivery status, every row is color-coded by how much the team actually knows.

• Blue: scoped, estimated by the people building it, dependencies mapped, open questions answered.

• Purple: directionally clear, but the team has real unknowns they haven’t worked through yet.

• Gray: effectively a placeholder. The work behind it might be three months of discovery or a conversation that hasn’t started.

Now look at your roadmap and recolor it honestly.

Most roadmaps mix all three: blue bars that carried forward from last year, a band of purple where teams have direction but not answers, and gray rows where someone needed to fill a cell during planning. But nobody reading the roadmap downstream can tell which is which. The format doesn’t carry that information.

A roadmap is one of the few artifacts that travels the full organization. Product owns it. Engineering builds from it. Finance maps spend against it. Sales references it in client conversations. The board sees a version once a quarter.

Each audience reads the same document for a different reason, and every reason demands confidence. Finance needs numbers to plan against. Sales needs dates to sell against. The board needs evidence that tech investment reflects strategy. A document serving all those audiences can’t afford a row that says “we’re still figuring this out.”

Every row carries the same weight: a name, a resourcing estimate, a delivery quarter. Nobody chose that design flaw. It’s a consequence of what roadmaps are asked to do.

Nobody announces “we’re treating this open placeholder as a locked commitment.” The format does it automatically.

Exploration dies two ways on a roadmap. Work that isn’t ready to present as committed gets forced into that shape anyway: a rough guess becomes a headcount number becomes a delivery date. Or it never earns a spot at all, because the format has no way to represent “we need to figure this out before we can plan it.”

We had a home-grown internal application I’ll call CompanyLedger. It had been around for years, accumulating processes, workarounds and manual inputs. It ran on spreadsheet uploads, duct tape and people running scripts at 3am (yes, really). It had been flagged by our auditors, so the CEO and CFO both knew it was a liability. A scrum team was already automating some of the billing calculations. The project shot to the top of their roadmap.

Then annual planning asked for a resourcing estimate.

Nobody had mapped what CompanyLedger actually did end-to-end. Different teams had asked the application owner to accommodate their processes over the years, and nobody documented any of it. The only way to understand system behavior was to shoulder-surf as users performed their daily activities.

To estimate resources, you need scope. To know scope, you need to understand the current system. To understand the current system, you need discovery that hadn’t happened yet.

We made an estimate anyway. That’s how planning works.

We’d submitted our “I-think-this-will-be-4-ish-people-of-work” estimate. Now we had to pull the rest of the business case together for leadership. I asked the product manager and engineering manager a simple question: for the “Deprecate CompanyLedger” initiative, at what point will users be fully out of the current system?

They looked at each other, then back at me. They weren’t planning to turn off CompanyLedger. They had never intended to turn off CompanyLedger.

They were deprecating CompanyLedger’s billing module. That’s all they’d ever scoped.

But the roadmap said “Deprecate CompanyLedger.” Internal team shorthand came thisclose to being what the CEO would read. What the CFO would plan around. What the board would anchor on.

We caught it. Changed the name to “Deprecate CompanyLedger Billing.” A small fix, but a critical one. Without it, the roadmap would have told the organization a story that wasn’t true. Not because anyone was lying. Because nobody had stopped to check whether the words on the slide matched what the team was actually building.

But by the time we caught the scope problem, the resource commitment was already in. The rough estimate had already hardened into a headcount allocation.

This is where planning processes quietly do their damage. The estimate goes in as a rough guess. It comes back as four people on a roadmap with a delivery date. The format doesn’t distinguish between “we’ve sized this carefully” and “we threw a number in because the spreadsheet needed one.” Both look the same on the slide.

Where the roadmap worked: as a shared artifact that forced the conversation.

Where it failed: distinguishing between “we’ve scoped this” and “we’re still figuring this out.”

On that imaginary recolored roadmap, this row was deep gray from the start. The team knew it. Nobody reading the roadmap could see it.

CompanyLedger took the first path. It earned its roadmap slot by pretending to be concrete. The initiatives that take the second path never show up at all. They’re the discovery effort nobody funded, the investigation that couldn’t compete for a row because it didn’t have a delivery date to offer. You can’t recolor what isn’t on the board.

The instinct here is to fix the format. Add a confidence column. Build a discovery track. Create intake stages. Those aren’t wrong, but they only work if the organization actually believes that not knowing yet is a legitimate stage of work rather than a failure to plan.

Discovery isn’t delay. It’s where the organization figures out whether a bet is worth making, before committing resources and a delivery date to finding out the hard way. But most planning cultures treat uncertainty as a gap to be flattened. Leaders who surface unknowns get asked when they’ll have answers. Teams that flag open questions get told to come back when they have a plan. The incentive is to project confidence whether or not it’s earned. So the format stays flat, every row looks blue, and the organization loses track of where its own knowledge ends and its assumptions begin.

Roadmaps aren’t plans. They’re conversations. The useful ones make room for what the organization doesn’t know yet. The dangerous ones paper over it.

Next time you’re looking at your company’s roadmap, pick the row you’re least confident in. Ask the team behind it: what do you still need to learn before this estimate is real?

If they can answer that clearly, the row is honest. The team knows what they know and what they don’t.

If the question surprises them, the roadmap has already done its damage. A guess went in. A plan came out. And somewhere downstream, someone is building against it.

Subscribe now

The harder version looks nothing like that. The person is capable. The task is appropriate. The trust is real. Still, something breaks downstream. It doesn’t trace back to any single decision, because the failure wasn’t a decision.

The alignment never happened.

There’s a useful map for this. Jurgen Appelo’s 7 Levels of Delegation describes delegation not as a switch but as a progression: Tell, Sell, Consult, Agree, Advise, Inquire, Delegate. Each step builds something the next step depends on. By the time you reach Delegate, the person holding the work has enough shared context to make calls you haven’t anticipated, in ways that track with what you’d actually want.

The progression exists because ownership can’t transfer cleanly without the steps that build it. Someone might have the right title, the right experience, a track record of good judgment. They still might not have what they need to make good calls in the new context. The task transfers. The context doesn’t.

Not every delegation needs all seven steps. Leaders who’ve worked together for years skip levels all the time, and it works, because shared history fills the gaps.

Gaps get dangerous when that history doesn’t exist: when someone is new, when the problem is unfamiliar, or when the process itself is novel. The danger is that it doesn’t look like failure when it starts.

Here’s an example of that gap in practice.

I was handed the annual planning process a few months into the role. The output was a technology portfolio that the CPO and CTO presented to Finance and the rest of the C-suite. I had credibility from prior experience, so the handoff came with a prior-year artifact, the presentation date and the implicit message: we know you’ve done this before, own it.

I had. And so I did.

I designed the initiative prioritization process to be independent of staffing. My blind spot was that the CPO and CTO cared deeply about team continuity. In their model, an initiative that disrupted existing team composition carried a real cost, one that should inform whether it got greenlit. That assumption never came up in a conversation. I didn’t ask. They assumed I knew.

When the deliverables came in, nothing lined up:

• Some teams treated their current staff as available to be assigned across initiatives.

• Others read my instructions as incremental headcount only and left existing staff out entirely.

• Some had a shadow sheet mapping every person to an initiative because keeping teams intact was how they thought about it.

• The infrastructure lead couldn’t give me anything until he knew what the feature teams were building.

Everyone had acted in good faith. Still, the assumptions never got compared. My process had completely missed what mattered most.

The CPO and CTO had to scramble to get the artifact ready for the C-suite. Two days of Product and Eng SVPs untangling what should have been built into the process from the start. The part that still sits with me: the people who followed my instructions the best had the most rework to do.

That residue doesn’t get cleaned up when the deliverable gets fixed. It persists in ways that look like execution failure, when the actual cause traces back to a conversation that should have happened and didn’t.

The hardest delegation failures don’t start with the wrong person or the wrong task. They start in the window where shared understanding should have been built and wasn’t.

Don’t just delegate; build shared context collaboratively.

Subscribe now

But that’s not when it went wrong. It went wrong earlier. Usually months earlier, in a moment no one remembers because it didn’t feel like a decision at all.

Here’s one of mine:

It was an average Thursday in October. Biweekly product-sales sync. Sales was riding a wave. They’d moved up-market from our typical small-and-medium sized clients, closing four enterprise deals with January start dates. The differentiator was a feature called “job costing.” Think of it as the ability to track costs against specific projects or business units. Big deal for enterprise clients. Sales wanted a status update from Product.

Product jumped in with their “org units” update (a system that mapped those same projects and/or business units inside our platform). More complex than expected, but they felt good about a December launch.

Then I asked: “Just confirming... the org units MVP is going to cover what the enterprise clients need, right?”

Wrong.

Org units was phase one. Job costing was phase two. Sales had sold the complete capability. Engineering was building the foundation. Both teams had been meeting for months, using the same words, meaning different things.

The room shifted. Confusion, then recognition, then something close to panic. We’d sold something we couldn’t deliver. We were screwed.

I’ll come back to how this played out. But first, the pattern underneath it.

The Pattern

It would be easy to call this a communication breakdown. It wasn’t. The communication was constant. The problem was that nobody paused long enough to check whether everyone had the same understanding.

This repeats across organizations, and it has a consistent structure: pressure to move forward, different functions solving different problems in parallel, and the window for sorting out the handoffs closes before anyone realizes it was open.

Two examples:

• A product initiative gets approved during annual planning. The VP of Product greenlights it based on customer demand and revenue projections. Six weeks later, the infrastructure team escalates tradeoffs nobody consulted them on. The database can’t support the proposed design without a migration that adds three months. The commitment was locked before the people who understood the technical cost were in the room.

• Finance needs to know which engineering work qualifies as a capitalizable asset. Engineering works iteratively, in ways that don’t map neatly to those categories. Without a shared way to bridge the gap, engineers end up filling out timesheets as compliance paperwork rather than as a reflection of what they’re actually building. Both teams are doing their jobs. Neither is solving the same problem.

Both follow the same shape. Someone needed to slow down and ask “do we actually mean the same thing?” No one did. Everything felt like it was moving in the right direction.

It’s like building a house with four different contractors who each have their own blueprints. The electrician wires based on one floor plan. The plumber runs pipes based on another. Everyone’s working hard. The work is competent. But when you flip the switch, nothing connects. No one stopped to confirm they were building the same house.

That’s what happens at the seams between functions. Engineering thinks in dependencies. Product thinks in priorities. Sales thinks in timelines. Finance thinks in constraints. Each one fills gaps in their understanding with assumptions. The misalignment only surfaces after contracts are signed, commitments have cascaded, and undoing any of it is expensive.

What Actually Happened

The decision to promise job costing by January wasn’t made by one person. It was a company decision, embedded in revenue forecasts, implementation timelines, and customer contracts before anyone realized the underlying build wasn’t going to support it.

The shortcut was treating “job costing” and “org units” as interchangeable. They weren’t. Org units came first; job costing came second. But that distinction got lost. Sales heard customer needs and relayed them as requirements. Engineering decomposed the technical work and built from there. Product scoped based on level of effort.

Nobody stopped to ask “wait, are we talking about the same functionality?” The moment for that came and went without anyone noticing.

By the time we found the gap, reversing the commitment was more expensive than living with it. Engineering accelerated the org units build. Sales stopped selling job costing. Operations built workarounds for the four clients already committed. It took twelve months to deliver what clients expected in ten weeks.

AI Compresses What’s Already Fragile

Organizations have always struggled with the gap between exploring an idea and committing to it. AI didn’t create that problem, but it makes the gap harder to see.

A leader can pose a question to their LLM of choice, receive a polished and confident answer, and move straight to a decision. Without recognizing that the messy, necessary work of figuring out what they actually mean never happened.

The AI doesn’t know what it doesn’t know about your organization. It can’t flag that your sales team and your engineering team are defining the same term differently. It just builds on whatever you give it.

So, when the underlying thinking is sound, AI accelerates good work. When it’s not, AI makes the problems harder to spot. The output looks clean even when the inputs were unresolved.

The failure isn’t the technology. It’s the unresolved thinking the technology inherits.

Welcome to Call It Early

I’m Clare Hawthorne. I’ve spent my career working across engineering, finance, product, and operations. Usually in rooms exactly like the one I just described, trying to figure out why decisions that seemed sound created problems no one anticipated.

What I’ve found: most organizational failures start between functions, in the phase before commitment. Not in the execution. Not in the people. In the moment when thinking that should still be open gets treated as settled. Sometimes that looks like two teams using the same word to mean different things. Sometimes it looks like a roadmap that locks in a bet before anyone pressure-tested it. Sometimes it looks like a leader handing off authority without defining what comes with it. We all talk about alignment, but that’s the step that gets skipped when everyone’s under pressure to move. And almost nobody notices until it’s too late.

Call It Early is about that moment. Timing, judgment, and the structural conditions that shape decisions before they become irreversible. If you’ve been sensing a pattern you can’t quite name yet, you’re probably right. And you’re probably not looking early enough.

What looks like momentum is often premature closure. Call It Early is about learning to spot it before it hardens.

Subscribe now