Cloud Strategy - Part II:  Organizing for the Cloud

Cloud strategy is not just a migration plan or a list of services to adopt. It is a set of business and technical choices that defines why the organization is moving to cloud, which outcomes matter, and how decisions should be guided. This article focuses on the organizational side of cloud adoption: leadership, governance, skills, accountability, operating model, and the principles needed to turn cloud from disconnected technical projects into a real business capability.

This series provides an annotated review, summary and analysis of Gregor Hohpe’s book, Cloud Strategy, available at leanpub.com/cloudstrategy.

Executive summary

Cloud strategy is not a migration plan, a technology roadmap, or a list of cloud services to adopt. It is a coherent set of choices that explains why the organization is moving to the cloud, which outcomes matter most, which trade-offs it is willing to make, and how technical and organizational decisions will be guided over time.

This second part of the series focuses on the organizational side of cloud adoption. The central argument is that cloud transformation is not mainly about moving infrastructure from a data center to AWS. It is a change in business model, operating model, skills, leadership, governance, and accountability. Cloud can improve delivery speed, resilience, security visibility, and cost flexibility, but those benefits are not automatic. They must be earned through clear priorities, a secure foundation, automation, managed services, cost accountability, training, and continuous measurement.

The article proposes practical cloud strategy principles such as business value before migration, foundation before scale, guardrails before freedom, automation before manual process, product ownership before project handovers, and outcomes before activity metrics. These principles are not universal rules; they are examples of the kind of explicit choices every organization must adapt to its own context.

The key message for leaders is simple: cloud success depends less on the provider selected and more on the organization’s ability to change how it makes decisions, funds work, develops people, manages risk, and measures value. A weak or invisible leadership model turns cloud adoption into a collection of disconnected technical projects. A strong strategy turns it into a business capability.

What is a strategy?

Strategy is not a plan

Strategy is not a plan, a detailed list of tasks with exact deadlines and dependencies. A strategy is not a Gantt chart.

Strategy is a coherent set of choices that explains where you want to go, why it matters, what you will prioritize, what you will not do, and how you will win or succeed under real constraints. In the context of cloud migration:

Why are we moving to the cloud, what business outcome are we pursuing, which trade-offs are we willing to make, and how will we guide the many technical and organizational decisions?

Definition of a good strategy

Example of a weak cloud strategy:

We will migrate to AWS to reduce cost, improve agility, increase security, modernize applications, use AI, improve resilience, and enable innovation.

This is not really a strategy. It is a wish list, far too generic. Example of a better cloud strategy:

We will use AWS primarily to increase delivery speed and reduce operational burden for new digital products. We will not migrate every legacy system immediately. We will first build a secure multi-account landing zone, establish cost and security guardrails, train product teams, and prioritize applications that benefit from managed services, automation, and elastic scaling. Stable legacy systems with no clear business case will remain on-premises until renewal or replacement.

This is closer to strategy because it contains priorities, exclusions, sequencing, and trade-offs.

Priorities: what matters most?

A weak strategy tries to pursue everything at once:

We will reduce cost, improve security, increase speed, modernize applications, improve resilience, enable AI, and transform the organization.

All of these may be desirable, but they cannot all be the top priority at the same time. A real strategy says:

For the next 18 months, our primary goal is to increase delivery speed for customer-facing digital products. Cost optimization is important, but it is not the first driver of the cloud program.

That changes decisions. For example, if speed is the priority, you may accept higher short-term cloud costs in exchange for managed services, automation, and faster deployment.

Exclusions: what are we not doing?

Strategy is also about saying no. For example:

We will not migrate every legacy application immediately. Stable back-office systems with low change rates and no clear business benefit will remain on-premises for now.

Without exclusions, cloud programs often become huge migration exercises where everything is moved simply because “cloud is the strategy.”

The cloud itself is not the strategy. Cloud is a means to achieve selected business outcomes.

Sequencing: what comes first?

A good strategy defines the order of action. For example:

We will first build the landing zone, identity model, logging, network connectivity, security guardrails, and cost governance. Only after that will we migrate production workloads.

Migrating applications before building the foundation may look faster, but it often creates security gaps, cost sprawl, inconsistent account structures, and operational confusion.

So sequencing answers: what must be true before the next step can succeed?

In cloud adoption, the answer is often: foundation before scale, governance before freedom, skills before autonomy, and pilot before mass migration.

Trade-offs: what are we willing to sacrifice?

Every meaningful cloud decision has a trade-off. For example:

We will prefer AWS managed services where they reduce operational burden, even if that increases dependency on AWS.

That is a strategic trade-off. You are choosing speed and reduced operations over maximum portability.

A weak strategy pretends there are no trade-offs:

We want maximum speed, minimum cost, zero lock-in, full control, full automation, total flexibility, and no organizational disruption.

That is not a strategy; that is magical thinking.

A meaningful strategy is built on creativity and discipline.

Creativity: think big and brainstorm. Discipline: concrete plan and trade-offs. Explore options, select a few that are achievable and give value back, communicate your choices.

As a business leader choosing which projects to fund, avoid falling for the most unsubstantiated or exaggerated claims. Reality always pushes back. When an unrealistic initiative fails, the problem is not only execution; it may be the initiative itself and the decision to fund it.

Gregor Hohpe then defines a checklist to evaluate strategic principles:

• If the opposite of a principle is nonsense, it’s likely not a good one. Everyone wants happy customers and a high-quality product, so turning them into a principle won’t guide a lot of decisions.
• Principles that include product names or specific architectures (usually in the form of buzzwords) run the risk of being decisions that wanted to be elevated to principles—an unwelcome form of reverse engineering.
• Principles should pass the test of time. No one is a clairvoyant, but it helps to imagine whether the principle is still likely to make sense in a few years’ time. A good proxy can be looking back three years and finding poor examples.
• It helps if the list of principles employs parallelism, meaning they apply the same grammatical construct. For example, it’s useful if all principles consist of full sentences or just nouns. Mixing the two will make them look awkward.
• Principles should be memorable. Few teams will walk around with the list of principles on a cheat sheet, making principles that no one remembers unlikely to influence many decisions. If you’re placing the principles on motivational posters plastered on the office walls, you’re likely kidding yourself.
• Although there is no magic count for the number of principles, less than a handful might be sparse, whereas more than a dozen will be difficult to remember.

A principle is weak if its inverse is nonsense. For example, “we want satisfied customers” is hard to use as a strategic principle because no serious organization would choose the opposite. Reflecting on my own journey, however, I have frequently observed that even these fundamental, self-evident goals are neglected in practice. In a cloud strategy, I would not discard them entirely; I would make them concrete enough to guide decisions. “Improve customer satisfaction” becomes more useful when translated into measurable priorities such as reducing outage duration, accelerating feature delivery, or improving response time for customer-facing applications.

Cloud strategy principles

Having established the criteria for effective principles, we can examine specific examples. It is important to recognize that, in my opinion, no universal list exists; the sheer number of organizational variables requires that every strategy be tailored to the unique business objectives and internal competencies of the enterprise. A cloud strategy is defined not by what the company says it wants, but by the decisions it is willing to make.

Business value before migration

Cloud adoption should start from business outcomes, not from the desire to move infrastructure. The goal is not to migrate as many servers as possible. The goal is to improve the company’s ability to deliver value: faster product delivery, better resilience, improved security visibility, access to managed services, better data capabilities, or more flexible cost models.

Decision guidance: prioritize workloads where cloud capabilities create visible business or operational value.

Foundation before scale

Before scaling cloud usage, the organization needs a secure and governed foundation: account structure, identity, networking, logging, monitoring, security baselines, backup, cost controls, and operational processes. Moving quickly without a foundation can create future problems: inconsistent environments, weak access control, missing audit logs, cost sprawl, duplicated architectures, and unclear ownership.

Decision guidance: build the landing zone, guardrails, and operating model before large-scale production migration.

Guardrails before freedom

Teams should be able to move fast, but only inside safe boundaries. Cloud self-service is powerful because teams can provision resources without waiting weeks for infrastructure. But without guardrails, the same freedom can create security, compliance, and cost risks. The goal is not to slow teams down with manual approvals. The goal is to automate the rules: allowed regions, mandatory logging, encryption, identity policies, network standards, cost tagging, and security controls.

Decision guidance: replace manual control with automated guardrails wherever possible.

Managed services before undifferentiated operations

Cloud should reduce the amount of infrastructure the organization has to operate directly. When a managed service can safely reduce operational burden, improve reliability, or accelerate delivery, it should be preferred over building and operating the same capability manually.

This does not mean blindly using every managed service. Managed services can create provider dependency, cost implications, and architectural constraints. But avoiding managed services only to preserve theoretical portability often reduces the value of cloud.

Decision guidance: use managed services deliberately when the operational benefit is greater than the dependency risk.

Automation before manual process

Cloud infrastructure should be created, changed, and governed through automation. Manual cloud operations do not scale well. They are hard to audit, hard to reproduce, and easy to misconfigure. Infrastructure as Code, CI/CD pipelines, policy as code, automated testing, and automated security checks are essential to make cloud reliable and repeatable.

Automation is not only about efficiency. It is also about consistency, auditability, speed, and risk reduction.

Decision guidance: if a task will be repeated, audited, or used in production, automate it.

Product teams before project handovers

Cloud works best when teams own what they build and run. Traditional IT often separates architecture, infrastructure, security, development, operations, and finance into different silos. Cloud changes this model because teams can make infrastructure, security, deployment, and cost decisions continuously.

A cloud operating model should move toward product ownership: teams should understand their applications, infrastructure, security posture, operational health, and cost. Central teams should provide platforms, reusable patterns, and guardrails, not become bottlenecks for every decision.

Decision guidance: organize cloud around long-lived ownership, not one-time project delivery.

Security by design, not by inspection

Security should be built into the cloud foundation and delivery process, not added at the end. In the cloud, many security risks come from configuration, identity, permissions, exposed services, missing logs, weak network design, and unmanaged data. These risks cannot be managed effectively through occasional manual reviews alone.

Security must be designed into account structure, identity, network boundaries, encryption, logging, deployment pipelines, and policy controls.

Decision guidance: make secure configuration the default, and make unsafe configuration difficult or impossible.

Cost accountability from day one

Cloud cost should be visible, allocated, and owned from the beginning. Cloud turns infrastructure spending into a continuous, usage-based financial model. This creates flexibility, but also risk. Without cost governance, teams can create resources, duplicate environments, store data, generate logs, or overprovision capacity without understanding the financial impact.

Cost optimization should not be treated as a cleanup activity after migration. It should be part of architecture, ownership, tagging, budgeting, monitoring, and product economics.

Decision guidance: every cloud resource should have an owner, a purpose, and cost visibility.

Resilience through architecture, not assumption

Using the cloud does not automatically make applications resilient. Cloud providers offer regions, availability zones, managed services, backups, replication, scaling, and disaster recovery options. But the customer must design the application and operating model to use them correctly.

A workload moved to cloud without architectural changes may still have single points of failure, poor recovery procedures, weak backup design, or untested failover.

Decision guidance: define resilience requirements explicitly, then design and test for them.

Modernize where it matters

Not every application deserves the same level of modernization. Some systems should be retired. Some should stay where they are. Some can be rehosted temporarily. Some should be replaced with SaaS. Some are worth refactoring because they support important business capabilities.

Cloud strategy should avoid both extremes: migrating everything unchanged, or refactoring everything unnecessarily.

Decision guidance: invest modernization effort where it creates meaningful business, operational, or risk-reduction value.

Skills before autonomy

Teams should not be given cloud freedom before they understand how to use it responsibly. Cloud adoption changes responsibilities for developers, operations, security, finance, procurement, and leadership. Teams need training not only on cloud services, but also on the shared responsibility model, cost management, automation, security, incident response, and governance.

Without skills, self-service becomes a risk. With skills and guardrails, self-service becomes speed.

Decision guidance: increase team autonomy as cloud competence and platform maturity increase.

Measure outcomes, not activity

A cloud program should not be measured only by the number of migrated servers, accounts created, or services adopted. Those metrics measure activity, not value. Better measures include deployment speed, recovery time, cost transparency, security posture, infrastructure provisioning time, operational effort reduced, customer impact, and business capabilities enabled.

This principle prevents cloud adoption from becoming a vanity migration program.

Decision guidance: measure whether cloud is improving the business, not just whether cloud usage is increasing.

Start small, learn fast, then scale

Cloud adoption should begin with controlled learning, not a massive transformation program. A first wave of workloads should prove the foundation, operating model, governance, cost controls, and team readiness. The organization should learn from real workloads before scaling migration.

This reduces risk and prevents large strategic mistakes from being repeated across many applications.

Decision guidance: use pilot workloads to validate assumptions before industrializing the migration.

Keep the strategy honest

A cloud strategy should be reviewed against reality. If costs are rising without value, if teams are slower instead of faster, if security exceptions are increasing, or if managed services are creating more complexity than they remove, the strategy needs adjustment.

Cloud strategy is not a document written once. It is a set of choices that must be tested, measured, and refined.

Decision guidance: revisit cloud principles and priorities regularly based on evidence, not enthusiasm.

Cloud is a business transformation

Cloud is not just an IT initiative ; it is a business modernization and transformation process that involves all aspects of the organization, not just technology. Traditional on-premises IT focused on capacity planning, predictability, procurement, separation of roles, and long-term budgets. In contrast, the cloud favors elasticity, automation, fast feedback, and ownership of every aspect and layer of the application.

The cloud provides the platform on which applications will run and data will be stored, an ecosystem of services that can be integrated in many ways to reshape the business and the organization.

Gregor Hohpe emphasizes that cloud computing is not merely a product to purchase or a cheaper hosting solution; rather, it is a new business model that requires companies to adapt their internal structures and behaviors, from budgeting to architecture.

Cloud often attracts with buzzwords and promises: lower cost, faster delivery, higher resilience, and better security. These are aspirations, not strategies. They must be earned; they do not appear automatically or for free.

As previously noted, effective strategies demand trade-offs — such as balancing cloud portability against the adoption of managed services. Opting out of managed services often means sacrificing the very factors that drive development velocity and application availability.

Traditional organizations are often organized into functional silos:

• Infrastructure teams
• Security teams
• Delivery or DevOps teams
• Governance and compliance teams

Maintaining a traditional silo-based structure in the cloud creates unnecessary friction and delays through handoffs. Cloud adoption favors an application-centric design for roles and responsibilities. Teams can build, deploy, and operate their own infrastructure using code, templates, and standards. Meanwhile, operations and platform teams become more effective by managing shared foundations, such as the landing zone, and by developing reusable modules and patterns that incorporate best practices and security policies.

Cloud is people management

The business transformation starts with people and is realized by people. It is the most important factor in migration success and often the most ignored.

Hohpe extends the familiar “R” vocabulary of cloud migration to people management: retain, reskill, replace, retire.

Retain — Some jobs will not change, or will change only slightly. For example, project managers may shift toward agile delivery and product-oriented ways of working rather than one-time project delivery.

Reskill — Some roles might keep the title but require very different skills. For example, IT operations may shift toward automation, golden images, observability, incident response, and platform engineering. Reskilling is usually the first choice: existing staff already know the business, the applications, and the current infrastructure. Training new people takes months, and hiring is often a long, painful, and expensive process, assuming you can find the right candidate.

Replace — Reskilling is not always possible or desirable. Some people have spent years becoming experts in their field, and it may make little sense for them, or for the organization, to switch to a completely new skill set.

Retire — Some responsibilities associated with direct data center facilities management may shrink or disappear, such as hardware installation, rack planning, and physical capacity management. Other responsibilities, such as vendor management, procurement, financial control, and risk management, do not disappear; they change shape in the cloud.

Hohpe warns against the “fifth R”: relabeling roles. For example, project managers may be renamed Scrum Masters and teams renamed “tribes” without removing the existing roadblocks.

“With existing structures and incentives remaining as they are, such maneuvers accomplish close to nothing besides spending time and money. Organizations don’t transform by sticking new labels on existing structures.”

In my view, internal training is the most critical component of people management for successful cloud migration and long-term business prosperity. Without adequate training for everyone involved—including business leaders and finance teams—it is impossible to implement the changes required by the new cloud model. Without training for developers and software architects, operations and security teams will spend most of their time firefighting architectural mistakes or troubleshooting cost spikes and skyrocketing bills. Without training for operations teams, developers will spend time reinventing the wheel to address common networking, monitoring, and security issues. Ultimately, leaders will be unable to formulate sound strategies or make critical architectural decisions, failing to reap the full benefits of the cloud. I have seen it happen.

Regarding training, I caution against the 'magical thinking' that assumes learning can occur in the fragmented spare time developers have between high-priority tasks and daily legacy system maintenance. Relying on individual, optional effort to drive company-wide transformation is a dangerous illusion. For cloud initiatives to succeed, organizations must provide dedicated time, resources, and incentives for training; otherwise, it simply will not happen.

While true learning comes from hands-on experience rather than online courses, a structured, role-based training path is essential to establish the shared vocabulary and foundational understanding that teams need to build upon.

AWS certifications are one of many available options. While numerous free and commercial resources exist to help you pass these exams, the primary goal should be mastering the material rather than simply test preparation. Understanding the core content of these courses is often sufficient. Below, I have outlined a standard mapping between organizational roles and relevant AWS certifications as an example.

One of the many positive aspects of the cloud is its capacity to attract top-tier talent, as skilled professionals are naturally drawn to environments that prioritize innovation over maintenance. Conversely, a lack of modernization and the absence of meaningful technical challenges can drive your best engineers away, leading to a drain of institutional knowledge. To prevent this, companies should reward their top performers and empower them to initiate a positive feedback loop where talent attracts talent, ultimately streamlining the hiring process and reducing recruitment costs.

Motivating engineers requires a clear career progression framework based on skills acquired and results, coupled with the active removal of rigid, bureaucratic processes that stifle creativity. This transformation often uncovers unrealized potential within the existing workforce—motivated employees who have been held back by legacy procedures but are ready to excel once the operating model is modernized.

Furthermore, attracting high-caliber staff often requires “ice breakers”: enthusiastic individuals willing to lead the initial charge of a major transformation and prove the new model’s viability. By focusing on people management and cultural change, organizations ensure that their cloud journey is supported by the very people responsible for executing it.

Cloud is a leadership challenge

Since the cloud is a business transformation, success depends heavily on leadership: executives must set priorities, make trade-offs, fund the right capabilities, empower the right people, and stay involved beyond the migration decision.

• Leaders need to set priorities and provide clear direction.
• Leaders need to balance the plan with emerging opportunities, course-correcting when it makes sense.
• Leaders need to allocate resources according to the strategy: saying you want something will not make it happen.

“To understand a company’s strategy, look at what they actually do rather than what they say they will do.” — Andy Grove, former CEO of Intel

You cannot have it all: setting priorities means making choices. If everything is a high priority, then nothing is. Hohpe compares IT to a machine with many moving parts, knobs, and levers that are interrelated and cannot all be set to “10” at the same time. This recalls a phrase often attributed to engineering and project management culture:

Good, fast, cheap: pick two.

The idea is that project outcomes, including cloud transformation, are constrained by competing forces, and leaders should be aware of the trade-offs and have realistic expectations:

Leaders, including the CTO and business sponsors, must drive the momentum of a cloud migration. A migration is more likely to fail when leaders remain silent and invisible, neglecting to solicit feedback or make decisive, high-level choices.

Cloud transformation is a cultural transformation, and as Hohpe says:

There is no Stack Overflow for transformation where you just cut and paste your culture change and compile.

While external consultants can help accelerate your progress and avoid common pitfalls, it is ultimately the leadership and their cloud strategy that determine the success of the migration.

“If you let externals or vendors define the strategy, you’ll be surprised how well their products fit your strategy” — Gregor Hohpe

When cloud migrations fail, they are rarely blamed on weak or missing leadership. Instead, those failures are usually hidden behind vague explanations such as budget overruns, lack of governance, skills gaps, or messy architectures. This risk is reflected in Kyndryl’s 2025 Cloud Readiness Report, which found that 70% of CEOs say their cloud environments were built “by accident, rather than by design.” This does not prove that every cloud program is accidental, but it strongly suggests that many organizations allow cloud adoption to emerge through disconnected, reactive projects rather than through a deliberate strategy.

McKinsey, one of the world’s largest management consulting firms, found that companies outperforming in cloud migration were 32% more likely to have active CEO sponsors. They were also more likely to develop the full roadmap, including security and compliance, upfront rather than funding disconnected one-off initiatives. McKinsey also found that cloud migration outperformers were 57% more likely to hire advanced skills such as DevOps and FinOps. This matters because weak leadership often underfunds the non-obvious work: training, platform engineering, FinOps, security automation, change management, and operating model redesign. The migration budget may pay for tools and execution, but not for the organizational capabilities needed to run cloud successfully afterward.

Before starting a cloud migration, take a serious look at what is currently running. To build a real strategy, IT leaders need to identify where things are breaking, what creates the most operational pain, and which systems are consuming budget without creating proportional value. A good starting point is an application inventory: what each application does, who owns it, what it depends on, what data it uses, how critical it is, and whether it should be retired, retained, replaced, rehosted, replatformed, or refactored. Cloud migration includes an element of outsourcing, but it will not magically solve existing IT problems.

“There’s an old rule in outsourcing: if your IT is a mess, outsourcing will make it only worse.” — Gregor Hohpe

Cloud is an organizational change

Kickstarting your cloud journey often begins with forming a Cloud Center of Excellence (CCoE). This is a small, cross-functional team responsible for setting standards for how the organization adopts, secures, operates, and scales its cloud environment. The CCoE serves as an internal cloud enablement team, helping to translate the company’s overall strategy into practical patterns, guardrails, and operating practices. It should include people from different teams and areas.

These central cloud teams have some characteristics:

• They are small: less than ten people.
• They consist of high-performing individuals who are comfortable with modern cloud technology.
• They operate with autonomy and are self-motivated.
• They have executive sponsorship to remove obstacles and set direction.

The downside of a CCoE is that, like many central teams, it does not scale well. As the company and its cloud infrastructure grow, the team risks becoming a bottleneck. Additionally, over-reliance on a central team for cloud knowledge can hinder the distribution of these skills across the organization.

The goal is for everyone to speak 'cloud' using a shared vocabulary, which won't happen spontaneously. To achieve this, teams should foster collaborative practices such as cloud expert rotations, code reviews, and pair programming.

Organizational changes, such as those related to HR and role structure, take longer than technological ones. Advancing one without the other leads to imbalances, and ultimately, any technological complexity built without a cultural foundation will collapse.

Hohpe suggests having at least the following three roles: Executive Sponsor, Chief Architect, and Program Manager.

Executive Sponsor: responsible for securing approvals, engaging stakeholders and the board of directors, protecting the budget, and ensuring that resources are allocated according to the strategy.

Chief Architect: the ultimate source of knowledge about the existing infrastructure and architecture, the arbiter of technical decisions, and the owner of architecture standards.

Program Manager: responsible for tracking the migration schedule, coordinating execution across teams, managing the flow of information, and escalating important decisions to the other roles.

Conclusion

Cloud strategy is a leadership discipline before it is a technology discipline. The most important decisions are not only which provider to choose, which services to adopt, or which workloads to migrate first. The deeper questions are organizational: what business outcomes matter most, which trade-offs are acceptable, who owns decisions, how teams will be trained, how cost and security will be governed, and how the organization will measure whether cloud adoption is actually creating value.

A weak cloud strategy tries to maximize everything at once: lower cost, higher speed, better security, full portability, more innovation, and no disruption. A stronger strategy accepts that choices are necessary. It defines priorities, exclusions, sequencing, and trade-offs. It builds the foundation before scaling migration. It replaces manual control with automated guardrails. It gives teams autonomy only when they have the skills, tools, and accountability to use it responsibly.

The organizational lesson is equally important. Cloud adoption cannot succeed if it is treated as a side project owned only by infrastructure teams. It requires visible executive sponsorship, product-oriented ownership, platform enablement, security by design, FinOps discipline, and structured training for leaders, finance, operations, security, architects, and developers. A Cloud Center of Excellence can help start the journey, but the long-term goal is to spread cloud competence across the organization rather than concentrate it in a small central team.

Ultimately, the cloud does not reward companies simply for moving workloads. It rewards companies that learn how to operate differently. The real transformation is not from one data center to another; it is from slow, manual, siloed, asset-oriented IT to an operating model based on automation, service consumption, shared responsibility, continuous learning, and measurable business value.