The Next Agile Frontier - Agile Company Development

Dealing with business growth/transformation challenges through agility

I’ve been helping companies improve their operations for over a decade. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with:

• Losing the Ability to Innovate You often see companies that grow successfully to the point where it seems their ability to innovate stalls. Looking deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation, GTM innovation, and other key business processes.

• Time to Market / Time to Learn — The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown.

• Losing Key Talent — Talented people are looking for an environment where they can thrive, have the right level of autonomy, work on interesting problems with minimum friction and headaches, and see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields.

Business/Organizational Agility — The New Business Operating System

Addressing these challenges by improving our ability to innovate and deliver, solving complex problems in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products, as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum.

While Agile was created in the IT/Software world, more and more organizations realize that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization, from product development/IT through revenue-generating activities such as Sales/Marketing to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model.

This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism, and continuous improvement at all levels of the organization.

A useful definition of the essence of this agility is provided in the Evidence-Based Management (EBM) framework created by Scrum.org. This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working.

In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company.

The trigger to “upgrade the operating system” is sometimes proactive internal leadership. More frequently, there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event.

Focusing Agility Where It Matters The Most

Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ developing company #2” (the company you want to become). Running ongoing operations might or might not require this way of working.

Try this - once you come up with your strategy for the quarter/year (e.g. your OKRs) assess each element according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while allowing them to explore alternative ways to achieve the desired outcomes via trial and error in the trenches.

Replacing the Engine Mid-flight

More often than not, these strategic interventions will need to occur in parallel to continuing to run the business as hard as ever. People struggle to balance their day job (Company #1, the current company that needs to continue running) and transformation work (Developing Company #2 — the one we are working to create) — how much capacity to assign to each? Does managing the day job and transformation work as part of the same bucket make sense? Who’s in charge of each type of work? Who mediates when there are conflicts?

I hear from CEOs in these situations that they frequently need to get involved in resolving these conflicts between the day-to-day and the transformation. This results in delays, frustrations, and feelings of disempowerment. The environment is even more volatile if this transformation also coincides with other bigger company changes (e.g., new leadership, new investors/owners).

Another common friction/frustration area is goal-setting. What should we focus on now? What’s realistic to achieve? Do we involve people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…)

This balancing act between operational and transformational work, alignment, and autonomy is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers,” while they sound very IT/product-centric, can come in handy.

Organizing around Bets

Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked. They spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like.

A preferred play is to reorganize around value — rethink team structure and bring together the people collaborating closely in executing the transformation into empowered, focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on.

The New Frontier for Agility

Agile was born in software development and has been widely adopted in IT and Product organizations to the point that there’s little argument that product/technology organizations should operate using agility principles.

More recently, other functions, such as Marketing, have adopted these agility principles and practices. These are useful stopgap measures on the journey toward real organizational agility.

The next frontier I’m seeing in a couple of early adopter organizations is the evolution towards a more holistic definition of “development” that I explored in this article - developing the company’s capabilities. In Scrum, this would mean that the company is the Product. 

If your company is hitting the scaling ceiling — losing innovation speed, increasing coordination overhead, or struggling to move from strategy to execution — let’s explore what is getting in the way.