Warning, this is a story that might sound familiar.

The frustration on the chief technology officer’s (CTO) face was palpable. One year prior, the $50 billion financial institution he worked for announced it was going “all-in” on the cloud to save costs and become nimbler. The CTO assumed the cloud was “just another data center,” and his teams approached their architecture and governance efforts accordingly.

His organization tried to implement security controls with the same set of operating models, architectures, practices, and tools that were used in its physical networks. The company experienced regulatory requirement delays and audit setbacks and was mired in compliance black holes, security red tape, and governance stagnation. With this approach, spinning up a computing instance was slower than racking and building a physical server in the data center it left.

Fortunately, the financial institution was able to turn its situation around—when the CTO made a mindset shift from a process-focused approach to a capability-based approach.

About the authors

Hart Rossman AWS

Hart Rossman


Rossman is vice president of global services security at AWS, leading a team of geographically distributed AWS builders. He helps customers realize the benefit of planetary scale security solutions in the cloud with a focus on innovating and deeply collaborating with teams across the broader AWS organization and partners.


Cliff Donathan AWS

Cliff Donathan


Donathan is a principal security advisor for AWS, specializing in executive strategy. Donathan has more than 20 years of experience in risk management, security, and governance. He is an advocate for women in technology and started a foundation to grow amputee soccer for women and girls both domestically and internationally.

Traditional operating models take a process-focused approach, separating teams based on physical assets and associated activity workstreams. For example, organizations traditionally create a user access management team, system operations team, network operations team, security team, and so on.

In an on-premises environment, this makes sense and is the easiest way to build teams. The network team has specific skills to accomplish specific tasks on specific hardware and uses a specific set of tools to assist them. When a network issue arises or particular connectivity is needed, people know to go to the network team for help. The same is true for the user access management teams, systems operations teams, and other teams needed to support the business.

Process-focused models have worked well because it is often easier to hire a network engineer than it is to hire an expert in network, security, access, and data. Information technology leaders can see where in the workflow things have broken down and can devise solutions.

A downside to this operating model is teams are encouraged to optimize within their specialized domain and process silos develop, which can diminish the larger security outcome for the end customer as well as the business. Teams don’t have the knowledge or authority to act outside of their narrow band of responsibility. This creates delay and churn as teams operate with incomplete data and dramatic changes in compliance regulations, resulting in infrequent releases.

Teams are not empowered to make decisions, and simple requests can take weeks to implement as approvals are passed from team to team. Instead of focusing on customers, CTOs spend time on improving lean processes.

Instead of separating teams by asset class and activity, capability-based operating models organize teams to achieve a particular outcome, with the knowledge and authority to receive, approve, prioritize, and execute tasks efficiently to achieve that outcome. Similar to how a DevOps team is responsible for the end-to-end facets of an application, including design, development, test, security, implementation, and maintenance, a capability-based team is empowered to perform all actions necessary to own its domain.

For example, the platform engineering group has the authority to perform certain actions within systems, operations, security, governance, and networking. The group is governed by a leadership team that is well coordinated and is completely focused on customer outcomes, unblocking things for speed and agility.

The cloud allows for this type of mindset shift to be possible. The cloud offers native tooling that enables shifting your organizational structure to align with a capability-based operating model. Capability-based organizations can focus on delivering outcomes for customers, instead of concentrating on different departments and processes.

The CTO of the $50 billion financial institution we mentioned at the beginning was able to turn the situation around by shifting his mindset from a process-focused approach to a capability-based approach. He was able to apply practices that enabled teams to reduce cloud service approval from eight months to two weeks. With the ability to approve services faster, the CTO began automating routine processes, governance reporting, and security controls.

Shifting to a capability-based approach frees you to focus on what matters most: providing your customers with better products and services. That’s a story with a much more palatable ending.