Commitment, Silos, and Governance with Myles Ogilvie
- Sydney Lego
- Aug 8, 2024
- 7 min read
November 17th, 2021
Q: Just in the context of getting started, you know, where would you sort of approach given that most organisations of a certain size are very siloed in terms of their second and third-level defense?
A: So a few thoughts - usually needs to be a why and that can be triggered by an audit point or some other sort of issue that's arisen. An audit-driven development is a thing that I find can be quite useful when we are establishing this lean control approach.
In the Barclays context, we were harvesting audit points. So I had seven different audit points at one stage running all with the same mitigation actions, which was to adopt elements of this approach. And, that starts to create the right sort of level, of, of energy around this, so you need, there needs to be a clear why, why is this happening, how to get started?
Well, as with any way of working change, we would start small and we'd start with early adopters. And so when I work with information security folk, there is a population amongst, amongst that population, there will be interested folk, they're innovators, they're keen, they understand, new ways of working.
And there will be folk who are a lot more traditional and are a lot more reticent and nervous about it. So you've got a spectrum and that's true in all the different functions. So you're trying to surface. the more innovative folk. You're trying to start small, so you might start with one product area.
So for example, many organisations who have cloud platform teams are building out some sort of landing zone on the public cloud for their IT stuff that generates all kinds of governance, risk, and compliance issues because it's a new technology and none of the old standards work and everyone's scratching their head.
And the second line, I just like causing so much grief because they don't have the technical awareness of the real risks involved. And so starting with a cloud platform team can be helpful pairing them with safety folk, who are just special, you know, just going to get started there. That's one area in which I've seen this work very well. So you can get started small with just one safety team, one product team, and another organisation I'm working with at the moment. We haven't taken the cloud platform, we've simply worked with, a team that is, that is enthusiastic. They're already trying to change the way that they interact with their governance, risk, and compliance colleagues.
There's a lot of safety departments here and you, my lesson from previously is don't start with all of them, so start with a few and it can help to start with the most technical, savvy ones. So the three that I would choose to start with in my first mini safety team with the first product team would typically be information security, IT operations.
If you have a separate operations function that does kind of ITIL governance and service transition stuff, start with them and then enterprise architecture, because the architecture board can often be a complete pain to, you know, to navigate. So, you know, architecture, Ops, and security. They're a good sort of group to start with.
But again, it depends on the organisation I'm working with at the moment, the architecture board has already been resolved. Okay, so they're not the bottleneck anymore. So actually architecture isn't necessarily the one that you need in the team. So it will vary. But you're going to start with just a handful of, you know, three people maybe to start with.
Q: The journey that you went through with Barclays, so you started small, how long did it take to get and like you were saying, this is this at the final stage. This was running across thousands of teams. What was that?
A: So, I mean, in principle, this is quick to pilot. this approach. So when you can stand up a pilot very quickly in a few weeks and base it off some sort of confluence platform and you're providing some sort of manual visibility of the things that I've been talking about, and so within a sort of three month period, you can get a good sense of what this process is like to live with.
Okay. So you can do it for one product team in a small way, but when you start to try to scale this up Inia large organisation, what we find is you have to do several things. You have to have a level of automation because you've got a lot of backlogs. You've got millions of releases potentially that are going out, and you know, you're always going to be limited in the capacity of your governance and risk team.
So a level of dashboarding, a level of data visibility is needed, an automation of that, and so that takes a bit of time to build. So we found we were quick off the blocks on the pilot. It took us around six months to think through the model. We wanted to stand up, to get some feedback, to iterate it a bit.
And then we went into, Oh man, to go big on this, we have to, we have to build out some automation. And we knew we didn't want to replace any of the tools that teams were working with. We didn't want to add in any more than we had to. So we're looking to layer something skinny over the top of some of the existing tools.
But the challenge you have is the IT operations folk that govern the right-hand side of this process, use something like ServiceNow. The IT dev folk that operate in the middle of this process use something like Azure DevOps or, or Jira. And then the business folk that prioritise business outcomes and think about the slices of value needed to operate something completely different, some sort of project system somewhere.
And those three data domains in many organisations are not connected at all. There is no traceability. So if you're looking for a change request that's going out and there may be no visibility of what's in it and, yet from a project point of view, you've got a focus saying, yes, we are 99. 5 percent green on our enterprise risk project dashboard. But, if you look through the other end of the telescope, And I, you know, true story, we've seen, 99 percent of the releases going out don't have any connectivity to the project dashboard. So you do not know what's, or where your risk is being managed.
So try to create your lightweight lens across all three domains that allow connection where the work is for us. So, that's, some tooling enablements needed, but it's culture first, it's, it's, it's an organisation, it's a minimum viable process. And then there's some tooling enablement. So our overall journey took about two years to get to the stage of 15,000 or so working on this. But, the pause in the middle was to, was to get the tooling rights. And then we were able to rapidly move ahead. And the interesting thing about that journey, for us was, you know, as a leader of ways of working, when you're trying to help the organisation, enable modern practices, you're always looking for those sorts of ninja moves.
How do we turn this into something that people want to do? How do we make this something people want to adopt and by trying to move some of the biggest pain points out of their lives, you suddenly create a level of goodwill and energy and interest? In the whole topic. So as soon as the language of the product owner, the language of outcomes, the language of backlogs, as soon as that was being built into the policy and standards, the SDLC policy is as it was then, the software lifecycle policy, as soon as that's been built into the standards of the organisation in a regulated, environment, that can be a very powerful, tailwinds to, to help all kinds of other good things happen.
Q: But what happens actually, where the risk and governance and compliance- we live with Excel sheets and PowerPoint to convert docents, and that's not going to be a great developer experience or a product team experience like when it comes to.
A: Okay, so that's an important step, as you say, because where the change folk are operating is in their mind. Is in their backlog and those stories, those risk stories, we call them risk stories, not control stories, because they should articulate the risk given the risk we're trying to govern here.
Well, what is it when you talk to developers about the risks? No, I'm always finding there's a willingness, an interest, and a passion to do the right thing. And what people don't like is when they're being asked to do things that they can see as the wrong thing to do, and they're not being given any context or rationale, or help in understanding why that might be useful. And, often it's because the controls that have been defined by others have not been optimised for the particular risks, which are, which are at play. And, so risk control innovation is a thing here.
You're looking for a process that allows some flexibility around what are the controls we need to bring in because when you're thinking about blockchain, when you're thinking about cloud, when you're thinking about other emerging technologies, you can't just be applying the same old thing you've done in the past. So looking for the sort of you're always wanting to create space for you. So the risk story is saying, given the risk, we need to see some acceptance criteria, but how you do it is down to you guys, that's the model you're aiming for. And you're right. BMK, there isn't a golden bullet.
Q: Does the model assume that all workers have equal commitments to safety?
A: So the model doesn't assert that everyone is equally committed. No, I think what we'd say is that you are more likely to build that level of commitment if you have a good quality pairing, so, if the product team understands the names of the people, they are asked to partner with in the safety team if they have, if there is a connection there is more likely to, that's more likely to lead to shared commitment. If there's a connection, if there are shared objectives, if the safety team are, are incentivized, not just around, no risk, but they're incentivized around making sure our strategy is successful, making sure our growth initiatives happen.
That's the ambition, so the shared, equal commitment to safety comes from an equal commitment to value as well. And that can only happen through some alignment of objectives, goals, and purpose. And that's why we're advocating starting to Pivot your GRC organisations, your safety organisations towards the same language, the same structure of value streams, that is already happening in your delivery space.
