Grand Social Engineering: DevSecOps And Influence - Seb Coles

Charlie. Um, hello everyone. Um, surely you can hear me. Okay, that sounds quite loud. Brilliant. Fantastic. What a big room. Look, you had different options today and you chose to spend some time with me. I'm really grateful. Thank you. Um, my name is Seb. So, I do um I'm a security guy. I work at SEL. So, SECL, we're a kind of platform uh investment infrastructure company. We're part of the Octopus Group. My role at SECL is uh all things security. So GRC, identity access management, dev sec ops, uh you you name it. But I also look after tech operations as well. So looking making sure our our colleagues are up and running and doing so safely as possible.

Uh my background though is engineering uh engineer by trade. And probably about 8 years ago now, I got the opportunity to do something which we would call a dev sec ops transformation now or really what's better known as a change program. Um I got the chance to work with eight engineering teams all using different technologies. Uh and I got to educate them about security. I got to introduce tools uh static scanners, software composition analysis. I've got to try and change their processes and really to try and look at the SDLC as a kind of system and how can I produce a system that makes a secure product in the first place and I I really really enjoyed it

but gosh it was hard. Um it was a very very different game and that's the game that I want to talk about today. Um, and it wasn't until a few years later when I was working at Clarks, I was very fortunate that I got to work with a man called Victor who was the VP of engineering at Clarks and he he sat me down one day and said, "Sb you've got a talent for change management." And I thought, "How can you have a talent for ITIL? That's not a very nice thing to say. That's a bit of a backhanded compliment." It's like, "No, Seb, that's not change management. Before I come along, it meant something

else. It meant organizational change management." the practice of uh identifying cultures and changing values and behaviors over time. And it it opened up a whole new field of study for me. Um and I got to learn how to do this kind of change program stuff properly. And that's what I want to talk about today. Um because as IT professionals, if someone says change management, you're probably also thinking it. Um so I want to introduce you to a different field of study and also some of the literature that's helped me be successful in the space. Um I've worked at Veraricode as a senior consultant. I worked at Clearbank. Um I built the security engineering function at

Clearbank from 1 to 9 and in two years I took them to the computing awards to win best devs sec ops implementation. I was head of devops at LRQA and now I do things at SEL. I'm I'm quite good at this and I want to show you all the I guess the rakes that I've stepped on so that you might not step on those rakes. Um, so the reason that I'm here is where DevSec Ops tends to start and end is you have that talented engineer uh who's learned a little bit about pentesting, learned a little bit about security. They start spending some time with their infosc team. Um, and what they wish for is that they could do security all the

time. They see the value in it. Bringing shifting security left, building a better quality product. That's what they want to do. But be careful what you wish for because they end up getting it. But then they turn into a very very different game because this is a game of influence and this is a game of advocacy. Now you're trying to uh make change without authority. You're trying to get time on people's backlogs. You're trying to introduce tools. But the thing is no one told them that the game had changed and no one told them what skills they need to develop to win at this game. And then they get frustrated. 6 months goes by, 12 months goes by and

the world looks still a little bit like it did at the start. They get frustrated, they burn out, they quit. and you hear phrases like I felt like I burnt my fingers and I've been that person and I've seen too many of these people. Um so the the rakes that I want to talk about today is the first one that I've stepped on is around how you actually plan for change. Some of the literature in this space we're going to talk about John Cotter Harvard professor uh leadership and change management. He has something called Cotter's eight steps for change and I want to show you how I've uh used that model for DevSec Ops. I want to talk a bit about

stakeholder management and what that actually means. Too often just a CV buzzword, but this is the number one skill that you need to develop in an advocacy role. U as a lead developer, my stakeholders were my product manager, my delivery manager, maybe my engineering manager. I could probably count my stakeholders on one finger. But when you're in one of these advocacy roles, suddenly every product manager is your stakeholder, every delivery manager. You could have tens and t and people out of commercial are suddenly your uh stakeholder because you're competing for backlog time. People in operations are now your stakeholders. Your stakeholder uh network is much much bigger. So I want to teach you how to manage

stakeholders. I then want to talk about the inevitable resistance. Now I'm preaching to the crowd here. You all know why security is important. But when you're going into engineering teams and you're trying to introduce education and tools and process, you will meet resistance because change is hard. It's not personal. It's not that they don't believe in what you're doing, but suddenly their day-to-day has changed. There's a bit more friction. Um, and I want to talk through some of the skills that I've develop u sort of helped me in my career to overcome that uh resistance. And lastly, I want to talk about how you change an organization. What does internal communications actually look like? Because gosh, it's a lot more than

firing out an email or being in a single all hands call to present. Internal communications is a far bigger field than this. And I want to teach you a little bit about it. At least introduce you to some of the literature of how to internally communicate properly. And then hopefully by the end of this, how dev secc ops should start and end. talented engineers, talented people wanting to be the flag bearer for security and having the skills to do it, understanding the game they're playing with coaching and mentoring and realizing most of the time I'm battling psychology more than I am battling hackers. Uh, and understanding that this game can actually take quite a long

time. And if at the end of this talk you think, gosh, I don't like the sound of that. Well, that's a good thing, too, okay? Cuz maybe this kind of role is just not for you. So the very first thing we're going to talk about is planning for change. So we're going to talk about Cotter's eight steps for change. I said Harvard professor leadership. Um you've got some of the uh the referencing at the bottom. This book here, what leaders really do. You can get that the hardback copy on Amazon for like £8. It's quite a short book and it's it's a fantastic book. Now, the first step of Cotter's eight steps for change is building a sense of

urgency. Or if you're a Simon Synynic fan, this is about your why. Like, why are we going on this dev sec ops transformation? You have to start here. There are many ways you can find that sense of urgency or too often it might be on the back of a breach. It might be regulatory compliance. It might be that your customers are just getting bigger and far more demanding with supply due diligence. you might be losing customers or or losing tendering processes due to your security. Um, many people start with maturity models. I like maturity models as well. In DevSec Ops, there's a whole lot of maturity models. Now, we've got BSIM from Synopsis and Black Duck.

We've got SAM, NIST, SDF, Salsa, DOM, all largely talking about the same thing. Um, but I really like BSIM uh because it's got great material. The literature is very good. I'd happily talk an executive through their literature, but they also do industry benchmarking. Um, being able to compare your organization across uh an industry benchmark, a very powerful story for urgency. Um, and everybody loves a radar graph. Once you've found your sense of urgency, you need to start by building your guiding coalition. And this is where security chapter comes in. Security chapters are not like a shadow resource. It is your your initial fan base. is your um your people who are going to test ideas. You're going to bring them

into tool um tool selection processes. They're going to test things for you. But these in in Cotter's eight steps, these are your guiding coalition. You need to build that base. So once you have your reason for change and you have your your small uh initial initial army, you need to give them a direction to march. And that's where your vision comes in. Where are we going? What does Nana look like for DevSec Ops? How are we going to measure our progress on Nana and what kind of projects might take us uh in that direction? And that becomes your road map, your DevSec Ops road map, your cyber program, what however you wish to brand it. But that then is your plan

that you start presenting to stakeholders, your consistent plan, which by the way can take two years to really pull this off. And after that, it's all about communications. Communicate, communicate, communicate. Especially in remote working environments, there's no such thing as overcommunicating. And I'm going to throw some awful business phrases now like omni channel. Your communications have to be across Slack, across teams, across email, presentations, in person. Your your stakeholders and the people you're trying to get your message across to are not just going to listen on the channels that you favor. You have to make the effort multi- channelannel communications that are clear, concise across every single channel as well as establishing front doors so people can

come and talk to you whether that is Slack channels, ask DevSec Ops, um just making yourself accessible for questions and keeping up those lines of communication consistently. Uh this I think this step is actually where technology professionals struggle the most. uh just a one one a one-time presentation, a one-time email, and that's that's just nowhere near enough, unfortunately. Step five is about empowerment. So, how do you help people adopt the change? You can't drive the change alone. You need to be able to give especially engineers the the ability to um adopt that change and drive it themselves. Whether that's running the tooling, whether that's education and training. Um what I love to do with my teams is secments. So I

very frequently I will rotate uh software engineers into the security space whether that's security operations for 3 months. I want them to see the kind of tools that we use. I want them to build relationships with the security operations teams but equally I rotate my engineers out as well. Uh my security engineers will spend 3 months in a feature team again to build relationships. But all of this is about a sense of empowerment. Security is not the SE thing. It's for all of us and we can all play a role. Once you've got all these things in place, we can actually start delivering things. And that's where all these kind of short-term wins trying to build

momentum, compounding returns. And we'll start with something nice and simple like developer education. We'll roll out an education platform. There's there's many of them. I like hacksplaining. These are very quick simple wins to help bring engineers, help them understand the language of application security. Um, but it's also easy and quick to to just win to help people get through this training. We might bring in a single tool, not all of the tools, not all at the same time. That's going to overwhelm everybody. You're going to find all these vulnerabilities and various different tools and you're going to scare people. Just start with one. And whether it's SCA or static or cloud security posture management, start with

one and start winning. And then we got threat modeling as well, which is such a fan uh there's another talk about threat modeling this morning. Um what a fantastic opportunity to build relationships between security and developers. a very easy thing to do. You can do it in PowerPoint. It's just so easy and a quick win to to cover your estate. And then when you get into year two, that's when things get really, really tough. That's when most change programs burn out. They lose their novelty. They're not fun anymore. And this is where stuff like gamification can be really powerful. So taking being able to rank engineering teams against each other. How many open vulnerabilities have you got? how many members of your

team have gone through the training or a part of security chapter. Being able to generate a score and compare teams month by month is really just that kind of novelty factor that can help maintain your change. Obviously, that needs to be done delicately because not all teams get to work on fancy new green Kubernetes things there. You will have the one team who is looking after the 20-year-old Java thing in the corner and that's a bit not it's it's kind of not fair. So these things have to what I usually do in this space is I um I report on the delta. So how a team has improved their security score month by month and whoever improves the most gets

the gets congratulated free coffees that kind of thing. And then lastly it's about how you make these things stick. You after 2 years you will also be tired. You will want to move on to your next job your next promotion wherever you want to go. And you need to be planning so that you can walk away from this. And that means identifying who's going to take the flag from you. Who's going to be that flag bearer? That might be a security champion. That might be a staff engineer. It could be someone moving into junior management position. But your job is to find them and help them play this game. Help them win so they can take the flag from you. So this

is Cotter's eight steps for change um overlaid onto a dev sec ops program. Okay. Then the next thing I want to talk about now is stakeholder management. Uh you don't need me to tell you that your organization has an invisible social fabric connecting everything. And there are going to be things that you cannot directly influence. And that might be budget approvals. That might be getting projects signed off. It might be getting tools adopted. For whatever reason, you cannot directly influence this. But your your social intelligence to understand your connections and the connections of those other people and the connections of the people that you're trying to influence is oh so unbelievably powerful and cultivating it. And that's what

stakeholder management is all about. But some of you are going to be saying, Seb, well I work in an organization with hundreds of people or maybe thousands of people. You're right. You can't be friends with everybody. Okay? So you need a plan. You need an approach. So this uh technique is straight out of operation strategy by Nigel Slack. This is a classic MBA textbook and this is about power interest grids. If you can imagine a a 4x4 a 2x two grid with the x-axis's power and by power I mean the ability for that person to mess with your day to mess with your plans. Some people are more powerful than others. Your boss for example very very

powerful. Okay they can mess with your day if they really want to. or executives or see senior stakeholders. But there are other people, peers, colleagues and people that might work for you, they're lower on the power that power uh axis. Now the people who have very high power but have low interest in what you're doing. Interest is now the the other axis. Okay, the amount of interest they have in what you're doing. People like your boss or for me, chief of information security, they're very powerful stakeholders, but they're actually not very interested in what I'm doing. Um the reality is they hired me to do a job to take a problem away from them. Uh and while that problem is not

on their radar, they're actually quite happy. So my job is to satisfy these stakeholders. That doesn't mean ignore them. That means reporting. That means uh frequent touch bases to help them understand what's going on. That's your strategy for managing these kind of stakeholders. And it's really important you do that because if these sleeping giants, that's not my name, that's Nigel Slack's name for them. Um, if they wake up and you don't expect it, that's really bad for you, okay? They can they can mess with your day. Or if somebody else is trying to wake up your sleeping giants, that's also an issue. You can mitigate that by keeping them fed with information, with reporting, with

metrics, all that kind of thing. Your next group of stakeholders are your key players. For me, this tends to be chief technology officers or senior engineering managers. These are people who have high power. Okay, the CTO can really mess with my day if he really wants to. you can start annoying hitting my sleeping giants over the head with a bat, but they're also really interested in what I'm doing because I'm impacting their teams. I'm impacting their delivery. I'm trying to change things. And with these, they're my key players. So, I have to cultivate those relationships. That means meeting them. That means scheduling one-to- ones. It means learning about them and helping that strengthen that connection so that

they can trust me. You're also going to have a whole field of stakeholders who are not very powerful and are frankly not interested in what you're doing. So you need to save your energy. You these people you really need to minimize your efforts at least in the scope of this project. Every project all the players change. Um but in this case just minimize your efforts just focus on your key players. And then lastly you have your again not my name Nigel Slack's name is your gad flies. These are the people in your stakeholder field who have low power. So this could be peers and and champions, but they're really interested in what you're doing and they're your fans and

you also need to keep them informed and whether that's through reporting, whether that's through monthly workshops, but you have to keep them informed in what you're doing because you still want them on your side. So um I do this with my junior management team. I talk them through stakeholder management and how to identify your stakeholders. They've always found this technique very useful. It just makes the the field of players a bit easier to deal with. Okay, number three, we're going to go into changing minds. So, this one I want to talk about um is the scarf model. One of my favorite books uh and sort of man mandatory training for anyone who reports to me is

your brain at work by David Rock. It's a fantastic book. I definitely recommend it. Um, one of the techniques in here is about scarf and about um, psychological safety and about how not only can you get on top of your own emotions, but how do you help other people get on top of theirs? When we're feeling angry, when we're feeling frustrated, the rational reasoning conversation of security is not very welcome. So sometimes we have to help other people get on top of how they're feeling first. So in the context of rolling out maybe a tool that blocks a pipeline deployment, okay, dependabot or something like that, five things we can do to try and help

those conversations and help people feel okay with this change. The first one is to acknowledge their status. We're all busy people. We're all trying to just achieve what we can for the business by actually recognizing someone taking the time to have a conversation with you, recognizing their tenure in the organization, recognizing their achievements in the organization, but also the status that can be gathered by going along with the transformation by becoming an elite team that cares about security. By acknowledging the status and the status gain from being part of your change, that can help them feel safer about what you're trying to achieve. The next thing is about certainty. Uh as as social creatures, we we hate

uncertainty. We hate it so much we'll lie to ourselves about reality to try and make it okay. There's a lot of uncertainty with rolling out tools. In the case of a pipeline blocking tool, things that will help is great documentation, but also planning. When is the tool getting implemented? When is it going to go into blocking mode? What can you do about it? The more certain we can make this this change, the more people are going to feel safe about it. And that is a good thing. You're you're going to hear me use this word safety a lot. A lot of making good change is about making people feel safe so they can listen to

the rational argument. So really being crystal clear when and why are the blocks going to happen and what can you do about it? Autonomy is a big factor as well. This is not just Seb trying to hit somebody on the head with a tool. We want the developers to adopt these tools, run them, educate them on how to do controlled bypasses in a safe way. What do those approval processes look like? Educate them on how to fix things so they're not a victim to the tool. This helps give them a sense of autonomy, allowing them to be part of the decision-m about how the tool is implemented. Again, helping them feel safe. Number four is about relatedness.

This is about understanding that we all have many stakeholders. We're all trying to do our best for the organization, but also acknowledging the pain that we are bringing. Okay? When we bring friction to the SDLC, that is pain. We should acknowledge it. It's for the better cause, right? It's for the greater good, but it is pain. So, don't ignore it. Talk about it. And that's going to help them feel just that sense of being related with each other. And finally, is that sense of fairness. There's nothing there's nothing more unfair than one team not getting the support they need for one of these security tools or they've got a different sensitivity uh on when their tool blocks like unless

unless they're trying to be the best team better than everybody else. You've got to just make the playing field fair. Okay, that just ens um ensures morale all those kind of things. So this is called the scarf model. SF um I actually plan my conversations based off this model. If I know I'm going into a tough conversation, I will write scarf down on a word document. I'll try and put some bullet points against each one. It helps a lot. Okay? And it's a great book. I definitely recommend it. The other thing I want to say about changing a mind is talking now about grief cycles. Uh this is Cubler Ros uh this is a Swiss psychiatrist. Um this

book actually came out I think it was 1969 uh on on death and dying. I'm not necessarily saying go and read this book, but there was a very key uh thing that came out of this book known as grief cycles. And by the way, I'm at no point saying that rolling out a tool is equivalent to bereiement or anything like that. Um, but what I'm saying is grief has predictable cycles and being aware of those can really help you navigate conversations. So in this case, removing local admin permissions that is always a tough one with developers. Okay, they need I need it to install my tools and build stuff. Any kind of loss is going to have a

grief cycle. In this case, the start of the grief cycle is around denial. There's no way he's going to take their permissions away from me. Now, in this case, you really need to remain firm. This is the start of your grief cycle. Remain firm in the conviction of why you're doing this. Don't feel that you need to start bargaining with somebody who's in the denial stage. You just need to wait. Okay? You need to tell you need to maintain your commitment as to why you're removing those local admin permissions. Tell them why and when. Maintain that certainty so that people feel safe and then just wait because we all process things uh on a cycle.

And eventually when that denial subsides, you'll get a state of anger. How dare they take that permission away from me? I needed to do my job. Security is blocking me. They're getting in the way again. And this is um the the reason why this is so powerful. People don't go into conversation saying, "I'm feeling angry." I wish they did. It would make life a lot easier. But your ability to sense this from uh people's words or how their their body language will help you say, "Oh, this person's in the anger stage right now. I'm not going to try and convince them with logic. That would be silly." What I am going to do is I'm

going to listen. Okay? I'm going to validate. I'm going to mirror. I'm going to match their emotional state. I'm going to repeat the things that they say back to them as a question. Mirroring very powerful technique. But at all costs, I'm going to avoid selling with logic because it's falling on deaf ears. After anger, we go then into the dip of depression. This is where people start to feel disengaged. I'm going to leave this place to somewhere else where they'll give me local admin permissions. security are getting in the way again. They don't want me to work. Maybe I won't work. Um, and that's fine. So, and I'm sorry if I come across as condescending. It's this isn't

condescension at all. This is understanding human behavior as they go through a grief cycle. And it's absolutely okay for everybody feel these things. It's normal. But at this point, depression is actually where I can start engaging in proper conversations. Now, I can be available to them. I can answer questions. But we can also start talking about hopes of improvement. How do we make this better for you? How do we make this with less friction? We can actually start going into the bargaining stage. Well, does do you need to lose it all the time? Is there priv uh sort of a pin process we can put in place where you can get admin temporarily? Is there any

way that I can assure you that if you need admin permissions, I'll get on the phone with you to help address your problem quickly? But this is the right time to have those conversations. You can't have it in the anger stage. It's not going to go very well. You can't have it in the denial stage because you're going to lose some of your negotiation power. So, understanding the where the conversation is, where they are in the grief cycle is so important. And now we can talk about buyins. Let's do this together. Let's work together to make it better. And then eventually you get into the acceptance stage. And if you get here, then congratulations. You

have ridden the grief cycle and you've not taken it personally, which is really the point of this slide. People will feel emotions. It's not about you, but your ability to navigate the cycle is going to make this a success. Okay. So, the grief cycle um Kubler Ross very very uh well interesting. I think the last thing I want to talk about now is about corporate communications. Again, I've got references and if anyone wants the references, just let me know and I'll send them out. Uh this is Argenti, Paul Argenti, corporate communications, another classic MBA textbook. Um and I said I think one of the biggest challenges of DevSec Ops is that internal communications. All too

often it's a single email or a single allhand presentation. Um this is Argenti's model for internal communications. Uh and I find this very very powerful. The first part of this model is around making sure that your communications align with the business strategy. Uh again all all too often dev sec ops seems quite grassroots or it seems quite rebellious. DevSec ops doesn't need to be a rebellion. It can easily align to business strategy. Um it can be novel, it can be virtuous, but it's just good business. Building products that are secure is just good business. Whether that's for customer value, whether that's for compliance reasons, I'm sure you will have uh much ease in aligning defec ops to whatever business strategy

is happening at the time. and you may as well get on the train, okay? There's momentum in that direction. Get on the train. Don't try and go the other way from the train. You're not going to win. Alignment gives your story credibility. The second part is about audience centric design, understanding your internal market, your target market. For me, that's engineers. I I like to feel like I understand engineers. Um, and that helps me create communications that that appeal to them. you'll see that I put a lot of thought into this. Uh, I guess that's kind of the point. Um, I like to tailor my me messages. If I put together a bit of internal communication

and it was boring to put together, it was probably boring to read and it probably got lost in every other communication. So, have the gifts, make things fun, have gamification, have have metrics. That's all good stuff. Compare, have stories that are other security stories going on in the world. do whatever you can to just make this interesting because if you want to win, you need to spend some time in this space. I've mentioned this already about consistency, omni channel communications. Um, you have to be where your customers are, your your internal customers. So whether that's Slack or emails or presentations, whether it means actually having to go into an office, I try to avoid that as much as I

can, but sometimes I do it so that I can meet my my internal customers. And the thing about hearing the same message across multiple channels is that it builds credibility. Whether or not that's true or like whether the message is true doesn't matter. Hearing the same message multi- channelannel builds credibility which is good for you. That builds trust. Trying to make sure that your communications internally are clear and simple. Your security champions will love to go in deep. Uh, I had a session last week where we were getting into Microsoft Defender and getting into Sentinel, which is really interesting for engineers because they they never see this stuff. Um, but that's not really relevant when I'm doing

communications across the board. You have to keep those messages very simple, clear, consistent, and memorable. There's also the element of credibility. It's all too easy in security to use the stick of FUD to make people feel scared about about attackers to seed uncertainty to seed doubt and that's a really dangerous tool to wield in infosac because that will start to impact your credibility. When these when these threats that you make don't materialize that infect that impacts your authenticity. So stick to the virtuous message of customer value of building a quality product about making it cheaper for security in the long run and don't overhype your statements. Keep them honest and believable. As soon as you lose your credibility, you you you

suffer as a leader. So it's this is very very important. And then the final one then is about narrative planning or or really just making writing a story. Uh we love stories. There's enough books about this that you can go and read, but everyone everyone likes a good story. What we want a plot. We want characters who are relatable. And at the end of the day, we are we are all the hero of our own little story. So, you need to be able to practice and plan your DevSec Ops communications to take this into account so people can buy in and enjoy it. Okay, so I've come to the end of that. So, there was four things that we

covered for great Dev Sec Ops transformation. So, number one, I recommend you learn about change management. It's a massive field of study. If you do an MBA, you'll have a whole module on this stuff. John Cotter up there is one of the I guess the classics, the titans, eight steps for change. This is an excellent book. We talked a bit about managing stakeholders. So, you've got Nigel Slack there, operation strategy. Um bit uh quite a long boring book, but there are some good bits in here. I would read about power interest grids. We did about planning for resistance. So, we talked about the scarf model. This is David Rock uh your brain at work. Fantastic

book. Everyone should read it. And then we also talked a bit about grief cycles as well. And then lastly, internal communications, how to communicate like a boss, corporate communications by Paul Argenti. Um, so and and that's it. So hopefully you found that just interesting, I guess, if you want to make an impact. Cool. Thank you. >> And I'll take any questions, I guess. >> Oh, fantastic. >> Question. I think the gentleman over there wants to ask question.

>> Uh thank you. It was a very good talk. Um many years ago before some of these were born uh there was a latest notes book that had a chapter on overcoming user resistance. Um, and my question is some tools I've decided are the right tool, but they do have issues. Have you come across that situation? Is there any tips for that? So, the question there was about um how to have I have I come across situations where I think I've got the right tool, but I'm still struggling. >> There's still issues with the tool. >> There's still issues with the tool. Yeah, that's that's a tough one. So, um having people brought into the tool

selection process I think is very critical. So, if I'm doing if I've come in and I'm choosing a static vulnerability scanner, making sure I'm bringing my change my guiding coalition into the journey very early being part of the selection process so that they've bought into the selection of that tool. They've also got skin in the game at that point. So if we are finding there are issues with the tools, there's feature gaps, whatever it is, well, we're all in this together. It's not just a sub tool, we've selected this tool based off our best judgment. So I think that's a good thing. Um I think the second thing is made if you can if you're a big enough organization,

develop the relationship with the vendor, bring them onto the course. Um companies like Sneak, people don't think I work for Sneak, but I love working with Sneak. They're very developer friendly. We have shared Slack channels. We can bring them into calls. That's fantastic. Um they can they can share some of the grief. Okay. At least be present or be able to communicate their road map about where they're going to address that kind of feature. Uh so I think some of it is bringing people very early into the process but also working with the vendor. Don't don't just take the brunt of it yourself. Have the vendor's help. I think >> Yep. Call mic here as well. Do you want

to run? Okay. We'll tag team. I'll do the next one. It's okay. >> Can you hear me? >> Yeah. >> You mentioned about change management there and um how do you how do you how do you manage a complete shift in change um successfully? So if you for instance are from a reactive security sort of uh area and you want to make that shift into a more proactive um area, how do you go about that change when you have so many people stuck in the old ways of how they used to do it? >> Yeah. And it's it's it's a fantastic question. It's a tough question. And the first thing that I need to say is that

your change horizon you need to be looking at 1 2 3 years for these kind of changes to be fully adopted. Um the average uh turnover for an organization is uh it's about 10%. So every year on your journey you are going to get 10% new players in your game and 10% of the old players are going to exit. Being ahead and making sure that you're capturing all the new people that are joining the organization, showing them your vision and what Nana looks like uh is so powerful to capture those new people because after 3 years, that's actually 30% of the organization who believe the status quo is what you've told them. That's really powerful. Oh

does that mean to pick up my daughter? No. Okay. Um sorry, sad, eh? Um so that's playing for the long game making sure you're capturing all the new people but uh after 3 years you'll have 30%. Um the second thing is you need to find uh your allies within the organization. Okay? Because there are people who also see what you see that things are wrong. Whether that's engineers you I mean usually it's engineers. They they see the mistakes that are happening or they've done pentesting courses. They know the bad thing that's going to happen but they think that they're on the road. And that's because nobody has stood up and shared a vision of what it could be. No

one has connected those dots. And that's why stuff like again security chapters are so important to try and bring these people together and realize that they're not on their own. Okay. So you will find a guiding coalition there. So I would start with security chapters. Um but you also need to identify the advocate role that I guess the role that I I tend to play and that doesn't have to be a security expert. Um it just has to be someone who's good with people and cares a bit about psychology and is quite good at planning. Um delivery managers can play this role very very well. Um, so having those pieces, having your kind of uh advocacy person, having your security

chapter, making sure you're capturing all the new people, that's all good stuff. Um, but the last thing I'd say is like communicating like a boss because you're going to be competing with other changes. Whether it's the agile crowd, okay, who want to do agile things or it's user experience trying to do user experience things, there's always many changes happening. But you can outplay people in the communications field because so many people take enough care, enough attention to make their communications internally interesting. You can win on this battlefield very easily. I think well hopefully that's some of it. I said I'd take the next one. It's okay. Get my steps in. So um just want to pick

up on a part of the comment you just sort of said there because actually you know I I used to work in large organizations. much prefer small because you can get things done. Um and the challenge is in a large organization is that while you're trying to change so are others and very often those changes can be directly competitive creating combative potential. How do you avoid that competitive potential? Yeah. Fantastic. So basically politics, right? Um so I guess I got a few a few questions on that. Yes, you're going to be competing for air time, competing for change. Um, I think having you using things like a power interest grid when you're working in much larger

organizations, you can spend the time with everybody. Trying to have strategies for different stakeholder groups, I think, is quite vital. Understanding who your key players are, who are the ones who, and that might not be based off their title, okay, that could be a staff engineer who's been at the organization for a long time, who has a lot of influence. They might not have the title, but they have a lot of power. So try and identify the people who are the most powerful and go speak to them. Get them on your side. Right. Actually, how many of you have just reached out to somebody in your organization just to have a virtual coffee? Yeah, not many. Right. That's such a

weird thing to do. I I set my staff, my team members uh weekly goals. They have to go and meet somebody new in the organization every week and have a virtual coffee with them just to get them in the practice of meeting people within their organization to help build their network, to help build their their social sphere in the organization. When you're playing at when you've got that kind of competitive element, you've got to be really good at making friends. Go and speak to these people. Understand that where where they're where you're competing. See if there's any alignment. If there's not, who who are their friends? Go and speak to them. see if there's other ways you can find leverage

uh upon these these people who are blocking you. Um but again I I I bring it back to internal communications. It's so rare to see good internal communications happen. I personally I try to always bring it back to this battlefield. I can now communicate people. I can make better presentations. I'm willing to stand up at the front. I'll have better metrics. I'll be able to tell a better story because I spend enough time in PowerPoint rather than an IDE. Um but that's that's the role that I'm playing. I have to. Okay. I'm sorry. Hopefully I answered just a little bit of that. Any more questions this time in the room? >> No, I think Can we let him go? Let him

go. Yeah. Go on then. No. Make him run again. All right. Give him a round of applause, please.