The Cluster Was the Easy Part

When I took on the Technology Architecture Manager role at Accenture Interactive in Sao Paulo in 2020, the brief looked like an infrastructure problem: enterprise clients wanted GKE clusters, and they wanted CI/CD automation with Jenkins and Spinnaker feeding into them so releases stopped being a manual, ticket-driven ordeal. That part I could scope in a planning meeting: cluster topology, namespace boundaries, pipeline stages, rollback strategy, all known shapes. What the brief did not say out loud, because nobody had framed it as a deliverable yet, was that none of it would matter if the delivery teams inheriting these clusters didn't trust them enough to use them the way they were designed to be used. A GKE cluster nobody trusts becomes a very expensive place to run three services and route everything else around.

The harder project sat next to the infrastructure one: getting 120-plus Accenture Interactive professionals through Google Cloud certifications. On paper this reads as a training line item. In practice it was the actual adoption mechanism, and it was a much messier problem than the platform build. The clusters had one right answer per decision; the people did not start from one place. Some had run production systems on VMs for a decade and treated containers as a mild inconvenience layered on top of deployment habits they weren't going to abandon on faith. Others were early-career and had never operated anything, so Kubernetes wasn't replacing a mental model, it was their first one. A single curriculum pitched at the median would have bored the first group into disengagement and lost the second group in week one. I couldn't design one on-ramp; I had to design a program that let people enter at different points and still converge on the same certification bar.

The pre-sales angle made this harder before it made it better. I was running technical pre-sales conversations with clients at the same time I was trying to get the enablement team fluent enough to deliver what those conversations promised. That ordering is backwards from how you'd design it on a whiteboard, and there was no clean way to sequence it differently, since the whole point of the engagement was to win the work by demonstrating the capability existed. So the training program had to produce credible competence under a deadline that came from sales cycles, not from a learning schedule. That's a different constraint than training people well. It's training people well enough, fast enough, that the client believes the delivery risk is gone. Certification became the proof point precisely because it was external and verifiable: nobody has to take my word for a team's Kubernetes readiness if 120 of them are Google Cloud certified.

What actually worked was pairing the certification track with real cluster work rather than running it as a parallel classroom exercise. People who were skeptical of a new deployment model didn't get convinced by slides explaining why Kubernetes was better than what they knew; they got convinced by being handed a real GKE namespace, a real Spinnaker pipeline, and a low-stakes service to push through it before anything client-facing depended on the outcome. The certification study gave people the vocabulary and the exam gave them a checkpoint, but the trust came from doing the thing themselves and watching a rollback actually roll back. If I were redesigning the program today, I'd push that pairing earlier and harder: less time establishing concepts in the abstract before touching a cluster, more supervised production-adjacent reps from day one, with certification study running alongside rather than ahead of it.

The lesson I carried forward from that year is that a platform migration and a training program are the same project wearing different clothes, and treating them as sequential (build the platform, then train people on it) is how you end up with a working cluster and a delivery team that still routes around it out of habit. The certifications mattered less as credentials and more as a forcing function that made the learning path concrete and gave 120 people a shared, verifiable finish line at different starting speeds. The technical build was necessary. It was also the part I'd already done before. The enablement design was the part that determined whether any of it survived contact with a production deadline.