What Is Your Team Missing?

By Tim Huegdon · Published 10 November, 2026

What is my team missing? It is the question a director or CTO asks, usually after something has turned up that, looking back, somebody could have seen coming. A complaint that had been building for months. A supplier change nobody was tracking. A colleague who had been running out of road for a long time.

In October I asked whether anybody is actually reading what a team produces, and last week I applied the same test to reports. Both posts were about outputs. This one turns to the other end: what a team notices in the first place, and how a leader can tell whether it is hearing the right things in the right proportion.

My argument is that a team can only respond to what it can hear, and it hears what it has deliberately set up to hear. Waiting for problems to arrive is not a design. What follows is a set of practices I have found useful and believe in.

Observations from Experience

In my work with teams I have seen the same pattern many times. A team can describe its systems in great detail and still be surprised by something a customer, a colleague or the market could have told it months earlier. There is no shortage of information. What is missing is a deliberate view of where the team listens, who reads each source, and which decisions each one could change.

Adding AI makes the volume of information grow. Feeds, summaries and alerts are nearly free to produce now, and in my experience nobody has chosen which of them are worth hearing.

Teams fail in two opposite ways. Some watch what is easy to count and are surprised by what they could have seen. Others become absorbed in their instruments: the dashboards multiply, and attention goes to the charts instead of the people the work is for. I made a related point in the agile metrics post, where I argued that metrics are signals to guide a team, not targets to hit, and that the conversation matters more than the chart. I will not repeat the argument here.

AI raises the stakes on both. A fluent summary of the data a team already has can feel like coverage, yet it describes only what was fed into it, so whatever nobody was measuring stays missing, now behind a tidy report. I wrote about that fluency in October. And new dashboards and digests appear faster than anyone can decide which ones matter.

Five Places a Team Hears From

There are five places a team needs to listen. A team that listens to only one has a gap, whatever else it has.

The system itself. How it behaves and what it costs. This tells you whether what you built is doing what you meant. It works because systems often fail quietly, staying up while they get worse or dearer. A service can answer every request and still answer some of them badly. I described a version of this in the incident response post, where an AI feature can stay available while its quality falls and teams find out from support tickets, not alerts.
Its users. What they say, and what they stop doing. This shows whether the thing is useful in practice, not just in the specification. Behaviour is honest in a way that opinions often are not. A feature can be released, praised in the demo and then quietly never used.
The people doing the work. How sustainable the way of working is. This answers whether the pace and pattern can be kept up. It matters because strain shows up late in the output and early in how people describe their week. Interruptions can creep into evenings long before the output falls. In my reading of the 2025 DORA report, I wrote about how friction and burnout sit in the system, not in the tools.
The market and commerce. Whether people want it and choose it. This shows whether the work is worth doing more of. Use and choice are different things, and only choice shows that the work matters. A feature can be used often and still never be the reason anyone signs up or stays.
The outside world. Security, regulation, suppliers and competitors. This tells you what is changing around you whether or not you change. Nobody inside the team will bring it to you unprompted. A supplier can alter its terms, or a rule change can arrive with a date attached.

In my experience most teams listen to one or two of these, usually whichever is easiest to count, and hear about the rest only when something goes wrong.

Here is an aside from my own experience, kept general, about listening to users. On a sports media website I worked on, very little use was being made of the league table data, and we could not understand why. The table for the top league was shown automatically. The tables for the leagues beneath it sat behind tabs, and almost nobody clicked through. We first assumed people did not know how to use the tabs. Extensive user testing showed they simply never saw the tabs as worth exploring. The behaviour told us something was wrong, and only talking to the users told us why. I think we could have known for several release cycles. The decision it should have changed was how the lower leagues were presented, rather than teaching people to use the tabs and wondering whether anyone wanted that data.

A Reader and a Decision for Each Source

The October post offered two questions for any practice: who consumes its output, and what decision does it change? They work as well on a source of information as on a report. Name the Reader covers the reader half. For a source, the point is simple: if nobody reads it, or it could not change any decision, it is noise, however accurate it is.

So the place to start is the decision, not the data. A signal earns attention if it could change a decision you are about to make, or a promise you have made to users. Otherwise it is context. A fall in traffic to a page is data. It becomes a signal when it could change whether you redesign the page or what you tell users to expect.

Eric Ries separated vanity metrics from actionable ones in a 2009 guest post on Tim Ferriss’s blog. The only metrics worth collecting, he argued, are those that help you make decisions. Most of what off-the-shelf analytics offers is vanity: it feels good but gives no clear guidance on what to do. His example is the total number of hits to a website. It is a big, comfortable number, and it cannot tell you what drove those visitors or what to do next.

Watch in Proportion to Consequence

Not everything deserves the same attention. What would hurt most if it failed should get the closest and most frequent look. That sounds obvious, but treating everything alike is a choice too, and it is the one teams often make by default. The payment path and a rarely used settings page do not need the same scrutiny.

Google’s Site Reliability Engineering book makes a related point in its chapter on monitoring, written by Rob Ewaschuk. The chapter is about paging engineers, so I am borrowing only the principle. Its advice is to separate what is broken from why it is broken, and to reserve interrupting a person for problems that are affecting users and that somebody can act on. It also warns that people who are paged too often start to skim and ignore alerts, and may miss a real one hidden in the noise.

Hospitals offer a stark version of the same problem. In 2013 the Joint Commission published a Sentinel Event Alert on medical device alarms. It cited an estimate that between 85 and 99 per cent of alarm signals do not require clinical intervention, and said that clinicians become desensitised and may turn alarms down or off. The alert is careful to say that its reported events are not an epidemiological data set, and hospitals are a different field, so I would not draw conclusions about software teams from it. The lesson is familiar, though: when nearly every signal is noise, people stop hearing the one that matters.

Decide What You Will Ignore Before You Look

Agree in advance what you will act on and what you will ignore. Then look at trends and surprises, not every wobble. One spike earns a look, not a reaction.

This works because, once a number has moved, it is very tempting to explain it. In that 2009 post, Ries also observes that fluctuations are often random or caused by unrelated outside events, and that people tend to credit themselves for the good ones. Deciding in advance what would count as a real change protects you from reacting to noise and from finding a story in it.

Say traffic dips on a Tuesday. The team has agreed to look at trends over weeks, not single days, so it checks that nothing is broken, sees no pattern, and moves on. Deciding to ignore something, and knowing why, is a proper outcome. It is not a failure to listen.

Where AI Helps You Listen

None of this is an argument against using AI to listen. I have found that, used well, it widens what a team can hear.

Its strength is breadth. It can read across places a team cannot afford to read by hand, such as support tickets, sales-call notes, incident reviews and supplier or regulatory updates, and notice when the same theme turns up in more than one of them. It is also good at drafting a first summary that a person can react to, which is easier than starting from a blank page.

Its drawbacks matter as much. It cannot see what it is not given, so a gap in what a team collects stays a gap. It cannot tell which theme matters to the decisions in front of you. And it makes noise cheap.

So AI widens the listening, and people choose what the listening is for. The leader’s part is to name the decision the listening should inform, to decide what will be ignored before reading anything, and to decide what to do with what comes back. The point of a better workflow with AI is not more output. It is better judgement about where to look.

Imagine a leader who asks an assistant to read a month of support tickets and sales-call notes and say what customers complained about in both. The useful part is the question. It asks for one thing, drawn from two places that rarely meet, and it exists because the leader has a decision to make about what to fix first. Whether the finding changes anything is still the leader’s call, and so is deciding that a theme does not matter.

A Test of Balance

Here is a simple test. Name the last decision a signal changed. Then name the last signal you rightly ignored.

A team that can name the first but not the second is probably reacting to everything. A team that can name the second but not the first is probably not listening. A team that can name both has probably chosen where to listen and how to respond, which is where I would want a team to be.

If you can name only the decision, ask what you have deliberately chosen to leave alone, and why. If you can name only the ignored signal, ask which of the five places could change something you are about to do.

Questions to Ask This Week

Which of the five places does nobody on your team currently listen to?
For the source your team looks at most, who reads it, and what decision could it change?
What would hurt most if it failed, and is that where your closest look goes?
Since your team started using AI to summarise or alert, has anyone chosen which of the new feeds were worth hearing?
What is the last decision a signal changed, and what is the last signal you rightly ignored?

None of these needs new tooling. They need an honest answer, and a view from outside sometimes makes that answer easier to reach.

When did your team last learn something important from outside its own data, and how long could it have known?

A team rarely sees its own gaps, because the places it does not listen are the ones it does not notice. Someone who has not lived with your team can ask where you listen today and which decision each source could inform, without the familiarity that makes every answer feel obvious.

A Second Pair of Eyes

If it would help to have someone look at this with you, I am happy to talk.

I help teams and leaders work out how to operate now, through process and communication consulting and through mentoring. The first step is a free 15 to 30 minute introductory conversation about the problem you are seeing, where I give you my initial thoughts and proposals. There is no obligation to go any further.

If it makes sense to continue, there are two usual shapes. One is a fixed-price audit of one or two weeks, depending on team size, which looks at process and communication: which feedback loops are broken, which artefacts have no readers, and which practices are doing real work and which are habit. The other is a monthly retainer for ongoing mentoring and advisory work. Even a lightweight second opinion tends to be valuable.

If any of this sounds like your team, get in touch.

About the Author

Tim Huegdon is the founder of Wyrd Technology, a consultancy that helps engineering teams and leaders work out how to operate in the AI era, through process and communication consulting and mentoring. With over 25 years of experience building and maintaining software and software engineering teams.