You show me a successful complex system, and I will show you a system that has evolved through trial and error.

—Tim Harford, Economist

Read any contemporary article on organisations and within the first few sentences the word, “agile” appears at least once. Some articles suggest achieving agility with a new target operating model (TOM), a way of rethinking processes and cultures to breakdown silos and accelerate time to market. Others suggest alternative structures to better lubricate the wheels of value delivery. These and other comparable suggestions are not necessarily wrong, but they are often light on the “how.” There is a presumption that agreeing on an end-state structure is the hard part of transforming. The reality is different, as I describe in my blog post on living transformations.

After a positive reception to our keynote, “How not to sabotage your transformation,” my colleagues and I on the Enterprise Strategy team set out to better understand how organisations move towards more agile operating models. Hours at a whiteboard yielded a messy hairball of activities and barriers representing the transformation journeys of our previous organisations towards greater speed, cost-effectiveness, and business focus. Informed by the numerous observations AWS customers have shared with us, our initial work to understand the complexity of transformation identified 160 challenges and intervention points – few of which can be predicted while sitting around a conference room table.

Take, for example, creating the two-pizza teams featured in Tom Godden’s blog post. Conceptually, a dedicated, high-performing team focused on delivering a business outcome makes sense, right? Digging deeper reveals challenges. Who sets this team’s goals? How is the best talent in the organisation freed to join the team? How should dependencies be minimised outside of the team? How is the team funded? Whether or not the team delivers on an outcome, how are compensation and bonuses handled? How long should the team exist, and who decides that the team’s mission is accomplished? What mandates and guardrails should a team be required to follow?

TOMs

Therein lies the issue with TOMs. They are easy to agree to—who doesn’t want to be more agile, more business-focused, and faster to market? The devil is in the details. A TOM is great if it defines key metrics of success, but most stipulate structures that require significant rewiring of an organisation. Even the term “rewiring” is a flawed metaphor; dynamic systems are not machines with easily replaceable component parts, and wholesale changes to organisations normally fail.

Transforms require (a) alignment on what “good” looks like and how it is measured and (b) leadership that drives improvements in every aspect of the organisation every day. This doesn’t necessarily require a project management office—more bureaucracy cannot address complex issues. (The Paperwork Reduction Act of 1980 illustrates this; it spawned more bureaucracy and, ironically, a significant increase in paperwork.)  Transformation requires a culture that recognises and encourages employees to drive change from their seats, challenging the bureaucratic shibboleths designed to prevent 1% of employees from doing unintentional harm but, in fact, impeding the remaining 99% of the organisations from moving fast.

Focus Areas

Our team’s research, experiences, and learnings identified six areas leaders should focus on to embed agility. Our hypothesis is simple: If each of these areas can be incrementally and consistently improved upon, you can create a better version of your organisation in a practical, sustainable way with much less trauma than in typical transformations. These focus areas are based on three principles. First, an organisation has no end state. Stopping improvement quickly leads to more organisational debt, such as stultifying bureaucracy and the inability to adapt to environmental changes. Second, organisations exist to deliver outcomes against a well-defined purpose. Third, agility is one of the last remaining competitive advantages, giving the ability to be responsive and resilient in the face of change.

So what are these focus areas? Each is worthy of its own blog post, but I’ll briefly sketch them out here.

Highly Aligned

Ask ten people in an organisation what’s important, and you will likely get eight answers, even within the C-suite. We like to think those carefully crafted top-down goals cascade to even the most junior developer. There are common anti-patterns here—seven strategic pillars based on six strategic imperatives and 52 goals, anyone? More pointedly, it’s impossible to express everything in terms of specific goals, especially in a dynamic environment. The military understood this years ago. They communicate a commander’s intent—a direction and outcome, not specific activities—that everyone understands. This intent is underpinned by principles or tenets, which help create a common language and understanding for decision-making. After all, if you aren’t all marching in the same direction, how can you possibly end up at the same destination?

Local Autonomy

To become faster, more resilient, more cost-effective, and more relevant, decisions should be made as quickly as possible by those with the most information—those who are closest to customers and their reactions. Yep, that’s not typically the CEO. There’s a balance here, though. Without alignment on a common mission, this autonomy could quickly devolve into anarchy, where decisions are made without consideration of the wider organisational mission and trade-offs.

Appropriate local autonomy minimises dependencies between different parts of an organisation. Dependencies are defects that should be eliminated to enable teams to move quickly, analogous to building loosely coupled applications. It’s easier technically (think APIs and microservices) than it is organisationally. It also requires the psychologically and organisational divide between IT and “the business” to be eliminated. Assessing how many handoffs there are and how long it takes to get an idea from concept to production is a great starting point to improve this area.

Focus on Outcomes

We have a habit in modern organisations of saying, “I’ve done my job,” rather than defining “done” as when a customer’s need is really met. We focus on outputs such as test scripts executed or story points completed, not what actually matters—the value delivered. Simple steps have a profound impact here. Get out of the building, walk in your customers’ shoes, and work backwards from their problems, not forward from your requirements or predetermined solutions. Get specific about goals and eliminate weasel words (e.g., “deliver game-changing features faster”). Focus on those things you can control, such as inputs to drive meaningful outcomes and reduce the amount of undifferentiated work to free time.

Right-Sized

Delivering meaningful outcomes normally means working across your organisational structure and is most effectively done in teams. These teams need to be of useful and manageable size with the right skills, culture, and attitudes. Too many people on the team risks a lack of trust and overhead, and too few leads to dependencies on other teams. Building these teams is a voyage of discovery unto itself. Seek diverse skills and worldviews with a cohesive culture that values differences and channels them to deliver outsized outcomes. You need the right skills for the problem at hand; a high dose of EQ to enable positive, continuous feedback; and the ability to cross-train team members. You want your A-players with room to bring others in as development opportunities. If done well, these teams focus on a single outcome (rather than pretend to multitask) and remain energised about the mission ahead.

Well-Controlled

Earlier I mentioned the risk of anarchy, but gone are the days of choosing between speed and security. Good central technology teams automate guardrails, infrastructure, pipelines, monitoring, and security so outcome-focused teams can do the right things easily. It’s a win-win—minimal dependencies, better consistency, and great flexibility without the overhead of raising multiple tickets and attending a plethora of coordination meetings. Teams like the security team become seen as enablers, not the “departments of no.”

Long-Lived

Once formed, teams go through a process of forming, storming, and norming. Over time, with the right coaching, they reach and maintain high performance levels. So why disband such teams based on arbitrary timelines and outcomes? Maintaining these teams heightens trust, a foundation for agility. These teams learn to take accountability for their cost footprint, supporting their developments and continually iterating to deliver incremental value.

Making improvements in each of these areas incrementally and persistently while preparing to pivot based on learnings is the essence of sustainable, meaningful organisational improvements. It’s not headline-grabbing, but your employees, customers, and stakeholders will thank you for your leadership.

—Phil