Chamber 🏰 of Tech Secrets #51: The "Ready, First" Pattern

How change happens in enterprises (sometimes)

The Chamber 🏰 of Tech Secrets is open.

The “Ready, First” Pattern

The “X-Ready, X-First” pattern is one I’ve observed to be successful a number of times over the course of my career as major landscape shifts have happened in the technology industry.

Allow me to share a few examples.

Mobile-Ready, Mobile-First

The first major disruption to occur in my career was the proliferation of mobile devices.

Remember when the iPhone had a button?!

Like many others, I observed our organization go through a Mobile Ready phase. We had a bunch of things to do like…

• Build APIs to serve data and functionality to apps

• Ensure we had mobile-friendly authentication and authorization paradigms

• Figure out how to deploy devices to public and private app stores

• Build teams with the appropriate development skills

• Learn to be successful with customer-facing mobile applications

During the “Mobile Ready” phase, we thought we might have a single “mobile team” that did all the things. As we moved towards mobile first, we realized we had to democratize the technology to maximize the opportunity.

A bit later, it was time to go mobile-first. While it is a bit hyperbolic (we still had good reason to build web apps), it did change the way we thought about what sort of experience to build for users of our applications. Mobile became a primary thought and often the default as consumer (and therefore enterprise) preference moved towards native mobile experiences.

Cloud-Ready, Cloud-First

Next was the cloud transformation journey, which started with a project that was literally named “Cloud Ready”. We had started our journey with cloud on two parallel paths: 1) What would come to be known as the CFA One mobile app and all its associated services and 2) our “Big Data and Analytics Platform”.

Remember these days? Source: AWS Blog

The cloud ready phase helped bolster these efforts while preparing the organization for larger scale. We had to account for things like:

• What cloud provider will we use at scale?

• What will our patterns be for all the things we had always done in a managed datacenter environment, including AuthN/Z, application deployments, databases, operational services, etc.?

• We had to get comfortable with security posture in he cloud.

• We had to solve all the typical stuff like logging, monitoring, tracing, billing, account management, account access with SSO, and a slew of other things.

• We embraced both cloud and a DevOps model at the same time, so we had a lot to learn there too.

• We rallied a lot of of EA, Cybersecurity, and other supporting teams around the cloud ready vision on a single new project, launched it, and then started to think about how to scale.

• We really built our software engineering muscle and culture at this time since custom-written software made a lot of sense in our cloud strategy (vs just hosting COTS).

As you might expect, we followed the next year with a project named? Yes! You nailed it! 🧠 “Cloud First”. At that point, we shifted to fully embracing cloud as the default approach and have never looked back. We moved from a small handful of teams to nearly one hundred (some have come and gone and count in my number) over the following years.

The “-first” phase was—once again—all about democratization and default-approach transformation.

AI-Ready, AI-First

Today, we stand on the cusp of embracing the next disruptive wave of change: AI. Once again, we’ll run the same play, starting with AI-Ready. We’ll need to solve a lot of challenges, which we are starting now:

• People: We’ll need to up-skill people and help them maximize the AI opportunity in their jobs.

• Process: We’ll need to understand and document our business processes so we know where AI can play and where we need humans in the loop for compliance or other reasons (perhaps in the future, AI can only spend $XXX before a human validates?).

• Data: We’ll need to have our data catalogued and ready for transformation and usage, whether that is for fine-tuning a model or injecting important, high-quality data into a context window or via RAG.

• Technology: We’ll need to figure out all the tech for delivering AI, all the architecture patterns, and all the developer tools. We’ll need to double down on our API implementations so we can empower models and agents with MCP-fronted tools. We’ll need specifications, standards, frameworks, registries, and more.

Thankfully, we have a great team of people across the organization to make these happen, and we have the benefit of learning from our past.

At some point, we’ll be ready to turn our eyes to “AI-First”, a term I am already seeing in blog posts and LinkedIn on a regular basis.

Ready or not, AI-First is coming.

Takeaways

So what can you take from this anecdotal experience and apply in your company?

1. Going straight to “first” is a bad idea. For major disruptions, it takes time to prepare, to build organizational support, to get funding and people, and to manage change. Embrace the “ready” phase and know that “first” is coming. Be patient. There is clear value in the readiness work (think of the AI examples above) and I think some degree of value in the anticipation of transformation that is ahead when we embrace “first”. In my career, the one time we jumped to a “-first” without a “-ready” was “API-First”, and it has not been the greatest success of my career. In hindsight, I think a patient readiness phase would have helped.

2. Use “X-first” in your internal vision casting, but not your external communications. “What might it look like if we were AI-First?” is a worthwhile question to ask to help shape the readiness journey. In my experience, we did not jump to the “-first” until teams were effectively clamoring for it and it was an obvious next step. This restraint creates anticipation, buyin, and support when the first model is embraced and requires organizational change, which is honestly the hardest part of any job.

3. Don’t overuse the “ready, first” pattern. It applies to major disruptors but not all changes. I would not recommend “SaaS-Ready, SaaS-First” or “Docker-Ready, Docker-First” or “Kubernetes-Ready, Kubernetes-First”. You get the idea. API-First might have been too small a change, which could be another reason for its’ lackluster transformational power.

4. Know the value of the transformation you’re engaging in. For mobile, it was about access to the business anywhere and everywhere. For cloud it was about empowering teams to manage their own infrastructure through APIs. For AI, the promise is radical productivity and work product increase. Following this guidance will help keep you on track on the previous three points, and ensure that you can set a bearing, take some steps, re-orient, and repeat.

I hope this pattern serves you well in your transformational endeavors. Agree or disagree, drop me a note and let me know what your experience has been. Thanks for reading! 🙏