This article was a guest post from Chris Hughes. Go ahead and check out his author.
In cybersecurity, it is easy to forget one crucial fact.
The world (or our organizations) doesn't revolve around us.
We may agree with this concept out loud and at face value. Still, when it comes down to our daily interactions with our peers across other functional areas within the organization, such as engineering, development, business, and sales, we generally need to have our behaviors match our words.
How often do we take a step back and put ourselves in the shoes of our peers?
All too often, it is easy to get caught up in concern over the latest penetration test results, vulnerability scan, or compliance drill, only to forget that while this may be the most critical thing in the world for us, it is often not the most important thing to our peers, and typically not for our organization either.
The reality is that the business exists for a reason, and that reason is not cybersecurity.
The organization generally has some core competencies that they use to deliver value to customers, partners, and stakeholders which aren't related to cybersecurity.
However, due to our hyper-focus on security-related issues, it is easy to forget that the organization and our peers outside of cyber have focus areas where security isn't their primary concern.
This feeling of security not being a focal point can be incredibly frustrating when we point out that the latest scan has new critical and high findings. Likewise, it's disappointing when the security-related technical debt backlog gets de-prioritized or not pulled into sprint planning considerations.
While security teams focus on the latest outputs from the CI/CD security tooling, developers focus on delivering new features. In addition, there are pressures from product managers and go-to-market teams to build capabilities and forego technical debt management.
While security teams focus on the latest penetration test report, product managers often focus on getting the latest version out to appease a critical stakeholder vital to the product's continued existence.
While we're focusing on the need to address the lengthy compliance requirements we're well versed in, our engineering and sales peers may be focused on landing some critical early sales to ensure the organization has enough runway to continue to try and make the product and company a success.
In a world that seems so technical, it is easy to forget that humans are underneath all the bits and bytes.
Humans' personalities, aspirations, and incentives align with their organizational roles. However, you can rest assured that those incentives and factors that evaluate their performance most often don't include cybersecurity.
By practicing empathy for our peers, we can better understand their role within the organization and what is expected of them from their leadership. We can also get a better sense of how the requests and requirements we often throw at them impact other critical tasks they have that our demands will potentially impede and impact. How often, if ever, do we take the time to reflect and inquire about the potential stress and impact our requests have on our peers?
This lack of empathy and curiosity for the roles, responsibilities, and demands that our peers in the organization face can often lead to resentment, bitterness, and them doing their best to avoid security due to having a negative experience and emotions associated with us.
In a world striving to break down silos and usher in an era of DevSecOps, continuing to pursue behavior that builds those walls up versus breaking them down is outright counterproductive.
By practicing empathy for our peers in the organization, we can build further rapport and collaboration and often drive better security outcomes than if we are callous and demanding with no concern for the impact it may have on our teammates and co-workers in other areas of the organization.
It also may open your eyes to what it feels like to walk a mile in their shoes; you may be surprised to learn how security looks from the other side alongside the other challenges and pressures that exist as a developer. All of this should help us build more developer-friendly services and tooling.
Implementing empathy in our daily interactions can lead to better security outcomes for the organization, and isn't that what we're after at the end of the day?
