As security leaders, we should explain the "why" behind our decisions, and especially our instructions, even when they seem obvious.
A few years ago, when I led infrastructure security for Fastly, I had an exceptionally thoughtful team member who would regularly spend our 1:1 asking me about my decision-making process. It was uncommon, as most 1:1s tended to be either about tactical issues, or long-term career progression. But she would ask about some decision we had made, and specifically, why I had prioritized that one, and how I had reached that decision.
I always found those discussions invaluable, for my personal growth as well. Explaining my train of thought, combined with her questioning of my decisions, made me realize where I was off the mark, or had missed some element of cognitive dissonance.
Notably, the discussions made me realize why it is so important that each time we as leaders make a decision, we make the effort to share why, and most importantly, not rely on the "hammer of security", or appeal to authority, to get people to implement what we want.
Over time, psychologists have tried to explain the value of "why" in a number of different ways. You've all seen Simon Sinek's "Start with Why", but there is more.
Deci & Ryan's Self Determination Theory describes how people have a basic psychological need for autonomy. It explains how people will feel happier and more fulfilled when they are taking action because they genuinely believe the reason why. A sub-theory of this school of thought, cognitive evaluation theory indicates that giving individuals a feeling of competence and autonomy can increase their intrinsic motivation. Rewards, feedback and explanations can all help increase that sense of competence. Procedural Justice, on the other hand, is the set of processes to make resource allocation decisions and a core part of democratic societies. It strives to ensure that people have a voice, and have a means of assessing that their leaders have good intentions. Without understanding why we made a decision, we cannot meet either condition.
Brehm's Psychological Reactance Theory, additionally, explains how individuals become reactive when their ability to choose is affected. Explanation acts as a mitigation, as it reduces the feeling that someone is controlling them arbitrarily.
One final, very practical study that will be of particular interest to you who want to get things done quickly, is Ellen Langer's copy machine study from 1978. She found that when asking to cut in line to make photocopies, even having a nonsense reason ("because I need to make copies") drastically increased compliance.
Later studies on all of this work showed the results are often more nuanced (e.g. Langer herself showed that as the cost went up—the amount of time her study subject would spend at the copier—only meaningful reasons continued to have an effect. But there are clearly some academic indications a "why" can make a real difference.
I think we see the value even more clearly through three simple hypotheses we can test every day:
- If you genuinely respect your peers (let's say development teams you work with) and their technical prowess, you are open to the fact that they may know how to solve a problem better than you do. Explaining to them "why" you believe "a" solution is the best way to mitigate a risk—and exposing your thinking—gives them the opportunity to step in and help solve the problem in better, more effective ways. You'll convince them that you consider them real partners, and may end up with better outcomes. Win-win!
- Many individuals learn best from others, and especially those that are more senior to them. By modeling and showing how we make decisions, they get an opportunity to grow faster, and make better decisions of their own, scaling your ability to influence the organization. Security, more than many other fields, benefits from apprenticeship, and the more we acknowledge that and implement it in our daily work, the better leaders our organization will develop.
- There's always the possibility we are wrong. The only way we can find out we're wrong is by sharing the assumptions behind our decision-making. Finding out we're wrong helps us grow, and allows us to gracefully accept an improvement leading to a better outcome. While finding out we're wrong can be painful in the short term, dealing with it gracefully is what I've truly seen propel careers ahead.
I hope I've established some reasons why sharing the "why" can be so helpful.
Knowing your audience – and focusing on what needs to get done
Now, is sharing a detailed "why" appropriate in every single situation? I'd argue almost all.
But there are exceptions. When you're dealing with an unconscious person, you don't call out "Get the AED" and then explain the various reasons you may use it. Instead, you just want people to act. During security incidents, or some high stress situations, you may find yourself in the very same situation, and will need to appeal to others to just do what you ask them.
If you've been able to share with them "why" in the past, chances are good you will have built up a good amount of trust that will get you the outcomes you're looking for.
I learned this limitation when I tried to make a "quick" decision in my first few days at a new company as CSO. I had joined a meeting on a specific, bug bounty-reported product vulnerability. I shared my point of view, that we should implement a drastic fix which would protect users, but break the user experience. I noticed I lost the audience pretty quickly. The meeting became a little adversarial, and I even appealed to authority, to persuade others of my point of view. As a new leader in the team, I was overcorrecting. And it lost me credibility.
Looking back, it harmed my relationship with these leaders. Had I taken a few extra minutes to ask for their point of view, and brought them along, it's likely we would have found a better fix. Or at the very least, a better way of implementing it.
A year in, I worked with the same engineering leaders on an incident. At that point in time I had built the trust I needed. We quickly aligned on a point of view and I was able to get some pretty intrusive asks done.
You also need to be able to tune how much depth you share in your "why".
Communication should always be focused on the recipient. No two people or groups are the same in how much information they need, and how it should be delivered. In a staff meeting, you can share a lot more technical detail about how you got to a certain point, and engage in discussion back-and-forth on what the right path really is. People will disagree and it's important they feel heard.
When you're meeting with your entire organization, that still matters, but you want to be a bit more thoughtful about how everyone in the meeting, with varied backgrounds but all still security people, perceives the discussion. You want them to leave agreeing on the outcome, and not wondering whether the discussion means the point will be revisited endless times.
Accuracy matters especially when you communicate with large groups. When you are communicating with the entire company, or deciding on a user interface element of a control that prohibits a user from doing something dangerous – you will want to be really clear while still explaining the potential impact of what they were trying to do. Telling them "this site is blocked" frustrates people. Telling them it is blocked because it hosted malware in the last 48 hours helps them understand why you made that decision, and reduce some of that feeling.
Each time we communicate with people, it's also a grand opportunity for Security to educate. People learn far better from getting feedback "in the moment" than from attending a yearly security training just when they have deadlines to deliver on. So, any time we explain a reason, we want to be accurate and avoid hacklore, outdated security advice that many people are starting to realize adds little to no value.
A final issue we as security professionals sometimes run into is that we have to defend decisions that may not really be fully ours to make. Examples include when we roll out a control because it is something our auditors/insurers/customers expect, but may not meaningfully improve security. For some organizations, phishing tests may be an example. Another may be when we deal with outdated compliance controls, for instance requiring unnecessary and unhelpful password changes.
In those cases, I've always followed two simple steps:
- First of all, ask yourself if communicating the requirement is the right thing to do. Or if you should push back. There may be a way to get to a better outcome and not to defend an ineffective control. Can I develop a convincing statement that prioritizes the right security work and explains why it deviates from what they expect? Actively defend newer research that, for instance, shows mandatory periodic password changes are not helpful, and there are better ways to protect accounts, such as MFA and passkeys.
- If this does not help, realistically express the actual value of the control to the people that will be affected by it. You may want to explain that sometimes, business considerations need to take into account a complex set of requirements. Customers do really expect products to be a logical extension of their own security program, and as a result their needs matter. And when we run phishing tests well, they can result in increased reporting, which helps you get a better handle of issues such as targeting.
How to share your "why"
In my experience, I've found it important to have patterns on how you communicate your why, without getting formulaic. When you use the same pattern time and time again, people may come to focus on how you're sharing your point of view, rather than the point of view itself. On the other hand, if you share in a unique way each time, it may be hard for others to catch on to the detail you're sharing.
In general, I found that in written communications, it's good to start with a tl;dr (too long – didn't read) or BLUF (bottom line up front) section that shares your point of view. And then share any supporting information that helps get your point across and educates. This lets readers understand things quickly, and dig deeper as is helpful.
In spoken communications, depending on the meeting, you can:
- lead with the problem and the decision, and then share the reasons why; or
- lead by stating the pertinent facts of the issue, and then build up to your decision.
In both cases, you develop a narrative arc that helps bring people along, but both have a different impact. Starting with the problem gets to business quickly, whereas starting with the facts or first principles builds up tension and is often easier to understand.
Having clear breaks between your facts or reasons can be helpful—for example, say "First, we need to improve developer efficiency; second, we need to reduce CVE count; we can achieve this by making systems more homogeneous and ephemeral, and automate our testing." People can only remember a few things at a time, roughly 7 (Miller's magic number), and breaking things up helps them "chunk" better so we remember them.
For me as a listener, the second strategy often works best. But both will work with different people and in different meetings. Early in my career, a senior security leader I look up to and learned much from, told me over a water cooler conversation that I wrote e-mails that were too long, so they missed the point. Solid feedback! After learning that point of view, I ended up using the first strategy more than the second. Outcomes matter.
Takeaways
Sharing the "why" has been instrumental in my career, and I'd encourage security leaders to think about how frequently they do it, and where they can, do more of it. It's a fast-moving field, and sharing our why helps both others and ourselves grow.
Consider the opportunity cost of not sharing your why. If you just share opinions without your why, it incentivizes others to continue coming back to you each time.
It means you and your team will constantly be stretched in all directions. Share the "why", and you're outsourcing some of your own decisions by educating others. Sharing the "why" as a security leader gets you more effective decision-making. And as a result, a more resilient organization.
Importantly, it will highlight your blind spots, making you a better leader, too.