Have Smarter Compliance Interactions

Compliance, Regulations and Governance teams (GRC) have come to a place where to scale - what matters is everything around the output - not the procedure/guidance/assessment itself. We need to focus on psychological safety, and leadership in our organization for smarter interactions to achieve results.

When approaching a potential team that we want to interact with, I'm not sure that pitching from a slide deck of services and internal mechanics works anymore. When GRC teams meet potential partners with the wrong mindset (internal facing) the people we want to work with cannot see what they would benefit from working with us. We should rather communicate the towards the stakeholders' needs and wants (external facing). Sometimes GRC teams are the first to announce that a regulation is key for the solution to operate. Testers call this the "your baby is ugly challenge". Other times the GRC teams are, again like the testing and QA teams, added as an afterthought or paid lip service to.

Secondly, we need to reconsider how we interact during a delivery. GRC activities are often rightly viewed as a blocking function or a gatekeeper. While some gates indeed need to be kept - the way we interact among us matters more. This is actually what sets great companies apart from the mediocre. It's not stating that we are "great" but wiring the organizations for smarter interactions that make us great.

Wiring the Winning Organization - IT Revolution

Drawing on decades of meticulous research of high-performing organizations and cross-population surveys of tens of thousands of employees, award-winning authors Gene Kim and Dr. Steven J. Spear introduce a groundbreaking new theory of organizational management. Organizations win by using three mechanisms to slowify, simplify, and amplify, which systematically moves problem-solving from high-risk danger zones to low-risk winning zones.

IT RevolutionTo Author Archive

Core interactions

Over there is a team doing some work - and you need to interact with them. To me, there are generally three ways to interact:

• Directly collaborating with them and being part of the delivery
• Assisting them with a dedicated time to help them manage on their own
• Providing a product they can build from on their own

Notice how this is a scale of involvement. In the first, we are an integral part of the delivery, in the second we are temporary and in the last interchangeable. Which of the three interactions you want to play is key to your success.

I have seen speciality teams die out after their offerings are integrated into delivery teams. It makes sense that for instance test automation is an activity that is anchored in the the same organization as the developers and others. To support flow and not become a bottleneck.

If you opt to provide shelf-like services at a fixed cost - be prepared to race to the bottom. What was once a unique shiny product will often be a commodity over time. And there is some value in commodifying and automating things - as it should make room for exploring the next thing. While products and services might seem a safe bet for a fixed income, swimming in the red ocean has its dangers.

I prefer the middle option. Is it just me? I prefer to enable others and help them eventually to solve the problems on their own. I want to unblock interactions and design organisations for success that works. Not hear-say, blue moons or tea leaves but actual organisational structures that are known to accelerate organisations. Let's have good strategies - not bad strategies.

Good Strategy/Bad Strategy & Playing to Win

Compatibility and Utility

MediumRoger Martin

Designing a Cyber Security and GRC unit for flow

When we meet someone we want to interact with we should first of all listen. Then understand where they are at on their journey - their challenges and strategy. Listen to understand the situation, then the challenge and lastly suggestions and first steps of action. (Based on the SCDA framing by Will Larson, https://staffeng.com/guides/present-to-executives/ ). Then and only then we can start to frame our suggestion to the person(s).

• Do they need people who can do: secure coding, write procedures, execute and set guardrails? Then help them have people embedded in the delivery teams.
• Do they need people who can advise and grow: then focus on coaching secure development, advise on procedure templates, and set up recurring knowledge-sharing sessions.
• Do they need stand-alone offerings to work with on their own: describe clearly how to interface with your team and be prepared to get out of the way. Template: https://github.com/Sidekick-Security/team-api

While there is value in stating what we do, how we are organized to do it and how we do it - what helps us grow is to frame the problem-solving from the stakeholders' point of view and provide smarter interactions.