My next class:
Security Culture for LeadersAmsterdamOct 7th - Oct 11th 2024

Distraction as a Service

Published: 2017-03-25. Last Updated: 2017-03-25 12:02:56 UTC
by Russell Eubanks (Version: 1)
6 comment(s)
Have you noticed that some security projects never seem to get finished? Despite the best of intentions, often times they linger, sometimes for years. I believe that distractions play a role in security projects being delayed and ultimately never being completed. If not monitored closely, nothing will get moved from the to do list to the this security project is finally done list.
 
For me, it has always been natural to accept every new project that needs attention. I want to be helpful and perceived as a good team player and I bet you do as well. I found that it is easier to say yes to every request for help than to say no. I suspect that "why yes I do have a minute" and "of course I can help you with that problem” sound very familiar. I have found this behavior can also carry potential for a negative reputation as an information security professional when it impacts the delivery of security projects.
 
While it is normal to want to help, it is not always natural to remain focused immediately after a distraction occurs. I have determined to ask the question "what is the next action I can take right now?” immediately after a distraction. I found this behavior helpful to remain both mission focused and results oriented. With some intentional discipline and focus on the impact of distractions on security projects, the impact of unplanned distractions can be minimized.
 
It is impossible to enumerate all of the ways distractions can impact a security project. It is very possible to more quickly recognize them when they occur and put measures in place to reduce the impact of distractions severely impacting productivity. Are distractions keeping you from closing out projects and ultimately preventing you from providing full value to your organization?
 
Please leave what works in the comments section below.
 
Russell Eubanks
6 comment(s)
My next class:
Security Culture for LeadersAmsterdamOct 7th - Oct 11th 2024

Comments

I think that this it is a common scenario to run into asks for help that are distracting. It is situation dependent, but it is important to know when to say no to projects and tasks that aren't beneficial, or will distract from more important projects. Ideally there is some sort of culture or organizational structure in place to minimize the occurrences, but that may be idealistic. I like some of the suggestions this article in the Harvard Business Review has for being tactful about saying no: https://hbr.org/2015/12/how-to-say-no-to-taking-on-more-work. Personally, I try to be honest and to the point. I used to have a tendency to apologize, but now I feel apologizing for saying no is an incorrect way to empathize with the requester. I try to simply state that while I'd like to be in a position to help, I'm not available to commit time to the ask and leave it at that. I don't need to be sorry/apologize about it because that is the truth. As unnatural as saying no feels, I try to keep in mind the objectives and best interest of the organization when making the decision about whether to accept additional work.

Cheers!
thank you for the information.
Catalpa88,

Love your comment - “it is important to know when to say no to projects and tasks that aren't beneficial, or will distract from more important projects”. Very nice pointer to the Harvard Business Review article.

Thanks for supporting the Internet Storm Center!

Russell
[quote=comment#39197]I think that this it is a common scenario to run into asks for help that are distracting. It is situation dependent, but it is important to know when to say no to projects and tasks that aren't beneficial, or will distract from more important projects. Ideally there is some sort of culture or organizational structure in place to minimize [url=http://bantayso.com]website[/url] the occurrences, but that may be idealistic. I like some of the suggestions this article in the Harvard Business Review has for being tactful about saying no: https://hbr.org/2015/12/how-to-say-no-to-taking-on-more-work. Personally, I try to be honest and to the point. I used to have a tendency to apologize, but now I feel apologizing for saying no is an incorrect way to empathize with the requester. I try to simply state that while I'd like to be in a position to help, I'm not available to commit time to the ask and leave it at that. I don't need to be sorry/apologize about it because that is the truth. As unnatural as saying no feels, I try to keep in mind the objectives and best interest of the organization when making the decision about whether to accept additional work.

Cheers![/quote]

i agree with you. like
I would argue that this is where management needs to step in and be held accountable. If your team is being pulled in 300 directions, they're going to do majority of those things poorly or rushed in order to bring the bar up on their more important projects. This causes oversights and failures, both for the implementers and the managers.

Management needs to be the buffer that exists to declare that these projects are top priority. Any other requests for large changes or project work must go through management and be approved - moving other projects around accordingly to ensure everything is succeeding. Sadly, this is not the case in most organizations. Information security professionals are working to help organizations succeed - that is our purpose in a nutshell.

I have grown weary of that helping them succeed always equate to: "This is business critical, I need you to jump on it right now." I've watched projects fail due to them not engaging security early in the process to ensure the architecture, configurations and connections were secure. On the other hand, I've seen several projects pop up on my radar that had engaged security early, received requirements and deployed them effectively. This made our job of implementing final steps very easy.

Management should be holding project managers accountable as well. I've had many project managers deflect their duties onto me; forcing me to reach out to the necessary parties to make things happen. Project managers should engage the necessary parties to get the work they need done - this ensures they can get realistic timelines from all personnel that have action items and helps them develop a dependency list: John can't do Z until Tom does Y and Bill does X. It shouldn't be on the engineers implementing - it's bad form.

Overall, I'd say it comes down to management and process control. Make information security as much a part of your culture as physical security and then it will begin to naturally flow. It'll take a few to several years to achieve it, but nothing is instant in this field.

#Rantover :D

~Traven
Traven,

Thanks for your response. I agree that Leadership (management) has a role to take care of the team and to help guide their priorities as well. I also agree with you that culture change is something that generally takes a long time to achieve/ realize. If you are fortunate enough to be in a healthy culture, count yourself fortunate. If you do not, seek ways to influence it to a better place!

Thanks for supporting the Internet Storm Center.

Russell

Diary Archives