Leap of Faith: Building Trust and Commitment with Engineering

April 5, 2023 Holt Hackney Applications & Technology, Data, Digital Transformation, Elevating Architecture, Software, Strategy & Planning, Uncategorized 0

By James Wilt, Distinguished Architect

In 2016, Forbes assessed the risk of failure in digital transformation to be 84%. Today, Harvard Business Review indicates that the rate of digital transformations failing to meet their original objectives averages at 87.5%. Taking into account margins of error, we are essentially stagnant in our ability to improve. Five years ago we identified Talent & Tools were lacking but that is not the case today. Leadership reluctance is the new bottleneck which is in dire need of being addressed.

The divide between Engineering Agility and Organizational Acceptance has never been as great as it is today. A leap-of-faith is only possible when actionable trust boundaries and mutual commitment exists.

Before we embark on bridging the Leadership/Engineering trust-gap, we need to understand what it is and why it exists.

From their own experience and journeys, Executive Leadership came to rely on end-to-end views of systems where almost every major decision is made & documented and full design is complete & signed off prior to the first line of code being written. Teams were managed and progress visualized by orchestrated waterfall processes & tools. This control instilled confidence and high trust in their development teams. Any disruption to this ecosystem required rigorous Change Management to adjust features, timeline, and cost impact. “I knew exactly what my Engineers were going to do and when to expect it,” one SVP shared. The measure five times and cut accurately once mantra ruled.

Life was so good.

Today in the modern land of loosely coupled, stateless, REST API based microservices running in cloud-native serverless environments, progressive Engineers clone starter code from a shared GitHub repository to accelerate/boot-strap their solution to vet initial considerations using a highly iterative experiment & decide hands-on approach. Change required? Not a problem. Versioning is leveraged to simply swap in the new without immediately abandoning the old for AB/Blue-Green deployments. “I can get it wrong five times and right the sixth — all in half the time it used to take,” one Member, Technical Staff commented. The cut as many times as you like mantra has emerged.

Life is so good.

From where we started to what is available and possible today, one might think organizations are operating at impressive levels of agility and deliverability!

Nope.

Why?!

Executive Leadership simply does not Trust their Engineering Teams. The reason is because this new way of hands-on iterative development makes it impossible to see the end-to-end view up front, understand how it will be built beforehand, and lock-in the design before any code is written. Change Management is turned upside-down and you may not know exactly everything you’re getting until the last microservice is deployed. When they ask their Engineers how they will solve a problem, they get multiple yet-to-be-vetted approaches with no commitment until they try a few.

For Executive Leadership, this induces uncertainty and diminishes confidence – even when these new methods provide strong metrics & evidence they actually work.

This is the Chasm

Engineers seek to operate in a modern way that delivers robust quality with great speed that is counter to the way Executives can synthesize what they do. “Start Small & Iterate” is counter to the traditional perception of how “Objectives & Outcomes” are delivered in a safe, timely, and cost appropriate manner.

Necessary motivation to accept and commit to change is where bridging begins. While this will be unique to each and every organization, starting at the top often works best.

Next is divorcing deep attachments to legacy systems and thinking. This is a great hurdle. Yes, those systems got you here, but today, they can be more of a risk than an asset. This was best recognized by Southwest CEO Bob Jordan when he admitted the carrier needed to upgrade its legacy systems after over 2000 flights were cancelled and the airline was grounded for four days.

Finally, creating an avenue where trust can be earned is paramount. It’s one thing to harbor distrust but it is entirely toxic to not articulate how trust can be earned. Note: using legacy systems and practices does not earn trust, it perpetuates risk.

1 – Own your Talent Supply Chain Strategy

A question to Executive Leadership: What is being done to build an Engineering Discipline that leadership trusts?

Crickets?

Consider leveraging a Talent Supply Chain Management Strategy to establish and articulate agreed upon trust-boundaries. This is a necessary commitment that will require years to realize value, so be patient.

  • Invest in education institution direction through active contribution toward their academic offerings:
    • Sponsor & host STEM/STEAM programs.
    • Contribute to academic curriculums in both content recommendations and volunteer teaching.
    • Raise the bar for internships.
  • Align with industry direction thinking – begin the journey with alignment through communication and messaging. Consider leveraging vendor-neutral industry certifications (e.g., The Open Group and Iasa Global in cloud, security, architecture, product-management, etc.) as a requirement for new-hires and encouraged for existing talent. Increase compensation/promote individuals who certify. This illuminates leadership’s commitment to modernize.
  • Promote outside-in ideation and risk-taking leveraging hack-a-thons and think-weeks focused on emerging practices & technologies. This rallies excitement in the new and communicates leadership openness toward acting on these advancements,
  • Direct teams to make decisions by leveraging data and learnings from micro-experiments. This focuses on science/measurable experience over gut-feelings.
  • Consider role-rotations to broaden skills, widen perspectives, foster cross-discipline networking.

2 – Instill a Culture of Learning

Become purposeful with educating teams in the new. Training is increasingly augmented by vendors and many online training environments exist. You are probably already investing in these. Landing positive outcomes requires much more than classes alone. Consider the following:

  • Be specific in class & training selection so it provides necessary knowledge & direction toward your future.
  • Talent needs to immediately apply learnings to solidify synthesis, so ensure access to uninhibited sandbox environments (leverage time & cost bombs to govern sandboxes, not feature restrictions).
  • Promote vendor-specific certifications to raise expertise on targeted platform features. Celebrate when certifications are attained.
  • Invest in offsite workshops. Teams need to be removed from daily interruptions so focused attention to new paradigms can be applied,
  • Let teams fail gracefully. In almost every case, the first attempt to apply newly learned skills and practices will result in an output/product that stems to further teach than to actually be put into production. Encourage or even mandate refactoring once the new skill is more fully established.

3 – Measure and Reward Performance

A smart team that cannot deliver is no better than a dumb team that regularly delivers junk.

Establish deliverability metrics that become mandatory across all deployments. Automate these metrics as much as possible leveraging your Agile Project Planning Tools (e.g., Jira, Azure DevOps, etc.). Consider the following examples:

  • Number of Sprints to production (less = better).
  • Number of Bugs reported (less = better).
  • Type of deployment (team automated = best; ops-automated = good; ops-manual = bad).
  • Number of Dependencies (less = better).

Further establish Quality & Security metrics that promote modern software, network, and security practices:

  • Evaluate the number of test/pre-prod passes vs. prod issues/failures.
  • How often used and effective are Application Security Testing (AST) tools?
  • How deep is Zero Trust leveraged?
  • What is the design’s Well Architected Review score?

The goal is to provide clear, delineated measures teams can leverage to demonstrate their overall maturity in the desired future state of trustworthiness. The more mature, the greater their autonomy.

How to Prepare and Know to Leap

Leaping before you’re ready will result in disappointment if not outright disaster. It is important to understand what knowledge and muscle is required along the various stages that lead to full Engineering Trust & Autonomy.

Each organization must determine this trust criteria for themselves, however, it is imperative to recognize starting from the future end-state goal and working backwards promotes the greatest benefit (e.g., innovative inspirational differentiation).Gauging

To be most effective, seek out Leading teams already doing this in your organization. They do exist, but they most likely are considered one-offs, rogue, and exceptions to the internal norm. Good. That’s what you’re looking for!

Next, you need to be realistic about what the end-state truly is. Not every team will attain full Engineering Trust & Autonomy and that’s OK. In most situations, over time, it will follow a normal distribution:

TrustAttainment

While determining trust criteria is specific to each organization, industry, and domain, what’s fairly consistent, yet ever evolving, are the technologies, tools, training, and certifications. Leverage input from those in industry ahead of you to prevent your own legacy ways from having too much influence.

TrustCriteria

Time to Commit

Once trust criteria is shared and definitive trust-boundaries are in place, the hardest piece of this puzzle must be executed: Executive Leadership and Individual Commitment

Putting your strategy into play takes time and during that time doubts will creep in. This is normal, however, there are a few tricks to leverage that ensure you stay the course:

  • Before you share this plan with your organization, have a minimum of 2-3 teams identified, preselected, and in-play at each maturity level. This means Executive Leadership will need an initial leap-of-faith to empower teams at the Perfecting and Leading levels at the onset. They already exist, you just need to partner with them throughout this journey.
  • Openly celebrate teams when they transition up a maturity level.
  • The communication plan should clearly identify that this is active at the time of the announcement. This means that team classifications must already be in place. If all teams, except those already preplaced, begin at the Learning maturity, there will need to be an expedited process to right-set their actual maturity. This instills a type of justifiable panic that serves two purposes:
    • Emphasizes the seriousness and commitment in leadership.
    • Identifies teams with the greatest commitment to prove themselves.

Measure Results

As teams work their way up in maturity, meticulously measure how the advancements impact the overall organization:

  • How much has time-to-value been reduced?
  • Where and in what ways has quality improved?
  • In what ways have systems become more robust?
  • Are Engineers behaving differently?
  • Are Executive Leaders less burdened?
  • Do costs more appropriately reflect value delivered?
  • Do customers sense the change?

There is No Easy-Button

If this appears to be a whole lot of planning and effort, it is! It requires coordination, commitment, and funding across every part of the organization from HR to Ops/Infrastructure to Engineering to Architecture to the PMO. It can take up to a year to establish and two years to start seeing permanent results.

It is a serious commitment across all leadership, teams, and individuals – a real Leap of Faith!

So, dig in and get going because this level of change is not a one-time deal. Rather, it becomes a perpetual new way of working. The Leap will truly be transformational!

References