How to Read an Engineering Team

The most revealing things about a software team are not in the codebase. They are in how the team talks about its work.

Non-technical leaders — CEOs, board members, investors — often feel unable to assess technology teams directly and defer entirely to the CTO's self-report. This is understandable. It is also a blind spot. Not because CTOs are dishonest, but because every leader has difficulty seeing their own team clearly. The CTO who built the current architecture will emphasise its strengths. The one who inherited a struggling team will contextualise its weaknesses. Both will present a version of reality shaped by their position within it.

The good news is that you do not need to understand the technology to form an independent view. The signals are mostly organisational and behavioural, and they are visible to anyone who knows what to look for.

The Incident Question

Ask the team to walk you through their last significant production incident. Not the outcome — the process. How did they find out something was wrong? How did they communicate during it? How did they decide what to do? What changed afterwards?

This single question is more revealing than most formal assessments. A team with healthy practices will be able to describe the incident clearly and specifically. They will know when they were alerted and how — because they have monitoring that tells them before customers do. They will be able to explain how decisions were made under pressure — because they have agreed roles for exactly this scenario. They will point to something concrete that changed afterwards — a process improved, a gap in coverage addressed, a lesson documented.

A team without these practices gives a different kind of answer. The incident is described vaguely, or entirely from the perspective of how it was resolved rather than how it was detected and managed. "We got it fixed pretty quickly" is not the same as knowing you have a problem before your customers email you about it. The absence of specific detail is itself information.

How a team handles failure tells you more about its health than how it handles success. Success is easy. The response to unexpected failure reveals whether the team has built systems and habits that hold under pressure, or whether it is held together by the effort of a few individuals who happen to know where everything is.

The Requirements Question

Ask someone — ideally not the CTO — to explain how a business need becomes something the team actually builds. Walk through the last feature that was delivered and trace it backwards: where did the idea come from, how did it get defined, how did the team understand what was expected, how did they know when it was done?

If no one can describe this clearly, delivery is ad hoc. Requirements that are vague, late, or constantly changing are one of the most consistent causes of engineering team underperformance — and one of the most consistently misdiagnosed ones. The team looks slow. The actual problem is that they spend a significant portion of their time working from incomplete information, building things that need to be rebuilt, or waiting for decisions that should have been made before work started.

The quality of the answer to this question also tells you something about the relationship between the business and the engineering function. A healthy relationship produces requirements that are clear enough to build from and stable enough to complete. A dysfunctional one produces a team that has learned to treat everything as provisional — because experience has taught them that it usually is.

The Individual Conversation

Have a direct conversation with an engineer — not the most senior one — and ask what they are working on and why it matters. Not what the sprint contains or what the roadmap says. What they personally are working on, and what difference it makes.

Engineers who are connected to the purpose of their work can answer this. They can tell you what the feature they are building enables for a user, or what the system improvement they are making prevents from happening. They may not express it in business terms — that is not their job — but the connection between their work and its effect is present and accessible.

Engineers who are executing without direction cannot. Their answer stays at the level of technical description: "I'm adding a new endpoint" or "I'm fixing a bug in the payment flow." The work is real, but the context is absent. This is not a criticism of the individual — it is a signal that the team is being managed at the task level rather than the outcome level, and that something in the planning or communication layer is not doing its job.

This matters beyond morale. Teams that understand why they are building something make better decisions about how to build it. They surface risks earlier. They flag when what they are being asked to do does not match what the business needs. Teams executing without context do not have enough information to do any of these things, so they do not.

The Morale Signal

Low morale in a technology team is almost always a lagging indicator. By the time people are visibly unhappy, the structural problems generating the unhappiness have usually been present for months.

The early signals are subtler. Engineers stop proposing improvements — not because they have no ideas, but because previous proposals went nowhere. Senior people begin describing their work in terms of what they are managing around rather than what they are building. Conversations about technical decisions become perfunctory — the team has learned that the decisions are made elsewhere. The team stops disagreeing in planning meetings, not because there is nothing to disagree about, but because disagreement has not historically produced outcomes.

These signals are visible without technical knowledge. They show up in energy levels, in the specificity of conversation, in whether people seem to own their work or merely be assigned to it. A team that is genuinely engaged talks about its work differently than one that has learned to comply. The difference is palpable in a room, even if you cannot read a line of code.

What morale is actually telling you is whether the conditions for good engineering exist. Engineers do not leave because the office is bad or the coffee is poor. They leave — and before they leave, they disengage — when the environment makes it impossible to do work they are proud of. Constant re-prioritisation, technical debt so severe that every change is painful, requirements that arrive too late or change too often, decisions made without technical input. These are the conditions that produce the quiet departure of a team's best people, long before the resignation letters arrive.

The Four Questions Every Leader Should Be Able to Answer

There are four questions that any CEO or board member overseeing a technology function should be able to answer at any point — not from a slide deck prepared for the occasion, but from direct familiarity with the team's situation.

What did the team ship in the last quarter, and what was the measurable effect on the business? What is the biggest technical risk right now, and what is the plan to address it? What is slowing the team down most, and who owns fixing it? What would make the team significantly more effective?

If the answers to these questions are only available through the CTO, that is information in itself. It does not mean the CTO is wrong — it means the leadership layer above the technology function has no independent signal of its own. In any other part of the business, a CEO who could only assess performance through a single executive's self-report would recognise that as a governance gap. The technology function is rarely held to the same standard, and organisations pay for it eventually.

The point is not to bypass or undermine the CTO. It is to have enough direct familiarity with the team's situation to know whether the picture being presented is complete. A good CTO welcomes this. They understand that a leadership team that can read the room independently is a leadership team that can provide better support when it is needed and better challenge when it is not.