When we approach others with curiosity to learn about their work, their priorities and their concerns, we gain essential insights to reframe discussions and reposition efforts to ensure the success of our security initiatives.
I got my first introduction to the importance of learning from others back in 1999, as the chief security architect for a global network migration project for a financial services client in New York City. Eager to prove myself, I was a touch amped up and ready to solve all the problems that didn’t exist.
I remember Steve, the partner, coming to my desk and checking in with me after a meeting. He assured me that nothing was wrong, and I wasn’t in trouble. Looking back, Steve taught me a lesson that improved my career.
Steve strolled over to the whiteboard that lived past its prime, propped up on a shaky easel next to my desk. He grabbed a fresh marker and asked me to explain my thoughts on the security architecture. Before I started, he got a smirk on his face and said, “Wait, hold on a second.”
He uncapped the marker and drew a blob in the upper corner of the whiteboard. “By the way, we have to connect to this system (that I no longer recall).”
Then Steve drew a circle in the middle with arrows going in multiple directions. “Don’t forget, we’re stuck with this middleware, and your solution needs to work with it.”
Steve continued to add a few more blobs, arrows and notes before putting the marker down. Then he looked over at me and paused for a second before asking, “Did you think you had a clean slate to design from?”
Almost laughing, he didn’t let me answer.
Steve simply explained that anyone can design from a clean slate, but that wasn’t the task. My team needed to design the right solution to fit the situation. And to do that, we needed to go find and talk to the right people to fill in all the pieces of the puzzle.
We needed to learn from other teams how to architect our solution. What was true then remains true today.
But not everyone figured this out. Just a few months ago, two security architects described their solution and documentation to me as “perfect.” They explained if people only took time to read what they wrote, we’d have no problems and they could go focus on more important work.
When I asked how many of their colleagues they’d talked with to develop their perfect solution, would it surprise you the answer was zero?
I reviewed their work to learn perfect was not an accurate description.
Just to make sure, I found a few folks in their target audience and asked them to both read the document and try to follow it to enact the solution. No one was successful and everyone ended up confused. Getting the project back on track meant finding and learning from the people affected by the change, so we could design the right solution for the environment.
Success in security means we need to get out and talk to others. Better, we need to learn from them. They have priorities, too. And sometimes (often), security gets in the way. They are smart and capable, just like us.
Not sure where to start? Try asking them:
- What priorities are they are working on?
- What gets in the way?
- What’s the hard part of complying with security?
- What is important to them?
- And what else is going on?
The key is listening to what they say instead of waiting for the pause and your chance to inject the idea forming in your head. Slow down to listen to what people tell you and use the time to learn from what they know. Sometimes what they reveal is better than just the technical and process insights we thought we needed.
Consider what happened when we took time to understand the needs of the group before implementing a security control — they wanted to know what took us so long!
Part of making security successful is easing the process of change. Ask people for help and ask people to observe what they do. Listen to the answers and reflect on what you learn. Learning from others is often the key difference between success and failure.
