marietheresa / improved-lamp Goto Github PK

It's easier to convince managers, developers, and everyone else that you are facing a problem if you have the numbers. So, if you can, take your problem and assess how much it affects your organization.

Let's say you're trying to make an argument for introducing a security scanning tool, then do a proof of concept. Turn it on and see what happens!¹ It's just so much easier to make a compelling case when you have the facts. So do yourself a favor (if you can) and get some.

Change is inevitable. And when it comes to cybersecurity, changes are often decided by someone in charge. That's just how it is.

But in this stage, we're nevertheless trying to create as much goodwill towards your change as possible. To do that, you must convince your developers (or whoever else is the recipient of that change) that going through that change isn't worse than the status quo.

In this issue, who'll do that by communicating everything you know the minute you know it.¹ Make it impossible to conjure up the specter of endless overtime and ever-changing deadlines by communicating often, clearly and in detail.²

So when management sets a meeting to decide on your change next week on Tuesday? Let people know. When you've got the okay and are trying to get the budget? Good job, but let people know. When you've talked your (chief) information security officer into not setting any deadlines in the next two months? Definitely let people know.

You know the saying, "communicate early, communicate often"? This stage is what that saying was meant for.

For anything that's new, teaching people how to do it will make the change go much smoother. Think about it: is it easier to follow someone along or to try and figure everything out by yourself? Even if you provide written documentation, people will have an easier time following it after seeing you do it. Because communication is hard, and written communication without the immediate feedback loop is even harder.

This is why, if you can, you should provide your developer with live training, aka workshops. You could pay a vendor to do that for you, but I think - if at all possible - you should do it yourself. And if you did #7, that's the perfect basis for creating¹ your workshops here.

Creating your own workshop will ensure they fit your company's environment and constraints perfectly. That's going to reduce friction and avoidable frustration. It will also let you put in and talk about non-technical topics like requirements and deadlines. And that's a good way to repeat that information and to ensure that as many people as possible have heard it.² Additionally, holding your own workshop will give you direct feedback on what people are struggling with. That's invaluable information to ensure a good transition. And to get that, you'll first need to create your own workshops.

By now, you - and hopefully most people affected by the change - know generally what you want to achieve. Now, it's time to finalize things and fill in those details. That's right, we're making a plan!¹ So you'll want to answer your basic wh-questions² and use those answers to create requirements, tasks, and deadlines.

And yes, this is a continuation of #4. And that's okay. But while you might have mentioned the broad timeframe and the general task before³, now we need the details. And you'll need to be as detailed as possible to prevent confusion and misunderstandings. And that's important because it can help avoid undermining motivation.

So, define what the requirements are precisely. Right little text blurbs to explain them. Set deadlines for specific dates and not "the end of October"⁴ or even worse " in the fall". Make it obvious who you're talking to and what information is aimed at whom. Tell people about how you will support them and give details on that.

And remember, you don't have to share all that information simultaneously, but you'll want to get it all out quickly and definitely at this stage.

Yes, I always include time for Q&A in my workshops. And that's great for any questions that people have immediately. But that's not enough. Because when people start putting your change into action themselves, that's when a lot of questions come up. And if you want to keep that early adopter momentum going, offering Q&A sessions to address those questions can be beneficial.

I like to schedule them slightly after the first round of workshops but not too far into the future.¹ To avoid awkward silence in these sessions, I prepare a couple of questions.² These might be questions people dm'ed you about, or if there aren't any, bring some yourself. This isn't really about the quality of the question³. It's more about getting things going - they work like an icebreaker, if you will.

If you can, take notes on the questions and answers and provide a summary later for everyone to refer back to.

Yes, the focus of this rollout plan are your developers. And yes, you'll most likely need support from your management as well. Making an informative and not-too-long slide deck is an excellent way to achieve that. Yes, it's a little boring, but it's a staple for a reason. Just don't include 150 slides or use all the clip art.¹ I find that putting your arguments down on paper like this also helps organize them in your mind, which often makes you better at communicating them.

You've worked hard on creating change. Your developers really came through. Awesome! Now, let everyone know publicly. Use those announcements to create good vibes and say thank you. Show management that your organization came together. If you can have a little celebration IRL. Bring cake.

After all the hard work, coming together around positive events is crucial. Sharing them isn't just enjoyable, it will also strengthen your relationships. And those are really important. Because when the next significant change happens, you'll need them to turn that into a success as well.

Look, some corporate security teams might not have the time. Feel free to skip this issue if there are only two of you.¹ But if you can wrangle some time away from other commitments, take that time to work through every task you set for the people having to change yourself.

That will accomplish a couple of things:

• it will give you a better understanding of the work involved, which will help you set realistic deadlines and tasks
• it will give you a better understanding of where people might struggle, which will let you provide appropriate help
• it will teach you everything you need to know about the change, which in turn will let you teach your people
• it will make you more believable when you talk about the change because you know what you're talking about

If I'm rolling out a security scanning tool, I'll try setting it up in one of my repositories. I'll look at the alerts it provides me and try to understand them. I'll try to solve a couple of the alerts. I'll try to understand each of the different functionalities of the tool in all of the use cases I can think of. And then, I'll read the documentation for all of that to understand how it works and to learn about the current limitations and edge cases.

Jumpstart your change by showing everyone how to complete the required tasks step-by-step.¹

Keep these workshops under an hour to fit them into a typical workday more smoothly. I also like adding time for a quick Q&A to deal with the most pressing things immediately. Host these workshops multiple times - at least twice - over multiple weeks to maximize everyone's chances to take part. Provide your slides afterward.

Start with the boring stuff: requirements and deadlines. Who has to what when? Then, provide background on the feature (what can it do, what can't it do, how does it work)² before explaining the steps necessary to start using it. And then show a live demonstration of how to use the feature. Yes, that's repeating yourself slightly. And yes, that makes it easier for people to understand.

This one really is optional. But if you can make office hours happen, they can be a great addition. To me, office hours are the least structured format of all the formats mentioned here. They're literally just someone from the security team being available to talk to. Just like how office hours work at uni.

So if you show up and you're expecting to be able to lurk and hear something interesting, you'll be disappointed.¹ If that happens, that's what I'll say, but in a friendly way. Because that's just what this format is, we make our time available to everyone with more individualized, tricky problems than we can reasonably address in the #11.

Sometimes, those problems are so out there that they might interest only a few. Sometimes, it's because they'll likely take up a lot of time, and we want to talk about various questions in the #11. Either way, office hours are a great way to help people who usually need help² and build relationships with your more interested developers.

Some people want to take things apart and understand how they work on the inside. Some people like to customize how their tools run to optimize their workflows. Some people want to get all the details before they do something. For those people, I like to host expert-level workshops.

The workshops in #10 provide everything necessary to use a tool or feature immediately. The expert-level workshops aren't necessarily more advanced, but they do cover more ground. Throw everything you think is exciting or might interest someone into these. But keep the same format as the introductory workshops.

For GitHub Advanced Security code scanning, I've covered things like how the code scanning workflow works and how you can customize each part of the workflow, starting with the code scanning analysis engine and ending with how to consume code scanning alerts outside the repository dashboard.

None of those things are technically necessary to fulfill the requirement to use code scanning. However, teaching developers about the options for customizing a tool they're required to use can make the usage less painful and restore the feeling of being in control, at least partly.

The last time you directly communicated with management was in #1.¹ After creating tasks and deadlines in #6, now might be a good time to loop management back in. Mainly because you want them backing you up during the next stage in case teams start complaining to their execs.

The second reason why I like to run stuff by management (yet) another time is that there might be tasks, deadlines, and requirements coming up that you don't know about. Challenging your deadlines - before you communicate them to your developers - with management is a great way to avoid double booking. Management will be able to tell you about these bigger picture things, and then you can take them into account and - if necessary - schedule around them.

Your developers will be forever thankful if you don't schedule the rollout of your change at the same time management wants to start everyone on a new task management platform.

People still on the fence about your change need easy access to all the information you've already shared. They might be trying to determine if your change will impact their roadmap and want to look up the tentative deadlines you put in that e-mail six weeks ago. Or they might want to know if anybody on the team can work on the tasks you defined, and now they want to refer back to that post you made about that last Thursday.

And the less friction getting that information creates, the better off you'll be because their patience trying to get it won't be endless.¹ And when they run out of patience, they'll form an opinion about your change based on the information that they currently have.

But older chat messages are notoriously hard to find.² Forgot what channel something was posted in? Good luck figuring out which of the dozen security-related channels the team uses for announcements.³ Can't remember the keywords in the title of the post you're looking for? Have fun scrolling through every message posted ever in the last quarter. And while e-mails might generally be more accessible, getting information from them is still a pain.

So, it's a good idea to start creating a more permanent form of documentation at this stage. Write everything you know - and even the things you don't know yet but are thinking about - down and then link to that documentation in each of your posts (or e-mail if you must). It will give people a single point of truth to come back to again and again, making it that much easier for them to be informed and follow along.

Just bring it up. If you have a regular meeting with your developers - great use that. If you don't, maybe there's another regular meeting where you can get 10 minutes to discuss security topics. The point of this issue is to make everyone aware that you're working on something that will likely result in a change that will affect them.¹ So explain the thing, explain why and how it poses risks to your organization, and promise to keep everyone updated (and then actually do #4 ).

So, if I were trying to communicate why we need a security scanning tool, I'd talk about how we currently don't know how secure our source code is, how that puts us at risk from vulnerabilities in our own source code, but also known vulnerabilities in external dependencies and how easy it is to find secrets (often in an automated way) in repositories. And how you can't improve, what you don't measure.