The Checkbox Project (Part 2: Organizing for Outcomes)

This post is excerpted from the DevOps Enterprise Forum paper “The Checkbox Project: Learnings for Organizing for Outcomes.”

In our first post, we looked at a case study of what it took for an organization to implement a single checkbox on their website. The results were less than ideal. Now, let’s take a look at how to organize your organization toward better outcomes.

Evolving Your Organization toward Better Outcomes

The Checkbox Project reveals the costs of an organizational gap (i.e., an organizational structure that prevented fast flow of new value). One contributing cause is the manner in which large enterprises typically use reporting hierarchies as an anchor point for individual agencies. After all, if you don’t know who you are reporting to, how do you know where you belong or what you are supposed to do?

There is often a PowerPoint diagram that shows each name in a tree-like structure. It provides a collective perspective of who fits where. Ideally, this depicts the most efficient structure for future work. However, what is efficient for reporting and accountability isn’t necessarily efficient (or effective!) for customer value delivery. The functional orientation of typical organizational structures creates silos that are challenging to see or interact beyond, despite many functions being required to deliver a desired outcome.

But future work could touch every team in your entire company or a single team or somewhere in the middle. Ideally, the existing structures yield the shortest lead time for a new scope. Unfortunately, there are many dimensions that could impede the ideal state. The flow of work in many large organizations follows a meandering path through the organization and often even doubles back on itself (or wanders in circles) before making progress toward delivered value.

The following section will provide some ideas on how the Checkbox Project could be improved upon in future iterations. Let’s face it, there’s always another project! While there is certainly no “one right way” to organize for better outcomes, the tips below may help you on your way.

Foster Shared Visibility and Build Clarity

Part of the challenge of the Checkbox Project was the lack of visibility into what it takes to deliver what seemed to be a simple change. Beyond that, a major downstream issue arose. Every team involved in the change was alerted to their involvement in the midst of their existing backlog. Not only were there delivery costs but there were also opportunity costs to consider. And there are social costs! What’s the cost of delaying your current road map to accommodate a change from another division? What’s the cost of delaying twenty individual road maps and the commitments they entail?

To address this, consider the following:

• Map out the current landscape. Visualizing is a powerful thinking and collaboration tool, even if it is just a collection of post-it notes with all the teams involved in a particular effort. When you start to look at the big picture, you can begin to connect the dots that drive powerful conversations, insights, and decisions.
• Create a shared understanding of the goal. The successful achievement of any initiative hinges upon creating a shared understanding of the goals among all stakeholders involved and affected. By gathering stakeholders to share ideas, concerns, and perspectives, you can uncover surprising collective insight, clarity, and support. Tools like video recording, online white-boarding, or textual documentation create a future reference point that can be easily shared up, across, and down the organization.
• Map the value stream. Mapping your value stream is one strategic way of providing a shared view of the current state, constraints, and potential future flow of your operations. The data derived from value stream mapping can lead to profound realizations, can identify points of unnecessary or potential friction and waste, and can reveal clear opportunities for improvement. Additionally, the process of mapping and visualizing both organizational and technical dependencies encourages productive discussions and informed decisions.
• Manage the entire value stream. Investigate Value Stream Management as a large-scale flow improvement enabler. Lean practices and principles work well for large organizations looking to simplify and deliver value with less disruption. Large-scale efforts can be holistically measured, predicted, and even simulated to improve operational efficiency and effectiveness while minimizing risk.

Optimize Team Structure by Balancing Size and Autonomy

The Checkbox Project demanded extensive communication, coordination, and collaboration. Having every required contributor on one team is never an option, but neither is a multitude of silos. With millions on the line and dozens of teams at play, it pays to invest in an organizational structure that facilitates agility and quicker time to market.

• Leverage resources and interaction modes that replace face-to-face coordination, consensus, and consultation. Each of the blocking decisions that stopped the Checkbox Project from proceeding could have been assisted by decision trees or filters, frameworks, documentation, and principles that guide decision-making and tactics. Of course, you can’t think of everything in advance, and there are diminishing returns (and maintenance costs!) for resources, but there is great value in minimal investments and doubling down where opportunities prove fruitful.
• Applying Team Topologies can help clarify cross-cutting accelerators, like an enabling team for partner offers or the creation of a platform team or complicated subsystem team for facilitating billing changes.
• Achieving sustained performance and value delivery requires a decisive product owner who has the authority to make strategic decisions. Amazon’s Single-Threaded Model establishes and supports decision rights and ownership (along with accountability) at the team level. This aligns with the principle of pushing decision-making capabilities down to the level where they can be most effectively deployed but also where the context is most relevant and available. The result is low-latency, high-signal decision-making and action.
• One approach that aids this autonomy (and loosely coupled composability with other teams) is to think of your teams as APIs. APIs are accessible, easily leveraged, independent, and composable. By emulating these properties within your team structure, their capabilities become clear and easily accessible to dependent teams without necessitating costly direct, synchronous interactions. This approach, as exemplified by Amazon within AWS, has proven highly successful.
• Reducing the need for coordination between teams also helps to ease cognitive load and distractions. Implementing service catalogs can help define and clarify roles, responsibilities, and operations across teams. Team APIs create clarity and visibility around team interactions, capabilities, and dependencies. A service catalog can start to create definitions around teams and interactions with minimal up-front investment.

Architect for Agility

System architecture is either as decentralized or decoupled as the organizations that drive it. The disruptive “all hands on deck” and deep coordination called for by the Checkbox Project can be avoided when each team can autonomously accommodate a change according to their schedule and priorities without impeding dependent teams. You may need a database change to fully implement a change, but if all that’s required of your team is an API call, you can deliver and move on. Additional opportunities to architect for agility include the following:

• Serverless options reduce requirements for ground-up infrastructure investments while allowing for fast experimentation and design changes.
• Event-driven architecture enables loosely coupled systems through publishing, subscribing, and reacting to events or “state changes.” This facilitates quick changes and new features with minimal risk and little need to coordinate across publishers and subscribers.
• API-first architecture simplifies interfaces and interactions, allowing teams to develop more and faster without deep coordination or dependencies. Domain-driven design establishes clear domain boundaries in a product-oriented and agile model. It also fosters a common language for building comprehension among both technical and non-technical team members. More clarity and definition means more action without getting everyone in a room to hash things out when.
• Platform engineering practices and product thinking for platforms are rapidly evolving. There are minimal starting points, good practices, and capable platform-as-a-service offerings. Shared platforms reduce tight coupling and the interrupt-driven model of shared teams, where tickets and queues dominate over self-service access to capabilities. Parts Unlimited could have avoided significant dependency delays by investing in the ability for delivery teams to access platform capabilities to perform actions like adding data fields, events, producers, and consumers of changes like checking a box.

Measure the Cost of Heroic Cross-Cutting Efforts

Cost is often a powerful motivator. It tells a story in a language many leaders understand. Value stream mapping combined with financial data can reveal surprising insights. In the case of the Checkbox Project, it would have revealed in a couple of hours what lay ahead as months of struggle and uncertainty, prompting a careful and strategic approach. After the project, it would reveal the most costly and wasteful aspects of the initiative, which could be improved prior to the next effort.

Tactics to minimize the cost include the following:

• Pick a product or initiative: Measure your most complete lead time and value stream metrics within that flow.
• Find the constraint and contributing friction: Odds are the friction points and delays are linked to organizational dependencies external to the team involved.

Evolve Your Operating Model

Massive coordination costs, like those in the Checkbox Project, can be avoided by an internal operating model that resembles what most organizations offer beyond their boundaries. Most partner-driven initiatives are facilitated with various interfaces that enable decoupled action. The interaction typically follows an “If you do this, and we do this, we’ll meet in the middle” framework. But as that dynamic evolves, it becomes more like a vending machine experience, with no direct interaction necessary.

Some options to evolve your operating model include the following:

• Investigate Self-Service: Operational efficiency can be significantly improved through the customer-centric model of services and capabilities, enabled by self service. Published styles, operational models, and architectural guides serve as standard reference points, as do form, data, and SLA standards. When combined with API-first approaches, this means that resources and capabilities are available for consumption and contribution on-demand.This model encourages self-reliance and streamlines operational processes. Pulling just what’s needed, when needed means less waste and more customer-supplier relationships throughout the organization, which translates to a natural extension to external customers and partners. Parts Unlimited could adopt a stream-aligned model (as in Figure 6), where each customer need is fulfilled by a stream-aligned team of cross-functional contributors able to access and leverage shared capabilities offered by internal platform streams. This not only reduces disruption and tight-coupling of dependencies, but creates a powerful “customer-centric” dynamic throughout the entire organization.

• Investigate the Internal Partner Network Model: At the advanced level, your organization can be reimagined as an internal partner network. By leveraging the experiences, models, and architectures of external partner networks, you can create a self-service access system to various capabilities. Salesforce’s AppExchange marketplace, for instance, is a great model to reference. Standard frameworks and SDKs, along with comprehensive documentation and support, form the backbone of this model. They provide their own apps, beta products, workflows, data, and thousands of partner apps on the system. It provides automated pipelines, low or zero-trust implementations, and automated verification systems. With this model, burden is matched with incentive, pushing individuals to fulfill all requirements before pushing for a change. This helps ensure operational efficiency and stability while encouraging personal responsibility and ownership.

Finally, regardless of where and how you start, you may benefit from familiarizing yourself with the principles in the full paper. These transcend specific situations, methods, and guidance. They are applicable to every circumstance in which it is necessary to organize for better outcomes.

Read the full paper in the Fall 2023 DevOps Enterprise Journal.

- About The Authors

Kamran Kazempour

Chris Hill

Speaker, author, leader, evangelist, engineer, researcher, and disruptor in developer relations and experience

Follow Chris on Social Media

• 
• 

Steve Pereira

Steve Pereira has spent over two decades improving the flow of work across organizations. He’s worked through tech support, IT management, build and release engineering, and as a founding CTO for enterprise SaaS. He serves as lead consultant for Visible Value Stream Consulting, as a board advisor to the Value Stream Management Consortium, Chair of the OASIS Value Stream Management Interoperability technical committee, and co-founder of the Flow Collective to bring flow-focused professionals together. Since 2017, he has been developing and facilitating Flow Engineering to make flow improvement in large organizations accessible, collaborative, and actionable.

Follow Steve on Social Media

• 
• 

Dean Leffingwell

Cofounder and Chief Methodologist at Scaled Agile, Inc.

Follow Dean on Social Media

• 
• 

Amy Willard