By James Wilt, Distinguished Architect

Albert Einstein is attributed to the saying, “Insanity is doing the same thing over and over again and expecting different results.” Being part of many transformations over the years, it never ceases to amaze me how many anti-pattern approaches are regularly repeated over and over again!

• Have you attempted to migrate all your Data Center applications to the Cloud to gain agility and lower operational costs only to find a small number of workloads succeeded and costs rose?
• Have you adapted Agile practices to greatly reduced your time to production only to realize an Agile-fall practice is the best you could muster attaining few of the hoped-for benefits?
• Have you educated and certified all your architects & engineers (e.g., in TOGAF, ITIL, etc.) only to flounder in execution when they attempt to apply them in your politically influenced environment?

I have! Let’s simply say, while these attempts are sometimes successful (14% according to this McKinsey report), they more often fail to deliver on their promises. None of these, and many other transformation approaches, are necessarily wrong. What is wrong, however, is that, traditionally, they all are missing an important piece that can and will enhance if not outright ensure success.

Don’t get me wrong, there still are elements in traditional approaches that simply will not deliver (what was that in the back – lift & shift?) and while those should be avoided, introducing “expert pairing” may have a profound impact on your overall success.

Let’s first explore why traditional transformation approaches, alone, deliver less than optimal results (i.e., 14%):

Frameworks, Platforms, & Automated Factories	Outsourced Transformations	Single Platform Vendor & Partner Led	Educate & Certify Resources
·       One size doesn’t fit all [workloads] ·       Workload and integration dependencies derail progress ·       Legacy apps rarely conform to minimum requirements for automated migration ·       Hard-coded connections never transform gracefully and they often represent the majority ·       Data migrations are costly and simply can’t “clean things up” ·       Security is significantly different and too often is misconfigured	·       External resources often lack customer-specific business domain expertise and experience ·       They don’t know where the skeletons are hidden and get easily bitten ·       Your expectations exceed their ability to deliver (if your own resources can’t meet your expectations, how will strangers meet them?) ·       It is a PM nightmare because required data to execute too often exists only in employes’ heads	·       Lock-in – yup – Vendor. Lock. In. ·       Their preferred tools often clash with your standard tools and trade-offs & compromises prevail ·       Criteria for heavy discounts are rarely met (perhaps, that’s why they exist?) ·       Integrations to systems outside their ecosystem are often abysmal, non-performant, and cobbled together ·       Upgrades will be necessary and add additional cost ·       Legacy implementations will break	·       While a number of teams will quickly adopt & adapt, an equal number will reject & resist (it’s follows a normal distribution) requiring a culture adoption strategy ·       What works in the classroom / lab rarely works in actual dev / test / pre-prod environments ·       Knowledge does not equate to successful execution ·       Happy-path training experiences fail to address and prepare for inevitable real-world failures

 

Again, none of these are necessarily evil. They offer elements toward success (e.g., platforms promote consistency and education/certs promote a common vocabulary). They weaken because they promise to deliver things to/for your organization from the outside when, instead, it’s actually your resources who have intimate inside knowledge & understanding and must carry the torch of sustainable delivery post transformation.

Successful Transformations, in my experience, seem to share the following attributes:

1. Clear vision & strategy from leadership who are fully transparent & on-board for the duration.
2. A culture of empowered resources encouraged to innovate.
3. Start small & scale up (Gall’s Law) with a roadmap that is highly scope contained.
4. Encouragement/guidance to fail fast and celebrate learnings.

Expert pairing focuses on 2 & 4 above while executing to 3.

So, What is Expert Pairing?

Essentially, expert pairing is when you “pair” expert resources to your own resources who are likely to be overwhelmed learning all the new factors related to the desired transformation. This is most prevalent when the transformation involves a paradigm shift that works contrary to what is currently considered standard or normal procedure. These include new frameworks, platforms, processes, technologies, tools, etc.

Think of it akin to paired-programming except your resource retains control of the keyboard and the expert serves as a coach-partner. Experts can come from in-house teams (if not initially, they will eventually) and from consulting partners.

Experts sit one-on-one with your resources to work through the gnarly hurdles transformations impose. These include things like when:

• Cloud implementations are 180° different from on-premises
• Security becomes the responsibility of everyone, especially development engineers, opposite from the bubble of security Infrastructure provides
• Network, infrastructure, and security are now code
• Microservices too easily blend back into monolithic Swiss army knife services
• New platforms & paradigms turn out to be way more complex and require purposeful complex configuration to achieve performance & resiliency goals
• There are now too many ways to implement a feature and you must choose when to use which approach and understand why

The Differentiating Factor

Up to this point, most organizations might claim, “we already do this to some level.” The key difference is that “experts” are evaluated and rewarded solely based on their paired-resources’ performance/delivery, not theirs.

You got that, right?

It’s all based on paired-resource outcomes. Outside the box (er, crazy)? Absolutely, but highly effective.

This means external experts are paid when your resources deliver. Not every partner/contracting organization will sign off on this concept, however, those that do will equally reap the benefit of an even stronger relationship.

And the Benefit?

This approach has evolved over about 7 years and the following outcomes have been observed:

1. One-on-one expert pairing allows resources learning to persist because they can vent transformation frustrations to someone who totally understands. Their expert, too, went through that same disruptive phase.
2. Your resources will deliver, and, with renewed confidence.
3. Through necessary pain comes empowered gain. Once they transform, these resources are very eager to apply their newly acquired skills in a more innovative nature.
4. A bonus outcome is that when the expert is internal, they often come away having learned much about another domain.
5. Another bonus outcome is that it scales with vigor. As resources transform from student to expert, they are eager to assist others as their experts.

Experts: Internal or External?

When pairing, you’ll need experts. It’s important to choose your experts wisely. Here are some thoughts when choosing experts:

Use Internal Experts

Use External Experts

·       When you have them and they are available, always! ·       When the nature of the transformation embodies proprietary information that should not be shared externally (e.g., skunk-works initiatives, innovative exploration, etc.) ·       When the transformation will have a cascading effect on other internal systems at a large scale.

·       When the transformation involves factors outside internal experience. ·       With new, emerging technologies. Vendor & vendor partners will often be more receptive to providing experts when rolling out their new technologies. ·       When a transformation requires a shift in the environment configuration and/or your operating model and these changes will likely ruffle feathers – it is often better received by external partner experts than those internal.

Your architecture team [that codes] who manage your patterns & practices can become one of the best Internal Expert resource pools as they often work closely in emerging spaces with external influencers. As new patterns emerge, they can piece together initial implementations and libraries and embed themselves one-on-one into product teams (see Micro-Experiments and Experiment Driven Development). Together, they can further refine the initial seed-work into a more robust offering that is inner-sourced to others.

Experts from your willing external partner can actually over-perform as they have your paired-resource to fill-in the gaps of domain, environment, and political influences they would otherwise need to discover on their own. They can then excel at explaining and expanding your resource’s skills.

It’s Another Leap-of-Faith

A few years ago, while building out this concept, I met with Satish Reddy of Sonata Software in Bellevue, WA who saw its potential and became a willing partner to pioneer with two of his experts. A key attribute when pioneering is to ask for forgiveness, not permission.

Satish and I both were quite pleased with our initial results as they far exceeded initial expectations, and they opened new doors of thinking how partners can genuinely act in a partnering relationship to the betterment of resource expertise at clients which is a less common ask and delivery.

Takeaways from our pioneering:

• Start with an initial small team, product, and commitment to establish confidence in the process.
• Listen to your paired-resources once your pilot completes.
• Adjust to your own organizational & cultural dynamics.

Last Thought

If this all sounds crazy (er, outside the box) then maybe a little crazy is what you need to raise that 14% measured success rate to something your organization won’t see any more than just another nice try!