The Machinery beyond the Function
For most of my career, I have looked at business through the lens of procurement. It is the function I know deeply, through the systems I have built and transformed, and the problems I have spent years solving. Like most professionals, I have spent a significant part of my career becoming better at understanding one particular component of a much larger system.
There is obvious value in this depth. Functions exist for a reason. They create expertise, accountability and focus, allowing people to develop specialised knowledge and apply it repeatedly to solve complex problems. But over time, I have also come to recognise a limitation. The better we become at understanding our own function, the easier it can become to see the organisation through that lens. We could end up defining problems according to where they appear, rather than asking what is actually producing them.
A Wider Field of View
Over time, my own field of view began to expand. I started looking beyond procurement and paying more attention to how different parts of the machinery interact — customers, operations, supply chains, technology, capital, people and, increasingly, the systems and incentives that sit around all of them.
The organisation is not really a collection of independent functions but a system of interacting components. And this larger machinery goes beyond any function. Vendors, customers, regulators, technology platforms, capital markets and other external forces all influence how the system behaves. Once we begin looking at business this way, some familiar problems start to look rather different.
Procurement Is Rarely Just About Procurement
A procurement decision, for example, is rarely just a procurement decision. A sourcing choice affects cost, but it can also affect capacity, speed, quality, resilience, innovation, working capital and growth. A cheaper supplier may not be cheaper for the business if the decision creates constraints somewhere else. The same applies to specifications, supplier concentration, contracting models and make-versus-buy decisions. Each may appear to belong neatly within procurement, but their consequences travel well beyond the function.
A procurement decision is often a business decision wearing a procurement label. The same can be said about decisions made in other functions. And this is perhaps one of the reasons I have become increasingly interested in the interaction and integration between functions, rather than just the functions themselves.
Risk Is Rarely Just About Risk
Risk management offers another example. Commodity hedging may look like a procurement or treasury technique intended to minimise uncertainty. But it seldom makes uncertainty disappear. It simply determines where that uncertainty sits and who ultimately carries its consequences.
The same principle applies more broadly. When we look at lean inventory systems, we solve for working capital and greater daily efficiency, but we also remove the slack that could absorb the impact when things go wrong. If we look at better cost discipline by removing slack in the vendor value chain, we may reduce an immediate cost while inadvertently carrying a risk that was previously carried elsewhere.
What often gets missed is the asymmetry in how we view these decisions. The benefit appears immediately and can be measured. The risk may appear infrequently and remain invisible for long periods. I explored this idea earlier in my piece on [Slack — Insurance not Inefficiency], where I looked at how removing what appears to be inefficiency can also remove the buffers that make a system resilient.
Risk therefore cannot always be understood by looking only at the function formally responsible for managing it. A decision that appears to solve risk in one part of the organisation may simply move it somewhere else.
The Event Is Not Always the Cause
Operational failures offer perhaps the clearest illustration. A flight cancellation or a supply disruption may be classified as an operational event, but the visible failure can be the manifestation of years of decisions elsewhere — capacity choices, network design, supplier strategy, maintenance philosophy, inventory policies, commercial commitments or planning assumptions.
The event is where the problem becomes visible. It is not necessarily where the problem was created.
This distinction matters because organisations naturally tend to respond where the pain is felt. The operational team is asked to fix the disruption. The procurement team is asked to fix the supply issue. The technology team is asked to fix the system failure. Sometimes that is exactly right. But sometimes the intervention needs to happen somewhere else in the machinery.
The Four Solutions
Functional boundaries are organisational conveniences. They are useful for managing complexity, assigning accountability and creating expertise. But the underlying problems do not necessarily respect those boundaries. A problem can originate in one function, manifest in another, be amplified by a third and require a fourth to resolve it. This is becoming increasingly common as businesses become more interconnected.
There are several ways of responding to such problems, and they do not all require the same degree of intervention.
The first is the functional solution. We all do it. The problem sits within our function, so we solve it within our function, using the authority, resources, processes and capabilities available to us. There is nothing inherently wrong with this. In fact, many problems should be solved this way. The danger begins when functional ownership becomes functional blindness, and “not my circus, not my monkeys” becomes a convenient way of avoiding a problem that actually crosses boundaries.
The second is the interdependent solution. The problem may be in Function X, but the solution may sit in Function Y. A procurement problem may require a product-design intervention. A supply-chain problem may require a commercial decision. A cost problem may actually require a change in the operating model. The functions remain intact, but the solution crosses the boundary.
The third is the design solution. Instead of asking how to solve the problem within the existing machinery, we ask why the machinery produces the problem in the first place. This requires looking at the larger system — the organisation, its vendors, customers, partners, technology, capital, processes, incentives and regulatory environment — and asking whether the whole thing could be designed differently.
Get Sudeep Hota’s stories in your inbox
Join Medium for free to get updates from this writer.
This solution can be highly disruptive, and also highly effective. It can produce outcomes that incremental functional improvements never will, but it also requires considerable conviction and careful stewardship. When you redesign the machinery, you are changing relationships and dependencies that may have evolved over many years. Seeing a better design is one thing; moving the system towards it without destabilising everything around it is quite another.
There is also a fourth dimension, and perhaps the one that determines whether the others are possible at all: people.
Systems, processes and structures matter, but people are the ones who see problems, challenge assumptions and propose alternatives. For that to happen, people need to feel safe enough to speak. An organisation needs an environment where opinions do not automatically become threats, where perspectives do not automatically become misalignment, and where challenging a way of working is not interpreted as challenging the people who created it.
The best solution may sometimes come from someone outside the function that owns the problem. But that insight will remain invisible if the system does not make it safe for people to say that they think the problem is being approached in the wrong way.
Disruption With Continuity
There is another dimension to changing the machinery that is easy to overlook: what should remain unchanged?
When organisations redesign themselves, there is often a temptation to wipe the slate clean. The old is labelled legacy, and the new is assumed to be better simply because it is new. Yet the old system may contain capabilities that are still valuable — accumulated knowledge, relationships, judgement, institutional memory, customer understanding and ways of thinking that helped sustain the organisation in the first place.
“Old is gold” is not literally true. Some things should absolutely be discarded. But the underlying idea has merit. Not everything that belongs to the old system should be left behind.
The format may change. Technology may change. The go-to-market model may change. The operating model may change. But the underlying identity and philosophy may still have value. The challenge is to distinguish between what has become obsolete and what remains fundamental.
This is a difficult balance. Organisations sometimes preserve too much because change is uncomfortable. At other times, they change too much because the desire to demonstrate transformation becomes stronger than the need to preserve what works. In wiping the slate clean, they can inadvertently destroy capabilities that the new system needs.
Good transformation therefore requires more than disruption. It requires balancing continuity as well — carrying forward the right parts of what already exists while deliberately changing the parts that no longer serve the future.
Don’t Dilute the Function
There is, however, an important qualification to this entire argument. Looking beyond the function should never mean looking down on the function.
Functional expertise is not something we outgrow because the problems become bigger. It is the foundation on which the ability to solve bigger problems is built. A procurement professional still needs to understand strategic sourcing, negotiation, supplier management, contracting and the economics of what they buy. A finance professional needs to understand finance. An engineer needs to understand engineering. The same is true across every discipline.
If everyone starts behaving like leaders and proposing innovative solutions to large problems without possessing the skills required to solve the underlying problems, we have not created a more capable organisation. We have simply diluted capability.
This is particularly important as people progress through their careers. The first decade or so should involve considerable time getting hands dirty, doing the work, developing judgement, making mistakes and building mastery. A senior procurement leader may no longer negotiate with a supplier every day, but they should still understand what good negotiation looks like, be able to challenge it and coach others to do it well. The same applies at every level of leadership. A CPO does not need to be conducting supplier negotiations every day, but should not become so removed from the craft that functional expertise becomes something delegated entirely to others.
Leadership at a higher level changes how expertise is applied; it does not make the expertise itself irrelevant.
The ability to look beyond the function should therefore be an extension of functional capability, not a substitute for it. The objective is to build depth, understand the craft and then use that depth to recognise when a problem requires collaboration beyond the immediate boundary.
A More Interconnected Future
This becomes increasingly relevant as we look ahead. The problems organisations will face over the coming decades are likely to involve more complex interactions between technology, regulation, supply chains, consumer behaviour, capital, geopolitics and changing expectations. A change in one part of the system can rapidly alter the behaviour of another.
This makes purely functional thinking increasingly insufficient, not because functions are becoming irrelevant, but because the interactions between them are becoming more consequential.
At the same time, seeing the whole does not mean pretending to be an expert in everything. We cannot become experts in every component of the machinery, nor can a solution that works in one organisation or industry simply be transplanted into another. Every system has its own incentives, constraints, history, culture, technology and context.
The value of a wider field of view is therefore not that we know more about every individual component. It is that we can better understand how the components interact, where the real constraints lie, and how a change in one part can alter the behaviour of the whole.
Perhaps this is where functional expertise ultimately takes us. The purpose of building deep capability is not to remain confined within the boundaries of the function. It is to develop enough understanding and judgement to know when those boundaries matter, when they can be crossed, and when the problem requires us to look at the machinery beyond them.
The machinery is larger than the function. And increasingly, the problems we face will require us to understand both.
