There’s a conversation that happens at a lot of companies somewhere between 50 and 150 people, and it goes the same way almost every time. The CEO asks the VP of Engineering, or whoever the de facto tech lead is, for a status update. The answer is some version of “the team is heads down,” “we’re making good progress,” or “we hit a few snags but we’re back on track.” The CEO nods and the meeting moves on. Then, on the drive home or in the shower the next morning, the thought surfaces: I actually have no idea what’s happening over there.
Trust that instinct. Not because your engineers are lying to you (most aren’t), but because the conditions that produce that kind of answer are structural. They’re predictable, and they won’t fix themselves.
Engineering Teams Don’t Report Problems They Don’t Know How to Frame
The first thing to understand is that optimism in engineering usually isn’t spin. It’s the default.
Engineers almost always underestimate complexity, and it isn’t incompetence. It comes from how technical work unfolds. A task that looks simple from a distance usually has dependencies, edge cases, and integration points you only see once you’re inside it. Teams schedule the work they can see, then reality adds the work they couldn’t. The timeline slips, they recalibrate, they call it a one-off, and they believe it.
The second issue is the lack of any benchmark. Without an outside reference point, a team has no reliable way to know whether its pace, code quality, or architecture decisions are below par. It’s comparing itself to itself, and if the system mostly works and nobody’s yelling, everyone assumes things are fine. DORA’s State of DevOps research shows high-performing teams deploy far more often and recover from failures much faster than low and medium performers. Most teams without strong technical leadership have never seen that data, let alone measured themselves against it.
Third, there’s the career math of delivering bad news. In most organizations, and not just in engineering, taking a problem upward without a solution feels risky. So problems get held and worked on quietly until they seem manageable or become impossible to hide. By the time a real issue reaches a leadership meeting, people inside the team have often known about it for months. People everywhere filter what they report upward based on how safe it feels to be honest. Engineers aren’t unusually dishonest. They’re human.
The fourth issue gets talked about least: the executive asking the question often doesn’t have the vocabulary to ask a better one. “How’s it going?” gets you “fine.” If you don’t know which questions would draw out a real answer, you won’t get one. That isn’t a criticism. It’s a gap most companies without a CTO simply aren’t set up to close.
The Signals That Are Actually Worth Paying Attention To
You won’t find these in a status report. You’ll notice them if you’re paying attention to the right layer of the organization.
Timelines slip again and again, each time for a different reason. The database migration ran long. A key engineer was out sick. An integration was harder than expected. Any one of those is plausible. When you hear a version of it every quarter, the explanations are covering a pattern, not describing isolated events.
Something has been “almost done” for far too long. I’ve walked into companies where a platform rewrite or a major feature had been two weeks from done for three months. The team usually isn’t stalling on purpose. More often they’ve hit something genuinely hard and don’t know how to say so without it sounding like failure.
Technical debt comes up in every honest conversation and in none of the planning ones. You’ll hear “we need to clean that up” or “that’s on the list.” Ask when it’s scheduled and who’s doing it. If neither question gets a real answer, the debt isn’t being managed. It’s being tolerated while it grows.
New vendors and tools appear without any visible decision. A new platform shows up in the budget, or an engineer mentions a tool you’ve never heard of, and when you ask why it was chosen the answer is vague. Teams should make tool decisions, so that alone isn’t a problem. But when those decisions happen with no criteria or written reasoning, technical governance isn’t working.
Security, compliance, and infrastructure keep getting pushed back. I’ve heard “we’re planning to address that” in front of boards, investors, and executive teams, about issues that were quietly known to be serious. Postponed infrastructure conversations tend to turn urgent at the worst possible moment.
Engineers are leaving, and the explanations are always pay or culture, never technical direction. Exit interviews are imperfect, but if you lose two or three strong engineers in a year and every reason is money or flexibility, it’s worth asking whether those are the real reasons. Strong engineers will leave an interesting problem for more money. They’ll leave a poorly run one for almost any reason.
The team can’t explain the business priority behind what it’s building. This one is underrated. Ask a few engineers what they’re working on and why it matters to the company. If the answers are vague, disconnected from business results, or different from person to person, engineering isn’t aligned with the business. That’s a leadership problem, not a communication problem.
The most important signal on that list is the last one, even though it sounds the least dramatic. I’ve sat in engineering reviews where the team had impressive technical work underway that had almost nothing to do with what the company needed that quarter. Nobody was lazy or acting in bad faith. There just wasn’t anyone in the room whose job was to connect the two.
This Isn’t an Engineering Problem. It’s a Leadership Vacuum.
It’s tempting to look at these signals and decide you have an underperforming team. That’s usually the wrong diagnosis, and acting on it tends to make things worse.
More likely you have capable people working without the leadership structure that would make them effective, and the difference between a team and a well-led team is large. Without strong technical leadership, a team defaults to familiar work. It avoids hard architecture decisions because nobody has the authority or credibility to make a call that sticks. And it optimizes for local comfort, keeping the build stable and relationships intact, rather than for business outcomes it may not fully understand.
McKinsey’s work on transformations has long found that most failures come down to leadership and execution rather than the technology choices themselves. The engineering usually isn’t the problem. The governance around it is.
Replacing engineers doesn’t fix a governance problem. You just end up with new people in the same vacuum.
What Changes When Someone Looks at This From the Outside
Something specific happens when an experienced technology leader reviews an engineering organization with no stake in the outcome. The assessment isn’t shaped by loyalty to the team, optimism about work already in progress, or any incentive to make things look manageable. The questions are different and the follow-ups are harder, and the picture that comes out is usually more accurate than anything the CEO could assemble from the inside.
What a rigorous outside review finds isn’t always what anyone expected. Sometimes the team is solid and simply hasn’t been given clear enough direction. Sometimes the architecture has piled up risk the team stopped noticing because they’ve lived with it so long. Sometimes there’s one engineer quietly holding a critical system together who hasn’t told anyone how fragile it is.
The point isn’t to find fault. It’s to give the executive team an honest read on delivery risk, architectural health, team capability, and how far what leadership believes is from what’s actually true. Those rarely match, and the gap is what you need to know.
The CEO in the opening scene isn’t trying to catch anyone in a lie. They’re trying to lead part of the business they can’t fully see, using information that has passed through layers of professional caution, optimism, and self-protection. That’s a reasonable place to be, and it isn’t a failure of management.
What it does point to is that nobody in the company is in a position to give an independent, honest read on the technology. Recognizing that gap is the first step, and the instinct that got you here is worth acting on.
Image Created with Nano Banana Pro