My AWS Partner Blog Post I Still Often Point People To

People building a portfolio eventually run into the same question: which pieces still represent how you actually think. For me, one answer keeps coming back: a guest post I wrote for AWS that ran on the Partner Network blog, arguing that hybrid architecture only pays off once an organization fixes the culture around it, not just the infrastructure. It's the one I still send when someone wants to see the reasoning, not just the résumé line. It was written the old-fashioned way, with no drafting tool doing any of the lifting, which is probably part of why it still reads like one person's actual argument, start to finish.

The post ran as part of AWS's MSP Partner Spotlight series, the week after a piece from Jeff Aden at 2nd Watch on managed migrations. Datapipe was the featured partner for that week's installment (at the time an APN Premier Partner, MSP Partner, and holder of several AWS Competencies and AWS Service Delivery designations), and I wrote it as the practitioner voice on how we were actually helping customers run hybrid environments day to day.

What I Was Actually Arguing

The piece leans on a line from the Agile Manifesto, "individuals and interactions over processes and tools," and applies it to a moment when most of the industry was pitching the opposite: buy the automation platform, adopt the CI/CD tool, and the transformation follows. I was seeing something different at Datapipe, working with customers like BMJ, a 170-year-old medical publisher trying to move a legacy release process onto a sustainable, continuously integrated model. The infrastructure shift only worked once the org stopped treating dev and ops as separate departments closing separate tickets.

Around that time I'd also become a big admirer of The Phoenix Project, Gene Kim's novel about an IT organization coming apart until it adopts DevOps principles. It's fiction, but it dramatized exactly what I was seeing in real customer engagements: the fix was never the tooling, it was getting people to work differently together. That book shaped how I thought and wrote about DevOps adoption for years afterward.

IDC was predicting at the time that 80% of enterprise IT organizations would commit to hybrid architecture within the year. That call held up. Flexera's 2026 State of the Cloud Report puts hybrid cloud adoption at 73% of organizations today. Hybrid didn't turn out to be a waypoint on the way to "real" cloud; it became the destination.

Why It Reads Differently Now

Rereading it, one part surprised me: the "individuals over tools" argument feels more relevant now than it did in 2017. Back then, the tool being over-indexed on was configuration management and CI/CD platforms. Today it's AI. The pattern is the same: an organization buys the capability and assumes the transformation follows, without doing the harder work of changing how teams actually collaborate, hand off work, and own outcomes end to end.

That's why this piece still belongs in the portfolio. It isn't a relic of a pre-AI industry so much as a data point that the underlying lesson survives whatever the current forcing function is. Tools change the shape of the problem. They don't change the fact that the problem is organizational before it's technical.

What I'd Add Today

If I were writing this fresh, I'd extend the "individuals over tools" argument one more step: AI doesn't remove the need for that cultural work, it raises the price of skipping it. When a team can generate infrastructure code, tests, and documentation in minutes instead of days, the bottleneck stops being execution speed and becomes judgment: who reviews it, who owns the outcome, how fast feedback loops close. That's the same DevOps question from 2017, just with a faster clock attached to it.

Final thoughts

The specific recommendations in the original (Terraform modules, Auto Scaling tuning, Direct Connect for low-latency hybrid links) are still solid, practical guidance for anyone building hybrid architecture today. But the piece endures for the same reason most good strategy writing does: it was never really about the technology in front of it.