Cheap to Build, Expensive to See.

A field observation from conversations with 30+ engineering leaders at growth-stage technology companies.

The goal of every engineering organization is the same goal as every other function in the company. Generate cashflow or protect it. Engineering does not get a different scoreboard.

Yet modern engineering organizations are accumulating operational blind spots faster than their tools can surface them, and those blind spots are increasingly the place where cashflow is being made or lost.

Three patterns have appeared often enough in conversations with CTOs and engineering leaders to warrant attention from any executive leadership team.

One. The data engineering leaders bring to board meetings understates what is actually happening inside their organizations.

Two. A significant share of engineering work is occurring in spaces current tools were not built to capture.

Three. The cost of verifying engineering output has shifted dramatically toward the most senior people on the team, and the dashboards that report on engineering performance do not show this cost at all.

None of these are technology problems. They are operational design problems with technological symptoms. The cost of leaving them unaddressed shows up on the P&L, just not always in the line item leadership expects.

Three shifts have made the visibility deficit more acute than at any point in the last decade.

The first is the adoption of AI-assisted code generation. Engineering leaders now manage organizations where a significant percentage of merged code was authored substantially by an AI agent. Most engineering management platforms have no concept of generation source. Decisions about review thresholds, ownership, and post-incident accountability are being made on incomplete records of what humans actually built.

The second is the distribution of operational decisions across communication channels legacy tools never intended to interpret. In conversation after conversation, the same pattern surfaces. The coordination that determines whether two teams collaborate or duplicate happens in Slack DMs, asynchronous documents, and side conversations no project management system captures.

The third is the compression of board-level expectations around engineering performance. CTOs and VPs of Engineering report rising pressure to articulate engineering output and risk in financial terms, at the same cadence other functions have been required to do so. The tools they have been given for this were designed for engineering managers, not for board members.

There is a generational shift underneath this. Engineering used to be the function the board left alone. The company let engineers work on their own schedule and judged the result largely by whether the product worked, because the output was hard to evaluate from the outside. AI changed that. The board does not care whether the code was hand-written or generated. It cares whether the code created cashflow. And under genuine uncertainty about what AI will do to the cost structure of software development over the next twenty-four months, the pressure to adapt is real. Engineering leaders are being asked to defend their function in terms the function was never designed to be defended in.

For most of software's history, engineering was measured on three things. Price, time, and effort. How much did it cost. How long did it take. How many people did it require. Every engineering management framework built between 2000 and 2022 was a refinement on those three measures. The iron triangle held because each leg was expensive enough to constrain the others.

AI collapsed the triangle. Generation got cheap. Iteration got fast. Headcount stopped being the binding constraint on output. The three measures that organized engineering management for two decades are no longer the measures that decide whether a release matters.

What replaced them is cashflow contribution. Did the work make money. Did it save money. Did it create future optionality or close it down. Engineering leaders are now being asked to answer those questions for output their tools still measure in commits, story points, and velocity. The questions are new. The instruments are not.

The result is that engineering leaders are increasingly making consequential decisions on data that arrives after the decision was already made. Several leaders described variations of the same scenario. A board meeting in which a question was asked about retention, customer impact, or competitive position. The answer given diverged from what they later learned was actually happening on the ground.

One leader described discovering that a senior engineer had been on a six-week trajectory toward resignation. It was visible in calendar patterns, Slack engagement, code review participation, and asynchronous response time. None of the tools used to monitor engineering health surfaced it. The first signal anyone saw was the resignation letter. The cost was not the resignation itself. It was the four months of recruitment, onboarding, and lost velocity that followed.

This is not a measurement failure. It is an architectural one. Most engineering tools surface what has happened. Few are designed to surface what has stopped happening. Almost none translate either signal into the cashflow language the board now expects.

Coordination used to happen at the water cooler. Then it moved to Slack. Now a meaningful portion of it happens between humans and AI agents in tools the rest of the team never sees.

That progression would be manageable if every function had moved in step. They have not.

When the product team adopts AI before engineering does, product is producing PRDs three times longer than they were a year ago. Engineers and managers are now expected to read and absorb those documents at the same cadence they read short ones, because the work they describe still has to ship. Design moves the same way. AI-generated specs, AI-generated rationale, AI-generated dependency notes. The reader on the receiving end of all of this is the engineering manager, who is also expected to review AI-generated PRs, AI-updated tickets, and the Slack threads where coordination still happens to live.

Slack used to be a thrash. Hard to read but humanly possible. Now it is a thrash overlaid with AI-summarized updates, AI-drafted responses, and AI-coordinated handoffs that humans are nominally responsible for approving. The reading load is not the same as it was twelve months ago. The reading hours in a day are.

The consequence is what might be called the coordination tax. Work gets duplicated because the document that would have prevented the duplication was too long to read. Dependencies are negotiated and forgotten because the message acknowledging them was buried under fifty other AI-augmented messages. Decisions are made and never absorbed because absorbing them was no one's job.

Detecting any of this requires manual triangulation across systems, usually performed by a senior leader or chief of staff. The triangulation itself is now slower than it was a year ago, because each system contains more text per unit of actual decision. Few organizations have automated it. None of the ones doing it manually have time to keep doing it manually for much longer.

The work to build the team's output got cheap. The work to see what the team is doing did not.

Software engineering used to have a stable ratio. For every hour spent writing code, roughly an equal hour was spent reviewing it. Code review, testing, debugging, and quality gates were where the senior engineers spent their time, and the cost of that work was understood as the price of producing software anyone wanted to use.

That ratio held because the cost of generating code was high. Senior engineers spent enough time writing that they were paid to also spend time reviewing. The whole budget worked because writing and reviewing were performed by the same people on roughly similar timelines.

AI broke the ratio in one direction. Generation got cheap. Verification did not.

Today, engineering organizations are generating significantly more code than they were eighteen months ago. GitHub Copilot users have reported generation gains as high as 55% on controlled tasks. The headline number is contested. The direction is not. The work to verify that code is correct, safe, and worth merging now lands almost entirely on the most senior people on the team. Those people are also the most expensive and the least replaceable. The cost of verification is now disproportionate to the cost of generation, and it concentrates on the smallest population of the engineering org.

Engineering leaders describe versions of the same scenario. Leaders have described staff engineers moving from roughly twenty percent of their week on review to closer to sixty. A principal who used to mentor juniors now spends most of their time validating AI-generated PRs that look correct and are not. A senior who used to ship features now functions as a quality gate for output produced by people they barely interact with.

None of this appears in standard engineering reporting. The commits closed and the PRs merged both went up. The hours that produced those numbers shifted from the engineering org as a whole to a thin band of senior people at the top of it. When those people leave, or burn out, or stop wanting to do that job, the cost of verification does not disappear. It comes due all at once.

The cashflow consequence is direct. The most expensive labor in the engineering org is now allocated to verifying output the dashboard counts as already shipped. That allocation is invisible and unattributed. The board sees the velocity. It does not see the staff engineer who is doing the work that makes the velocity possible.

Three implications for organizations with engineering teams of 50 or more.

Current observability is a partial signal. The data presented in standard engineering dashboards represents a subset, sometimes a small subset, of what is actually happening operationally. Decisions made from this data alone are understating risk. The action this week is to add one cashflow-relevant question to your next staff or board meeting and notice whether your current reporting can answer it.

Cross-system synthesis matters more than tool consolidation. Several organizations have tried to address the visibility deficit by consolidating onto a single project management platform. None have reported it working. The synthesis layer that matters operates across systems, not within one. The action this week is to identify the one person on your team who is doing the manual triangulation today and ask them what they cannot get to.

Account for verification cost separately from generation cost. The two are now distinct activities performed by different people at different rates. Reporting that lumps them together obscures where the expensive work is actually happening and who is doing it. Engineering organizations that do not track this will discover the cost only when a senior person leaves and the work they were silently doing surfaces all at once. The action this week is to ask each of your senior engineers how much of their time goes to validating AI-generated work, and write down the answer.

The next eighteen months will see a gap open between organizations that have begun to systematically address the visibility deficit and those that have not.

The gap will not appear in productivity metrics. It is invisible there by construction. It will appear in retention, in board-level confidence, in the trajectory of decisions made in the moments between board meetings, and most consequentially, in cashflow that either materializes or does not.

For engineering leaders at the level of CTO or VP of Engineering, the operational reality your tools describe is not the operational reality you are accountable for. The board does not need engineering output measured in commits or velocity. It needs engineering output measured in money made and money saved. The gap between the two is the next frontier of engineering management, and the work it represents is no longer optional.

This is one cut at a moving target. I am wrong about parts of it and I would rather know than not. If your experience contradicts any of the three patterns, send me a note. The argument gets sharper when it gets challenged.

Eli Landon is the founder of Zamski. zamski.com