Google Professional Cloud Architect Study Guide

Chapter 15. The Human Side: Working with Stakeholders, Driving Change, and Making Decisions That Stick

I’ll never forget walking into that conference room in Denver. The CTO had hired me three weeks earlier with a simple mandate: “Save our cloud migration.” Their engineering team had spent six months building what was, technically speaking, a beautiful architecture. Microservices deployed on GKE, proper service mesh configuration, elegant CI/CD pipelines, infrastructure as code with Terraform—everything a cloud architect dreams about. The technical design was so good I wanted to frame it.

The meeting was supposed to be a final architecture review before moving to production. Instead, I watched it turn into a slow-motion train wreck.

The architect—let’s call him David—opened with his architecture diagram. Seventeen interconnected boxes, five different GCP services, beautiful color coding. He was clearly proud of it, and honestly, he should have been. It was good work.

Within 15 minutes, at least a third of the room was actively arguing for abandoning the cloud migration entirely. “Let’s just stay on-premises where everything works and where we can control everything,” became the rallying cry. The CTO, who’d championed this migration and staked his reputation on it, looked like he wanted to melt into his chair.

David’s beautiful architecture—six months of work, technically flawless—was dying. Not because the technology was wrong, but because he’d built it in isolation. He’d designed ...