What a CTO should be hearing

Much of what a CTO most needs to know never reaches engineering on its own. It sits with the people who deal with the product’s consequences every day: customer service, marketing, finance and sales. Most CTOs do not listen to them systematically, and they make technical decisions on a narrower picture as a result.

I learned how much this matters on a visit I nearly did not make.

---

A failure rate that was not a failure rate

Shortly after joining one company, I went to visit the contracted maintenance operation for one of the products I had inherited. It was the kind of visit that is easy to defer when the diary is full. I am glad I did not defer it.

The product had a component with a high apparent failure rate. It was one of the more expensive parts in the assembly, and the maintenance company was replacing it regularly. On paper, this looked like a reliability problem. In practice, it was an incentive problem. The maintenance company was measured on turnaround time, and there was no commercial penalty for swapping out an expensive component whether or not it was actually faulty. The fastest resolution was always to replace the part. So that is what they did.

Nobody in engineering had been to see this. The logistics team was ordering replacement stock against a failure rate that bore no relation to how often the component was actually failing. The numbers looked like a product problem. The real problem was a contract structure that made unnecessary replacement the path of least resistance.

I developed a test process and the software to go with it, which let the maintenance team identify whether a removed component was genuinely faulty or simply replaced for speed. The actual failure rate turned out to be a fraction of what the replacement rate had implied. I provided the test tooling to the maintenance company and put a gate on future orders that required my review. I also made clear that the refurbished stock of genuinely good components would need to be used up before new parts could be ordered, and then only at a rate consistent with the real failure data.

The maintenance company was not behaving badly. It was behaving entirely rationally within the incentive structure it had been given. The point is that nobody would have seen this from inside engineering. It took being physically present at the sharp end of the product’s life to understand what was happening, and it took technical knowledge and commercial authority together to do something about it.

That combination is what a CTO uniquely has. But it only produces results if the CTO is actually in those conversations. Most are not. There are four functions a CTO needs a regular line into, each providing a kind of signal that engineering cannot generate on its own.

---

Customer service

Customer service knows things about the product that a CTO will never find in a bug tracker. They know which problems customers hit repeatedly but never report formally. They know the workarounds customers have invented because the product does not quite do what they need. They know which features confuse people in ways that look like user error but are actually design failure. They know the gap between what was promised and what was delivered, because they spend their days in it.

A CTO with a regular line into customer service will periodically hear something that reorders their priorities entirely. A CTO who only sees formally logged defects is working from a filtered and systematically incomplete picture of what the product does to the people using it.

---

Marketing

Marketing gives advance sight of incoming needs. They know what is being positioned to the market before engineering does. They know which customer problems the company is committing to solve, which competitors are being cited in sales conversations, and which capabilities are being implied in campaigns that have not been built yet.

The CTO who is not talking to marketing regularly is often the last to know about commitments that will land on engineering’s desk as urgent requirements. Getting into that conversation early changes what is possible. Getting into it late means being handed a problem with the solution already implied.

---

Finance

Finance reveals the commercial reality of technical decisions. Which products are profitable and which are not. Where margins are eroding and why. What running a particular system or maintaining a piece of infrastructure really costs when it is fully accounted for rather than buried in a shared cost pool.

Technical debt, in particular, is almost impossible to make a convincing case for addressing unless it can be translated into commercial terms. Finance can help with that translation, but only when the relationship is in place. A CTO who understands the P&L of their own product portfolio makes different decisions from one who does not, and argues for them more effectively when the argument has to be made at board level.

---

Sales

Sales reveals how the market actually receives the product, as opposed to how engineering imagines it is received. The objections that come up repeatedly in sales conversations are often product gaps in disguise. The features competitors are credited with, accurately or not, say something about what the market values. The deals that are lost, and why, are some of the most useful product feedback available, and they rarely reach engineering through any formal channel.

Sales also has a view of what the product could be that is worth stress-testing against technical reality. Not because sales is always right about what is buildable, but because the distance between what sales believes is possible and what engineering believes is possible is often where the most productive conversations happen.

---

The pattern underneath

What these four functions have in common is that they are in contact with reality in ways engineering is not. Customers, market positioning, commercial performance, buying decisions: these determine whether the product succeeds, and none of them is visible from inside engineering without deliberate effort.

The CTO who builds systematic relationships with these functions is not being political or spreading themselves thin. They are collecting the information their technical judgement needs to be useful. A decision about where to invest engineering capacity, made with the full picture, is a different decision from the same one made inside the technical silo.

The practical version is not complicated. A regular conversation with the head of each function, focused on what they are seeing and what is coming, is enough. Not to report on engineering, but to listen. The signal-to-noise ratio in those conversations is usually high, because the people in them are dealing with consequences that engineering created and often does not know about.

---

Four things worth taking seriously

For CTOs: set up a regular conversation with the heads of customer service, marketing, finance and sales, and use it to listen rather than to report on engineering.

For boards: ask whether your CTO has a working line into each of those four functions. If not, their technical judgement is running on a partial picture.

For heads of customer service, marketing, finance and sales: what you see every day is product signal that engineering cannot generate. Bring it to the CTO rather than waiting to be asked.

For anyone reading a failure rate: before treating it as a product problem, check what behaviour the surrounding contracts and incentives reward. Go and see where the numbers are made.

---

I would be interested to hear which of these four functions your technical leadership hears from least, and what that has cost.