Adaptive Organisations: Building Resilience Through Product Orientation, Fast Learning, and Ambidextrous Leadership

Executive Summary

We’ve all watched it happen. Companies that seemed invincible disappeared or became irrelevant within a decade. They didn’t lack talent or resources. They simply couldn’t adapt when their markets shifted.

This white paper explores the concept of Adaptive Organisations: enterprises that have developed the ability to respond rapidly to change while maintaining operational excellence. Traditional companies, with their rigid hierarchies and departmental silos, struggle with this balance. Through years of working with organisations attempting this transformation, three fundamental elements consistently emerge: organising around products rather than functions, building genuinely fast learning cycles (measured in days and weeks, not quarters or even years), and managing to innovate whilst delivering today’s business, which is usually called organisational ambidexterity.

And there’s an important enabling factor that we need to consider: company restructuring alone achieves nothing if your leadership team still operates as a collection of departmental heads who happen to share a boss. An adaptive company needs genuinely adaptive leadership that functions as a cohesive leadership team.

The uncomfortable truth is that adaptation isn’t optional anymore. You either become genuinely adaptive or become a case study in someone else’s presentation about being on the failing side of a market disruption.

1. Introduction: The Imperative for Adaptive Organisations

Picture this scenario: you’re in a strategy meeting when someone mentions a startup that’s eating into your market share. They have fifteen people and a product that looks hastily assembled. Your company has thousands of employees, decades of experience, and resources they can only dream of. Yet somehow, they’re winning customers you thought were loyal to you.

This pattern repeats across industries with depressing regularity. Established companies, perfectly optimised for a world that no longer exists, find themselves outmanoeuvred by organisations that barely existed yesterday. It’s not because these startups are smarter or work harder, but instead because they’re built differently.

Traditional organisations were designed for a different era, when you could spend six months planning, a year executing, and another six months evaluating. Market positions were defensible for decades. Customer needs evolved at a pace that was slow enough to be tracked through sporadic market surveys. The assumption underlying such organisations is that employees are not capable of learning outside of their “job”, and therefore, focusing them on just one aspect of the value stream made sense, especially since it was possible to keep interfaces stable enough to allow for this specialisation to occur. These organisations made perfect sense then. You organised by function to achieve economies of scale. Marketing people sat with marketing people, engineers with engineers. Everyone became an expert at their specific piece. Optimise each department, and you’ll optimise the whole organisation. The theory was elegantly simple but also incredibly wrong, as the sum of local optima does not give a global optimum (for example in Hunter, 2016, referring to W.E. Deming’s System of Profound Knowledge). In any case, the dysfunctions of such an organisation were covered by the overall slow pace of the markets.

Furthermore, designing a company in this way results in departments that become their own kingdoms, with their own specialised languages, metrics, and priorities. Meanwhile, the customer, who simply wants their problem solved, must navigate this byzantine structure without even knowing it exists. Their requests bounce from department to department, accumulating delays and frustrations at every handoff, and often go unanswered.

We’ve seen organisations where a decision that a competitor makes in an afternoon takes many weeks and many frustrating meetings. People work incredibly hard, but they’re working within a system that actively resists speed and adaptation.

This brings us to Adaptive Organisations. An Adaptive Organisation can sense changes in its environment and respond effectively and repeatedly. It’s not about being “agile” (a term that’s been tortured beyond recognition), and it’s definitely not about constant pivoting. It’s about building an organisation that evolves continuously whilst still delivering value today.

This sounds straightforward, but it requires rethinking almost everything about how organisations are usually structured: how we make decisions, how we organise teams, how we think about leadership. And even how we define success and failure! The way the average company is structured might make sense in an old-fashioned production-oriented company acting in a fairly static market, but it doesn’t cut it in a fast-paced innovation world.

The question isn’t whether your organisation needs to become more adaptive: the market has made that decision for you. The question is whether you can build this capability before someone else makes your business model obsolete.

2. The Three Pillars of Adaptive Organisations

After observing dozens of transformation efforts, we’ve noticed that organisations that actually become more adaptive share three essential characteristics. They’re not the only things that matter, but without them, you’re essentially rearranging furniture on a sinking ship.

2.1 Product Orientation

The first shift tends to terrify middle management: moving from functional departments to product teams.

In a traditional organisation, when customers have problems, their requests trigger cascades of activity across multiple departments. Sales owns the relationship but can’t fix the problem. Engineering can fix it, but it doesn’t talk to customers. Support talks to customers but lacks the authority to make changes. Finance has opinions about everything but understands little of the technical details.

Each department optimises its piece. Sales optimises for closing deals. Engineering optimises for elegant architecture. Support optimises for ticket closure rates. The result is local optimisation that creates global dysfunction. Brooks (1987) called this “accidental complexity”, i.e. complexity we’ve created through our organisational choices over time.

Product orientation takes an entirely different approach. Instead of organising around what people do, you organise around what you want to deliver. You create teams that own as much of the entire product or value streams as possible, from start to finish. This sounds straightforward; however, the difficult part is the implementation.

First, you must determine what constitutes a “product” in your organisation. Is it what you sell? What do your customers buy? What value do they receive? The decision of what we consider a product is, in a sense, the fundamental decision that underlies how we should then organise the company.

We’ve seen companies developing a website, but considering each part of that website a product. The result is a website that looks, feels, and functions like a patchwork because… it is built by a patchwork of teams that barely understand what each other does.

Another common setup is to separate product development and product support completely. And I assume you, as a customer, have already experienced the frustrations of dealing with a customer service that can do little more than instruct you on how to switch your product off and on again.

We’re sure you have already heard many of these “war stories”!

One common mistake we’ve seen repeatedly is chunking the creation of value in smaller blocks in a way that, more often than not, is driven by the current reality of the organisational structure (department, sites, distribution of knowledge, budgeting and accounting practices) rather than truly understanding how we actually deliver value to real customers.

For example, in banks we often see products like “bank accounts”, “credit cards”, “investment funds”, …, but, in the end, they are all competing for the same thing: the money of the customer. This might seem a trivial issue, but the result is the practical impossibility of creating a valuable solution that, as Denning (2010) puts it, “creates Customer Delight”.

Once you’ve defined your products, you can build teams around them. These teams need genuine cross-functionality, which means putting people who’ve never worked together in the same room and expecting them to deliver. It’s messy and uncomfortable at first, but if appropriately accompanied by good coaches, it works, and it enables achievements that often seem like magic: we’ve seen 10-person companies eat the market away from multinationals investing 50 to 100 times more.

The key is for teams to achieve as much as possible and have complete ownership over the product. These teams don’t throw work over walls to other departments. They understand customer needs, build solutions, measure impact, and iterate. When something breaks at 3 AM, they know about it. When customers provide feedback, it goes directly to them. This creates accountability that actually means something. When you own the entire value stream, you can’t blame another department for problems or hide behind process and policy. You succeed or fail as a team based on whether customers receive value.

Sure enough, there are products that, due to their complexity, it will be impossible for each team to take care of the entire value stream. However, the fewer components and silos we have in a value stream, the better. Therefore, the effort to create teams that, although not full-product teams, encompass as wide a range of the product as possible, remains an essential aspect of this work. This clearly indicates that individual and organisational learning, and more generally, developing the skills of the company’s employees, is of paramount importance. This is what Senge (1990) calls the “Learning Organisation”.

But product orientation alone isn’t enough. We’ve seen organisations create product teams that are still very slow in getting to market. This is why we need to speed up the cycles…

2.2 Fast Improvement Cycles

The second pillar concerns speed, but not in the way most people think. It’s not about working faster or harder; it’s about learning faster than the speed of change of your environment.

Traditional organisations typically operate on annual cycles. Annual planning, budgets, reviews. This made sense when markets moved slowly. Today, by the time you’ve executed your yearly plan, its underlying assumptions have become historical curiosities.

Fast improvement cycles create feedback loops measured in days or weeks, not quarters or years (Ries, 2011). You try something, learn what works, adjust, and try again. Simple concept, surprisingly difficult to implement. Most companies are implicitly designed to prevent precisely this kind of experimentation: without the previously discussed Product Orientation, the internal barriers of an organisation prevent learning from happening. Consider what happens in your organisation when someone wants to try something new that goes beyond the boundaries of their department. How many approvals do they need? How long does it take? What’s the cost, be it financial, political, … if it doesn’t work?

One of us worked with one company where obtaining approval for the development phase of an extension of a product took 16 times longer than building, launching, and testing it with customers would have. That’s madness, but it’s completely normal in most large organisations. And, BTW, when this product extension was launched, it failed on the market because the assumptions agreed in management (and often those assumptions were the result of compromises to satisfy egos) were not what the customers really needed.

Creating fast improvement cycles requires three fundamental changes. First, dramatically reduce the cost of experiments. If an experiment costs millions and takes months, you’ll only run a few conservative ones. If it costs hundreds and takes days, you can run many of them and learn rapidly.

Second, you need to have product teams that can run these experiments; the more siloed the organisation, the more planning is required. This means time, problems with the availability of the right people, and the need for a broader agreement to initiate the process. Product Teams are the fundamental building blocks for running experiments effectively. It is essential to note that Product Teams must be capable of understanding and controlling the whole product development cycle. Often, we see “product teams” that are responsible for technical development and nothing more. Real Product Teams, on the other hand, talk to customers to understand them, model those lessons in product iterations, ship the products to customers, and monitor and learn how customers use the product.

Third, you need leaders who can hold their nerve whilst teams experiment. Giving teams the freedom to experiment and pursue ideas that may fail shatters the false security of following a pre-defined plan, but without it, you don’t get innovation.

Organisations that master this build learning into everything they do. They run retrospectives that actually change how they work, not just tick boxes. They share failures as enthusiastically as successes. They measure cycle time obsessively, always asking how they can learn faster.

But success creates its own challenges. As you improve at rapid learning, opportunities appear everywhere. New markets, technologies, business models. The temptation to chase everything becomes overwhelming, but the reality of running a business is that while we need new products for the future, we still have to manage operations today: this is where Organisational Ambidexterity comes into play.

2.3 Organisational Ambidexterity

The third pillar addresses a fundamental tension: how do you keep today’s business running whilst building tomorrow’s?

Every organisation faces this challenge. You need to exploit current strengths, as that’s what pays the bills. But you also need to explore new opportunities, or you’ll eventually become irrelevant. March (1991) first articulated this as the exploration-exploitation dilemma, which typically requires two distinct approaches: Exploitation and Exploration.

Exploitation focuses on efficiency, consistency, and incremental improvement. You know what works and want to do it better, faster, cheaper. There is usually some improvement over time, but caution is the name of the game: you don’t want to break what works. The metrics are usually clear, processes are defined, and risks are understood.

Exploration emphasises experimentation, learning, and breakthrough innovation. You don’t know what works, and that’s the whole point: betting on something that can have much greater returns in the future. Metrics are unclear, processes are emergent. Most experiments will fail, and that’s ok. Reinertsen (2009) compares Exploration to investing in stocks that might be risky, but while you know how much it costs to fail, the potential returns are so much higher that it still makes sense to try.

Managing both in the same organisation is like asking someone to be simultaneously careful and reckless, focused and flexible, efficient and experimental. No wonder most organisations excel at one or the other, but rarely both (O’Reilly & Tushman, 2008).

We’ve seen various attempted solutions: from a complete separation by creating “innovation labs” of “incubators” that generate great ideas that rarely become actual products. Teams alternate between periods of exploitation (delivering existing products) and exploration (developing new ones). This cycle is brittle: Exploration is abandoned when times are tough and immediate delivery is paramount, and exploitation is abandoned when customers lose faith in a company’s future value due to a lack of meaningful innovation in its pipeline. The former often creates the feeling of having two organisations in one: one of an elite of people working on cool new things and another one of the people who have to deal with customer complaints and fix the problems introduced by the other part. The latter, instead, is driven more by the emergencies of the day than by a real strategy.

Successful organisations develop what is called “dynamic capability” (Guo et al., 2022). They are capable of shifting their balance between exploitation and exploration in response to environmental conditions.

This isn’t a strategic planning exercise. It’s an operational capability that requires, as a fundamental skill, having Product Teams that can be rapidly deployed in different types of missions: sometimes to exploit, sometimes to explore. Again, this requires a learning organisation and the capacity and resources to upskill people.

Most importantly, it means accepting that this tension never completely disappears and being able to manage it properly and quickly is a significant competitive advantage. You don’t solve the exploitation/exploration challenge. You need to learn to dance with it.

These three pillars create the structural conditions for adaptation. Still, to actively develop and sustain such an environment, you need the support of the people who have the authority to do so: leadership.

3. The Role of Adaptive Leadership

Here’s something that took us years to understand: you can have perfect structures, processes, and principles, but if your leadership team doesn’t fundamentally change how they work together, nothing else matters.

Heifetz et al. (2009) describe adaptive leadership as mobilising people to tackle tough challenges and thrive. In practice, this means accepting some deeply uncomfortable truths about how leadership must work in adaptive organisations.

This means that the leadership team’s ability to work as an actual team, and not just as individuals who report to the same boss, sets the ceiling for the level of adaptability the organisation can achieve. If leadership operates in silos, your organisation will too, regardless of what the org chart says.

In most organisations, what passes for a “leadership team” is actually a collection of functional heads who meet regularly to exchange updates and manage dependencies. The CFO discusses finance. The CMO covers marketing. The CTO reviews technology. Everyone nods politely, asks questions to appear engaged, then returns to running their silo. This isn’t a team: it’s just a very expensive status update meeting.

In adaptive organisations, leadership teams collaborate with each other and with the employees to build the systemic capability to meet market opportunities by leading with innovation. The competence to “go-see” and profoundly understand the way you generate value is already part of the body of knowledge of Lean: the 3G’s Gemba, Gembutsu, Genjitsu. To date, many companies apply these concepts in localised, team-level operations to drive immediate improvements. However, we still rarely see this approach extended across the entire organisation to achieve global optimisation.

Individual challenges are often a sign that we are not looking at the problem in a sufficiently systemic manner. The CFO must care as much about customer experience as the CMO. The CTO requires a sufficient understanding of finance to make informed trade-offs. Everyone must think systemically about cause and effect across the entire organisation. Eventually, role titles based on functions and departments become meaningless.

This proves more complicated than it sounds. Most executives have spent careers becoming functional experts. Their identity is tied to their expertise. Asking them to think beyond their function feels like abandoning what makes them valuable. The leader as the boss of a silo is a metaphor so widespread that most managers have difficulty conceiving other ways of working as a leader! Yet when leadership teams make this shift, something remarkable happens. Intractable problems suddenly have solutions. Decisions that would have taken weeks can now happen in hours. The organisation feels different, less political, more purposeful.

Furthermore, adaptive leadership primarily involves creating conditions for others to solve problems, rather than solving problems oneself (Heifetz et al., 2009). This contradicts every heroic leadership narrative we’ve absorbed since business school: traditional leaders pride themselves on having answers. Adaptive leaders pride themselves on creating environments where learning is possible and answers can emerge. They set direction and boundaries, then step back. They provide air cover for experiments. They ask questions that alter how people perceive problems.

This requires a different set of skills: telling people what to do is easy. Creating conditions where they figure things out themselves, and often develop better solutions than you would have, is much harder. We’ve watched executives struggle with this transition. They’re accustomed to being the smartest person in the room. Suddenly, they’re supposed to facilitate rather than dictate. Their value lies in enabling others rather than relying on their own expertise. It’s an identity crisis wrapped in a transformation programme.

Another uncomfortable truth: adaptive leadership requires managing paradoxes that might never be resolved. You need stability whilst enabling change. You need standards whilst encouraging experimentation. You need results whilst accepting failure. Most leaders want resolution: pick a side, get clarity, … But in adaptive organisations, these tensions are useful devices as they create the energy for evolution. Leadership’s job is to hold these tensions creatively, not eliminate them.

This might be exhausting and requiring an intellectual and emotional sophistication that most leadership development programmes don’t even acknowledge, let alone develop. It means being comfortable with ambiguity, conflict, and perpetual incompleteness. But when leaders get this right, organisations thrive. They move fast without chaos. They innovate without losing their core. They adapt without falling apart.

4. Conclusion: The Journey to Adaptability

So where does this leave us? If you’ve read this far, you’re probably thinking either “this makes sense but sounds impossible” or “we’re already doing some of this, but it’s not working.” Both reactions are perfectly understandable views. Yet we are seeing (and helping) many organisations going successfully through this evolutionary path, so we know it is possible provided that management has a strong will to go through it and the willingness to learn, challenge themselves and look beyond the current set of models many companies seem to adopt without really challenging them before..

Becoming an adaptive organisation is genuinely difficult. It requires changing structures that have been considered successful in the past. It requires leaders to work in ways that feel uncomfortable and risky. It requires everyone to accept uncertainty in a way that most people might find deeply unsettling.

Successful organisations also don’t attempt to change everything simultaneously. They start with experiments. One product team. One fast improvement cycle. One leader willing to work differently. They learn what works in their context, adapt principles to their reality, and gradually expand what succeeds, knowing that adaptiveness is a path, not an endpoint.

But here’s what we’ve observed: organisations that commit to becoming genuinely adaptive don’t just survive disruption: they create it. They stop worrying about startups eating their lunch because they’re too busy creating new markets. They stop fighting over resources because they’re generating new value streams. They stop fearing change because they’re driving it.

References

Brooks, F. P., Jr. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10-19. https://doi.org/10.1109/MC.1987.1663532

Brooks, F. P., Jr. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley.

Christensen, C. M. (1997). The innovator’s dilemma: When new technologies cause great firms to fail. Harvard Business Review Press.

Denning, S. (2010). The leader’s guide to radical management: Reinventing the workplace for the 21st century. Jossey-Bass.

Hunter, J. (2016). Optimize the Overall System Not the Individual Components. https://deming.org/optimize-the-overall-system-not-the-individual-components/

Guo, Y., Huang, P.-W., Cui, C., Fang, S.-C., & Tsai, F.-S. (2022). Entrepreneur hubris, organizational ambidexterity, and dynamic capability construction. Frontiers in Psychology, 12, Article 717245. https://doi.org/10.3389/fpsyg.2021.717245

Heifetz, R., Grashow, A., & Linsky, M. (2009). The practice of adaptive leadership: Tools and tactics for changing your organization and the world. Harvard Business Press.

March, J. G. (1991). Exploration and exploitation in organizational learning. Organization Science, 2(1), 71-87. https://doi.org/10.1287/orsc.2.1.71

O’Reilly, C. A., III, & Tushman, M. L. (2008). Ambidexterity as a dynamic capability: Resolving the innovator’s dilemma. Research in Organizational Behavior, 28, 185-206. https://doi.org/10.1016/j.riob.2008.06.002

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.

Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Business.

Senge, P. M. (1990). The fifth discipline: The art and practice of the learning organization. Currency/Doubleday.