Becoming a HOW Organization: What you do is more impactful than what you know

Years ago, at an internal Microsoft Architect Summit, my good friend and colleague, Miha presented a concept that changed our world with his presentation, “If there was a school of IT ARCHITECTURE what would I learn there?“:

This was so insightful! It added perspective. I heard some had it tattooed on their ankles!

Years later (while washing my ankles) I had an Epiphany. This enlightenment is more than an observation. In fact, as said, it almost is a form of division or separation — which is unfortunate because what it really is, is a Roadmap!

Architecture teams that focus on the HOW that Engineering Teams are asking for will see a new relationship emerge. HOW comes from architectural resources already armed with necessary tools from reference architectures & implementations to harvested patterns to having greater visibility across the organization in what other Eng Teams are doing.

It is not limited to Architecture organizations, either. We’ll see it is equally impactful, if not more so when applied to Security organizations. The key to success is in interaction and delivery.

Imagine a World where Teams Interact at the HOW Level

When an Eng Team approaches Architecture & Security with a request for which there is no pre-existing pattern or reference implementation, it is far too easy to completely shut them down. Hard. “You’ll need a special request from your VP signed in blood that details why this approach is necessary against existing practices.”

We must end this!

There is a genuine transformation when you remove the word, “NO”, from an organization’s vocabulary and replace it with, “HOW”.

The new response is, “since we don’t yet have an aligned pattern or reference implementation, let’s absolutely work together to determine how we can do this in a secure, performant, and resilient way.”

Only the CIO (Chief Information Officer), CISO (Chief Information Security Officer), and Chief Architect should have permission to use, “NO”, and only when it is necessary for the safety/integrity of the organization. Every resource from VP to Analyst to Architect becomes a “HOW” resource in this new way of working.

The Road to HOW

While Security orgs generally grow slowly, Architecture orgs are more sinusoidal growing and shrinking according to perceived value and demand. There’s always this pull to continually “show your value” for which artificial metrics are created showing soft value for efforts around harvesting patterns and creating reference architectures. When real demand hits, neither org can adequately scale.

This is where Miha’s roadmap comes into play. While it is important that Architect & Security orgs continuously ask, “WHY”, it is essential that they focus on delivering “HOW ” to their Engineering partners. When doing so appropriately, they never again need to “show their value” as their value is continuously part of the delivery ecosystem.

It’s more than a Statement or Declaration

• It’s not enough to tell your architect & security resources they “need to code” …
  • You need to foster a culture of architect & security resources who genuinely feel rewarded when they produce reference implementations and harbor a desire to share this knowledge with others.
  • Bi-weekly “Curiosity, Sharing, and Learning” 60–90-minute sessions with Engineering are best received when Eng Teams are called out to share their learnings & accomplishments for 75-80% of the session allowing Architecture/Security to introduce a new concept (e.g., Zero Trust) by demonstration.
  • These demonstrations are used to solicit Eng Partners who will ask to partake in using the concept introduced into their product portfolio.
• It’s not enough to introduce and show new concepts…
  • You need to embed your architect & security resources into the Eng Dev Teams (for several weeks) to further refine and harden implementations for production-ready deployments.
  • The Eng Team needs to lead a share-back session at a future Curiosity, Sharing, and Learning session showing their adoption, struggles, and refinements to make the concept peer consumable.
  • This Eng Team will become future expert pairing partners by embedding themselves into other Eng Teams looking to adopt to scale the new concept.
• It’s not enough to land new concepts…
  • You need to continually refine and advance them into better offerings.
  • One architect on my team implemented a Cognito/Fargate zero-trust library quickly adopted by a progressive Eng Team. He later implemented a Lambda version that used internal identity management, was twice as fast, and scaled across multiple regions. The latter, however, was more complex to implement.
  • After working with the original Eng Team to replace their zero-trust implementation with the new approach, we all agreed on a journey-adoption-approach: experienced teams would adopt the Lambda version directly and new teams would first learn by implementing the Cognito/Fargate approach to later replace it with the Lambda approach.
  • When to Use Which is equally as important as new concepts.

It should happen Top–Down but it won’t!

• Given the concept of Becoming a HOW Org, the pushback at the senior executive level to make such a transformation happen will be quite large. It is far better to deliver results first and then ask forgiveness.
• Create a consortium of leaders to drive the concept inside-out both up and down the organization.
  • In one large organization, we did this at the Sr. Director level. The Heads of Cloud, Security, Engineering, and Architecture met weekly to plan while keeping their respective VPs at bay.
  • Team members who believed in the concept surfaced with a willingness to make it work.
  • Cross domain teaming commenced, and the first initiatives began their collaborative journeys to production.
• Ideas from team individuals are prioritized over roles.
  • Ideation comes from any team member and those with domain role expertise review and refine from their backgrounds and connections.
  • Experiments with wins and failures are equally celebrated as new insights and learnings shape the outcomes desired.
  • Execution in these new approaches and new ways of working will permanently transform these cross-functional teams.
• Once delivery begins, leverage telemetry and analytics to shape your story to show the value attained.
  • We saw this new way of interacting produced solutions with a profound robustness.
  • New active/real-time telemetry produced actionable data back to the team that allowed anomalies to be found and corrected before they were detected externally.
  • As results started accumulating, external benefits surfaced noticeably.
  • VPs started asking, why?
• Align feedback to VP directives & OKRs.
  • Ask for forgiveness by focusing your plan to implement your VP-led goals.
  • Identify your collaborative alliances as being necessary to ensure transformational success.
  • Ask for and accept their guidance and refinements to lock in their ownership for this new way of working.
  • Establish VP commitment to transform into a “HOW” Org.

HOW Comes with a Cost/Downside

Once your initial pilot initiatives land and prove that HOW Orgs genuinely work, prepare to be met with overwhelming resistance from your mass of resources. Empathetically understand they have worked hard and devoted their careers to reaching their current role/status. Trying to convince them a servant leadership approach to move forward is necessary will instead feel more like a step backwards.

I’ve seen up to 50% loss of resources when this shift in execution takes place. This requires you to be prepared to bring in new resources from both internal and external sources. This is a good thing because incoming resources will have self-selected they desire to work this way.

Build from this Opportunity

You’ll need to have a thermometer to know resources who “say” they want to shift over and those who actually will shift over. I found a litmus test to help find which camp resources originate:

• When a shift in platforms, technologies, and/or processes accompany the need for change, I would first, as a leader, attain foundational certification in that shift and then encourage all my team to also attain that foundational certification. The rational for this is to have consistent understanding and a common vocabulary.
• About 10% up to 15% of your resources will be early-adopters and attain desired certification(s). Perfect. This becomes your core team.
• Start moving your core team’s responsibilities into this new HOW way of working and you’ll get other team members questioning why they are not included. It’s simple. Get certified (i.e., commit) and then you get to play.
• There will be those who have no intention of moving in this direction, and that is OK. You’ll always have legacy support work they can focus on.

HOW is Especially Easy When Leveraging These:

• Ensure Transformation w/Expert Pairing – shows how your new relationship with Engineering can scale the HOW movement and your resources will become more recognized as Experts.
• Leap of Faith: Building Trust and Commitment with Engineering – shows how to further empower Engineering Teams with autonomy that leadership can stand behind.
• Micro-Experiments and Experiment Driven Development – supplies an approach to facilitate how to decide which new concepts apply to desired outcomes.
• Replaceable is the New Reusable – focuses on writing code that can be easily swapped out as skills in new concepts mature.

When is it time to convert into a “HOW” Org? You tell me!

Arrange a Conversation