Old Wisdom, Relearned at Cost

Thirty-five years across technology leadership roles includes a fair number of moments where an old principle proved itself right at some cost. The ones that have stayed with me are not the ones I first encountered in management books; they are the ones I encountered as expensive lessons and only later recognised as compressed versions of something already known.

The reason these lessons recur with particular force in connected-product businesses is that the feedback loop between decision and consequence is long, and the cost of reversal is high. In a software company, a bad assumption can be corrected in the next sprint. In a business where decisions get embodied in hardware, tooling, supplier commitments, certification, and deployed units, the same bad assumption may not declare itself for months, and by then it has compounded into something considerably more expensive than the original error. The proverbs that have survived for generations have survived because they are compression algorithms for exactly that pattern: the cost of not doing the simple thing at the right time. In connected-product leadership, several of them turn out to be unexpectedly precise, not as abstract wisdom but as operational rules that apply directly to the decisions in front of a leader.

Start small, start real

Begin with the smallest version of the thing actually meant. A real first step, not a glossy plan. The advantage compounds: a small real start provides feedback that a big imagined plan never does, and the feedback is what turns the next decision from a guess into a measured choice.

The instinct in most organisations is to plan extensively before committing. The problem is that planning is comfortable and starting is exposing. A detailed plan that has not yet been tested against reality is an elaborate form of staying in place. The organisation that starts something small and real in week one, even imperfectly, will know more by week four than the one that has spent the month refining the deck.

One foot in today, one foot in tomorrow

The past is data. The present is leverage. The future is where the work pays back. A leader who only looks backward is decorating yesterday’s organisation. A leader who only looks forward will misread the present badly enough that the future never arrives as imagined. Holding both at once is harder than most planning conversations admit.

Measure twice, cut once

Carpentry wisdom. Spend two minutes verifying the measurement before spending two hours regretting the cut. In strategy: validate the assumption before committing the budget. In hiring: do the reference call before the offer. In architecture: confirm the requirement before building the system. Slow on the inputs, fast on the execution.

The version of this principle that most organisations violate is the architectural one. A system built on an unvalidated assumption about how the product will be used is technical debt from day one. The assumption was the measurement. Nobody checked it twice.

I learned this one directly in the development of a connected device deployed across multiple markets. The assumption I had not validated was the connectivity profile of the deployment environment. The architecture was designed around persistent, moderate-bandwidth connection, reasonable for the urban Western European context where the product was first developed. When the same product was deployed in a different environment, where connectivity was intermittent and lower-bandwidth than the design assumed, the communication layer proved not just inconvenient to retrofit but central enough to the architecture that addressing it properly required significant rework. The measurement that was missing was a validated connectivity map of the actual deployment environments, gathered before the architecture was committed. It would have taken a week. The rework took considerably longer.

A stitch in time saves nine

Catch the problem when it is small. Fix it. Move on. The cost of dealing with a thing now is reliably less than the cost of dealing with the same thing after it has tangled itself into three other things. Most operational debt, most technical debt, and most relationship damage in organisations comes from skipping this rule under time pressure.

The irony is that the time pressure which causes the skipping is itself usually a product of previous stitches not taken. The problems that dominate crisis management are almost always problems that were visible earlier and deprioritised.

Physical products make this worse, because the cost of a deferred fix grows with every unit shipped. A connector known to be marginal on the test bench costs a design change and a few pounds per unit before production. Found again after ten thousand units are in customers’ hands, it costs a field-service programme, a warranty provision and possibly a conversation with a regulator. The engineering problem is the same one. Only the price has changed, and the price was set by the decision to wait.

The chain is only as strong as its weakest link

In supply chains, this is obvious and routinely ignored anyway. In teams, the weakest link is often not the least skilled person but the most overloaded one: the single point of failure through whom everything critical flows. In technical architecture, it is the component that has never been tested under the load the rest of the system can generate.

Identifying the weakest link before it fails is an act of systems thinking. It requires looking at the whole rather than optimising each part in isolation. Most organisations do the latter, which is why the failure, when it comes, always seems to arrive from an unexpected direction.

The customer is always right

Not always literally true. Always useful as a discipline. When a customer says something is wrong, they are reporting a fact about how the product feels to use. Their explanation of why it is wrong may be off. The signal underneath it almost never is.

The version of this principle that organisations most often get wrong is treating customer feedback as something to be managed rather than used. The complaint that comes in three times from three different customers and gets logged, acknowledged, and left unaddressed is not a support issue. It is a product issue that has been reclassified as a support issue to avoid fixing it. In a connected product, the same signal may be arriving through telemetry, warranty claims, workshop notes, and support calls at once; the failure is often not lack of data but lack of willingness to join the evidence before the field has made the answer embarrassingly obvious.

Inclusion and collaboration

Not soft. The two together are a competitive advantage. A team where every voice is heard surfaces more options. A team where collaboration is structural produces better answers than the smartest individual in the room. The reverse, where the loudest voice wins and the others give up, is what most businesses settle for. The settled-for version is also the version that gets out-competed by a team that does the harder thing.

The reason these principles keep appearing is not that they are wise in the abstract. It is that they address failure modes that the specific economics of technical work make expensive and recurring: the cost of building on an unvalidated assumption, the compounding cost of deferred problems, the systemic fragility of a single point of failure. They are short enough to hold onto under pressure, which is probably the most practical quality a principle can have. The ones worth keeping are the ones that have already proved themselves at someone else’s expense, or one’s own.