Elevating business scaling constraints through agility
Business scaling constraints live above the team and program level. Elevating agility to the company development level — where strategy, culture, and structure interact.
Click image to open full size Growing Pains
I’ve been helping companies improve their operations for over a decade. A repeating pattern is where a 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 Get Complex Stuff Done You often see companies scale to the point where things get stuck. I hear from frustrated CEOs/COOs who know up front that despite investing in great functional leaders, any cross-functional complex initiative is doomed for failure.
- Time to Market / Time to Learn — Despite the fact that the organization is bigger than ever and has access to more talent and more resources, things take longer and longer. You look in the mirror and you seem frighteningly similar to the incumbents you once disrupted.
- Losing Key Talent — Despite a recent funding round and a promising future, you see a worrying trend of key people moving on and unfavorable trends in internal employee satisfaction surveys. People talk about being bottlenecked, stuck, and mired with more and more legacy. They feel like cogs or pawns rather than players.
The Need for a more scalable and dynamic business operating system
What I often see when exploring what’s going on beyond the surface symptoms is lack of cohesion, frustration due to lack of alignment that leads to centralized decision making, and static up front planning that gives the comfort of predictability while not really delivering outcomes. These causes are very similar to what product and engineering leaders have been working to address for decades now, via “agility” - the realization that our work is rife with uncertainty and ambiguity and that in order to thrive we need to align on what’s important, create empowered teams that cut through functions, and work in an iterative manner to seek towards valuable desired outcome. There are different ways to apply this thinking - You might also call this OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, Scrum or any number of other techniques.
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 of 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 achieve their goals. It includes work on focus/flow, empiricism, and continuous improvement at all levels of the organization.
The Evidence-Based Management (EBM) framework created by Scrum.org provides a useful definition of the essence of this agility. 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.”
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 significant pain/frustration and a realization that the company simply can’t scale further with its current operating model.
Focusing on Growing Pains - Working ON the company vs IN the company
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 the company. Working IN the company might or might not require this way of working - that really depends on the different activities (e.g. selling the product using existing motions - working IN the company, developing new sales motions or GTM approaches - working ON the company)
Try this - once you develop your strategy for the quarter/year (e.g. your OKRs) assess each goal 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
Working ON the company will often involve some people who are also busy working IN the company. These people will struggle to balance their day jobs and transformation work. How much capacity should be assigned 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. If this transformation also coincides with other material company changes (e.g., new leadership, new investors/owners), the environment is even more volatile.
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.
Rethinking the classic functional structure - 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, and 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.
From developing products to developing companies
To recap where we are - Agile was born in software development and has been widely adopted in IT and Product organizations. While there are plenty of arguments around HOW to pursue agility, There’s little argument that product/technology organizations should move from a project-based to a product-oriented operating model leveraging agility principles.
More recently, other functions like Marketing have adopted agility principles and practices. Movements like “Agile Marketing” are a significant step forward, especially if the actual scope spans more than strictly marketers.
Working with these expanded “agile marketing” teams and seeing the power of collaboration across functions when tackling strategic initiatives was an eye-opener for me and made me notice the real prize - the evolution from agility focused on functional work towards the holistic definition of “company development” that I explored in this article.
If you are interested to explore how to leverage agility principles and practices to upgrade your business operating system - let’s discuss
A free email series on building an organization that reliably converts strategy into outcomes — without the coordination overhead.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →