Drew Wigodsky

Don't ever forget the individuals you meet and teams you form along the way. I was part of a team at Rainier that still interacts 25 years later, even if the company hasn't existed for over two decades (sold to Compaq/HP). Years later at HP, I got flown in at the beginning of selling a $3b outsourcing deal that literally redefined our industry. The lawyer across the table saw my Rainier shirt and instantly knew what I came from. I shared lunch with a co-leader of our team yesterday; we still talk about things we learned 25 years ago and how they apply today. I caught up with three or four last month, and at least ten this year. Good teams last long after expiration: ask old techies in MN/IA/NE about Rainier. I'm keeping that shirt 4ever.

I like that the prompt here says anyone. I really wish it said “everyone”. We've seen progress here. 30 years ago, not even 5% of IT could describe the key elements of cybersecurity. Today, it’s over 25% -- given a bit of time to check in their favorite LLM or search engine. That’s OK. You do not have to be a security expert to be an expert voice in a security conversation. Security has more than one perspective: sometimes it's the perspective of the security expert, the application expert, or the business expert. Each role has something meaningful to say about security. Each of these people might get called on during an incident. Each of these people probably knows some part of what remains unsaid at the end of the conversation.

It's not just about SQL and Python and AI/ML. You don't need to be a data scientist to use data. It's equally about tools like statistics and Excel and your favorite BI or visualization framework. We've only scratched the surface of data-oriented job functions, but every one seems to start with the basics: plotting time-series data and using that knowledge to create or optimize something. I find the best path to understanding data is knowing how it is actually useful. I'd recommend most data scientists serve first as business or process analysts. It is far too easy to get caught up in tools like the "model of the day" while forgetting that the tool needs to actually do something someone considers useful.

I wasn't qualified for every job in 30+ years. Often, I was half-qualified. That goes a long way, if you are open to constant learning. For me, I started as a software developer. I was getting geeky about early AI in '95 when someone needed two LDAPs combined, so I started to become what is now an Identity expert. First consulting client needed a firewall, so I learned vulnerability. The next 10 years I coded and configured my way to millions of desktops. Ten years later, I spent a decade as an enterprise architect. Somewhere along that way my employer found me good at GRC. After that, I spent a 15 years back in security and GRC, ending as a CSO. Now I lead a company doing all those things. I still have bleeding edge skills. #flexible

Learn something EVERY day. I subscribed to the MSDN (dev) in 1992 so I could regularly read every article. I have Beta CDs dating back almost that far; I installed at least half of the products just to play and learn. TechNet (IT) followed not long after that, and I turned installing and upgrading software into lessons. None of these resources exist anymore, but my practices and habits are still foundationally aligned with timely information applied ASAP. Those tools started a lifelong habit of setting monthly goals for learning. IS changes every day. Now I spend more time on LinkedIn and YouTube, but the goal is the same: find wisdom through exploring, learning, testing, applying, breaking, adapting, optimizing and re-imagining my skills.

AI needs to take lessons from other broadly applicable domains in technology, particularly identity and access governance. 20 years ago, about half of identity projects failed. Today, about half of them still fail. Most fails: scope, skills or comms. Things to watch out for: - Lack of top-down or bottom-up support -- NEED both - Focusing more on problems than solutions - Taking on too much work or too fast - Product leaders that are too technical or not technical enough - Broken communication channels due to disruptive nature of projects - Projects that have more vendor requirements than business ones - Governance and standards that lack flexibility - Rigid architectures or processes - Insufficient time for people to build and test skills