The Three Phases to DevOps in Security (The Real Magic) - PART II The Actions, starting with People
This is part two in a five-part series. If you’d like to understand more of the stories behind this work and how it can be applied to making your security organization more effective, collaborative, and engaged, contact us….
In the first blog we considered the importance of a strong foundation. The objective in changing people is to be a catalyst for changing culture. The goal is to lead the team towards collaboration, communication, discourse and learning while avoiding being anonymous, disconnection and debilitating blame. The objectives are to:
The objective in changing people is to be a catalyst for changing culture. The goal is to lead the team towards collaboration, communication, discourse, and learning while avoiding being anonymous, disconnection, and debilitating blame. The objectives are to:
* Know who your customers are
* Build “emotional capital” with customers
* See broad collaboration as the core to succeeding
* Make the Team feel valued - contributing
* Using Empathy & Discourse to collaborate and solve problems
* Leading by Example
1. Meet Everyone (the Customers): The very first thing I do with a security team is ask them, who do you know in the organization. So far, other than one lone individual at one company, they respond just with other IT people – usually support desk, or infrastructure (usually networking). My response is to task them with getting out and meeting all of the company. I remind them that what the company does pays their salaries and bonuses, so it would be really good if they knew what that was. We set up a grand tour where we meet every business unit within the company, and the security team is tasked with only one task - listening. They visit Marketing, Sales, Manufacturing, Distribution, Finance, Legal…any and all groups. I challenge the security team to ask: “What is it that your department does?”, “How does what you do provide value to the company?”, “What keeps you up at night?”, “If you’re department wasn’t available, what would happen?”, “What processes are critical? What technology is critical for you?”
Oh, and I remind them that there isn’t a wall between IT and “The Business”. IT is part of the Business (thank you to David Schenk for that mantra). Further references to “The Business” as a “them” costs them a quarter in a cookie jar.
Result: The team finds out who their customer is. They will gain an appreciation for what the company does, and what is important to it. Their customer’s value, concerns, and problems become real. Now the things that security thinks about can become grounded in what the organization values. There will be an affinity and empathy towards what the organization does, what pain points exist, and how security and its actions have an impact. It Changes the team’s approach from an abstract “Do this so the company doesn’t fail!” to “This will help distribution because they system won’t be disrupted!” or “Charge records will get to Fraud Prevention on time.”
2. Communication: I mandate communication patterns between the teams. I set down a few rules, many of which will sound like some training you had at some HR event:
* If your email exchange goes beyond two messages, make it a phone call.
* Better yet, always start with a phone call. Email is only for transmitting data (files, file manager…)
* No, better yet, if you can, walk over and talk to the person face-to-face (I do it by the theory “Managing by Walking Around”.
* Group meetings are either Face-to-Face or with Video. Video is good when everyone is remote (global).
* Communicate frequently – have team group meetings and everyone attends. I have one-on-one’s weekly to ensure people feel listened to.
Result: The team knows each other, their faces, and who each other is. The team learns that most of communication is about facial expressions, vocal tones and things that don’t transmit via email. Do not let people become anonymous. Encourage people to feel included.
3. Collaboration & Discourse: During meetings encourage feedback and contribution from all team members in priorities, learning, teaching, and what gets done. I have found that putting people on the spot for feedback doesn’t work well for those that may be more introspective, however making it clear that feedback is welcome, and will be considered opens the opportunity for them to speak. This is achieved by making it clear that you expect your ideas to be challenged, and that you allow the team to do so. Consider any feedback you do receive carefully – testing it with the team members offering it, examining how it can disprove your ideas (not how it confirm them). Make sure the comments are focused on the idea, not the person suggesting it. We all have ideas that have faults, so no sense blaming. Rather it is better to refine the idea which becomes a learning experience. You show value in their ideas and feedback by publicly considering it. As a manager, allow your statements to be challenged. Ask your team to disprove them – how could my idea be disproved?
Another technique I use is to ask each person in the team to come with updates on what they are doing so that they understand that everything going on is important and we should discuss it together. Give them praise publicly for presenting the idea (not just when its right).
Result: You’ll be modelling what you expect your team to do in their interactions. You’ll surface assumptions, find faults in designs and ideas, and gain a lot of opportunities to teach, and learn! You’ll create feedback loops – a willingness to discuss openly any issues, problems or concerns. You will do it in a manner that is open, lacking in blaming the individual, but focusing on the idea. You will create an environment where people will feel they can participate.
4. Be Willing to Fail: Model this from the top. Admit when you make mistakes. Give others in the team credit and make it wildly public. Recognize success globally but keep mistakes internal. If a team member makes a mistake, take the blame on your shoulders to address, and have the conversation one-on-one with the team member. Understand the issue and encourage the learning process by talking through what happened, and how it can be avoided in the future. As the organization as a whole learns blameless environments, you can let mistakes be examined more broadly, but until that adoption occurs, you need to ensure that the team knows that you won’t hold mistakes against them (unless they are systemic and chronic).
Result: You’ll have a dedicated, loyal team. One that sees learning as a sign of strength. One that feels they contribute, they’re recognized, and that faults, while always painful and frustrating, will be less so – that they feel they can move forward, learn, grow and correct what goes wrong.
The concepts of “understanding your customer”, collaboration, and learning is at the core of Virtual Clarity’s [methodology] where we help you achieve the transformation in your security team. Reach out to Virtual Clarity to see how we can help send you on your journey….