Lea Snyder - Principal Security Engineer at Microsoft

Lea Snyder: Twitter, Mastodon, LinkedIn 

Tell us a little about your current role: where do you work, your title and generally the sort of work you and your team do.

I’m on the Internal Security team for Identity and Network Access (IDNA), also known as the Microsoft Entra Team (Microsoft Entra - Secure Identities and Access / Microsoft Security). My team secures IDNA products, systems, operations, associated data, and users. We work with teams that build both internal and external products and services. Another way to think about what we do is that we protect the IDNA stack from evolving threats and global actors via multi-disciplinary efforts across Security Engineering, Software Engineering, and Technical Program Management.

We partner and collaborate with security teams across the company to turn our mission into reality. Specifically, I work on the Infrastructure & Security Operations team which focuses on creating a secure operational environment. I was hired to build a program to run security drills to ensure services teams can respond to a breach and resume normal operations by validating capabilities and artifacts through controlled simulations. I also work with our Detections team on strategy and overall approach, as well as the Product Security team on specific deliverables. I also work on the Internal Security strategy and executive communications, including things like how we define our work.

How do you spend your time day-to-day?

I’m still rather new to my role and I’m still learning what my role entails so it’s hard to compare to other Principal engineers at my company.

I’ll be honest, I spend a lot of time in meetings. In addition to normal meetings (1:1s, team meetings, v-team meetings, project work meetings, and cross-org security sync ups), I attend meetings focused on Detection, Response, and Product Security workstreams. It’s really important for me to understand what’s going on in my organization, what work we’re prioritizing, and where we are blocked so I can find opportunities to assist. Also, I participate in large company-wide efforts to address security concerns. I often do document reviews, as asking the right questions can add a lot of value. I even wrote up a tips & tricks document for my team on how to approach documents based on my observations from both asynchronous and synchronous doc reviews.

I spend a decent amount of time mentoring, since investing in others by giving them professional support and coaching helps them achieve their full potential within the company. Additionally, mentoring helps me gain new perspectives and helps me become a better leader. I also mentor folks from underrepresented groups already in security and those trying to break into security.

When I’m not in meetings or mentoring sessions, I’m doing deep work on solving complex, ambiguous security problems.

You moved back into a Principal engineer title when you joined Microsoft. Can you talk a little about the process for finding that role? How did you decide to pursue this path, especially in light of your previous experience in engineering management roles?

There are a lot of paths to being a technical leader. I actually interviewed for both Principal Individual Contributor (IC) roles and Director roles when I was last exploring options. One of the nice things is I don’t think there’s a one-way door with career decisions. I’m a Principal IC but I could easily pivot back to a management role. I love interviewing as it can highlight growth opportunities that may be hard to spot otherwise.

For example, I realized after an interview I did not know that much about Container Security. After the interview concluded, I researched the best books on Container Security, purchased one, and promptly read it cover to cover. This allowed me to be more confident in future interviews and gave me an opportunity to spend some time diving deep into a technical area. It was through this activity I realized I really missed having the opportunity to dive deep into a technical domain.

As for my current role, I had previously talked with a Microsoft recruiter. At that time, I wasn’t interested in exploring opportunities at Microsoft, but I took the time to establish and maintain the relationship. This allowed me to reach out when I was ready to explore opportunities. I always recommend establishing and maintaining relationships with recruiters — you just never know what the future holds. The appeal of the Principal IC role was getting to work on the strategy for complex, ambiguous security problems that haven’t been solved and having more opportunities to continue to expand my technical breadth.

How do you decide between growing as an IC or moving into management?

I often get people who come to me to ask how to decide if they should go into management or keep going as an IC. I consider myself lucky getting to explore a lot of different paths and being able to move back and forth all while staying a technical leader.

A lot of people express that they think management is a quicker path to achieving their goals, mostly in terms of level. I cannot stress this enough: they are very different roles. There’s no right path, but decide how you want to grow and go after that.

If this is something you find yourself struggling with, ask people what they love about their jobs and ask what they don’t love. I think seeing which items resonate more with you (or which things you would like to avoid) may help decide which path to pursue.

However, sometimes you can’t tell what you’ll think of something until you try it, so if you can try before you buy, if you will, I do recommend that. A common way to do this is to manage summer intern(s) or manage contractor(s).

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

I think my willingness to network has really benefited me and opened doors that were important to reaching Principal.

I’ll admit I was reluctant to network, and to a point I still am. However, I found a way that worked for me – I volunteered at local security conferences and quickly joined the organizing committees. I’ve been on the organizing committees of BSides Boston, BSides Seattle, Layer8, and The Diana Initiative. I’ve also volunteered at other conferences (AppSec Village @DEFCON, Day of Shecurity, etc.) These experiences allowed me to meet other security pros but reduced the awkwardness of having to introduce myself to strangers. My network has been instrumental in every corporate role I’ve landed. I simply would not have gotten into the door at a lot of the companies where I have worked without my network.

I think actively honing my leadership skills has been critical to me achieving Principal. I find that people who are trying to get to the next level often focus on technical depth, when they should instead focus on expanding their technical breadth and gaining leadership skills. There are a ton of leadership skills, and you don’t have to excel at all of them, but you need to show that you are the kind of person that others want to follow (or another way to think about this is influencing without authority). I talked about the importance of negotiating as a leadership skill at TDI 2022 in case that’s of any interest.

I have a BA in Economics and an MBA. I worked at the student IT help desk in college and have always been interested in technology, but much of my learning came from self-directed learning (and breaking things). That being said, I think the MBA has opened doors. At the very least it allowed hiring managers to feel OK about taking a risk on me. I’m lucky to live in Seattle, which is a large tech market, but I’m not sure how much location will matter in the future.

I do think the companies I’ve joined have had an impact on my career path. At Akamai, I was expected to dive deep into infrastructure but also had the freedom to explore security. When I left Akamai, I joined Amazon. Amazon, and specifically the Technical Program Manager (TPM) role, really helped propel my career. The TPM role requires a type of finesse that pushes you to gain leadership skills quickly as so much of your success comes down to influencing without authority. I credit much of my leadership skills to the time I spent at Amazon and the different roles I had while there – TPM, Security Engineer, Privacy Engineer, and Security Engineering Manager.

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

I think my impact as a Principal Engineer is greatest when I can help drive alignment and clarity.

For example, I was asked to put together a virtual hub for my organization, a place where you could go to get updates, learn more about the individual teams and what they do, as well as review FAQs and documentation. I had complete control over what was highlighted, which was a lot of fun as I could promote work being done across the organization that folks may not be aware of and really champion the work of my teammates. Once I put the hub together and shared it broadly—both inside and outside the organization—it was easy to understand the massive scaling impact of what felt like a simple thing. As a Principal Engineer, I’m in a great position to have an impact by driving alignment and setting the stage for my team to excel and be recognized.

Sometimes it can be hard to be objective about the impact you are having. I find it helpful to request feedback. I recently reached out to an engineering manager on a partner security team and his feedback really helped me understand how much of an impact I was having on large cross-organization efforts.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

Not really. In many ways I work on the same types of things I’ve always worked on – ambiguous, complex, and unsolved security problems. These are the types of things I enjoy working on and tend to excel at, so I think even when I wasn’t a staff+ engineer, my managers were willing to let me work on them once I made the case. I think the difference is now I am invited into the room when previously I would have to really push to get into the room. I also just get assigned the hard problems versus having to prove that I can solve them. In many ways, it’s just easier for me to get to do the kind of work I want to do.

What Staff Engineer archetype do you consider yourself? Why?

My hunch is at some point we rotate through all archetypes depending on the situation.

I’ve been a Tech Lead in the past. In my current role, I primarily consider myself a “Solver” but my suspicion is if I asked my leadership, they would also say “Right Hand.” I love solving problems and unblocking others so they can solve problems. I’m quite happy to spend months digging into the data and historical context to understand the best path forward with the highest likelihood of success.

I tend to have my primary problem I’m working on while being assigned random hotspots as well, which is why having technical breadth has been critical to my success and ability to work on so many different things.

What would be your advice for someone who has just started as a Staff-plus engineer?

I have three pieces of advice:

1. Listen. Ask questions. Don’t rush to give advice or solve problems for engineers on your team. For example, let’s say an engineer wants to discuss how to eradicate vulnerabilities at scale. I have plenty of thoughts on how to do this but my role as a Principal Engineer isn’t to give the engineer an answer, it’s to coach them on how to get to the right answer. For this reason, I will primarily spend my time listening to their proposed solution (or reviewing it on a whiteboard) and then start asking questions. The purpose of the questions is to make sure the engineer can close any gaps in the approach and have answers for all possible questions (or as many as possible). My last question is always focused on how I can help them going forward.

2. Be OK with not doing technical things all the time. For example, one minute you’ll be rethinking your organization’s approach to security risk assessments and then in the next, working on executive communications. As a staff+ engineer you probably have a lot of unique skills, and you should expect that leadership will leverage them for whatever your organization needs at that time. You need to remember that you will have an impact no matter what you are doing and just embrace that. If in doubt, ask for feedback.

3. Ask for help. Let’s be real, we all need help from time to time. You don’t have to have all the answers, nor does anyone expect you to. I often ask for help getting connected to people who I don’t know or ask for help from peers who I know will have a different perspective than mine when I’m working on solving problems (helps me ensure I don’t have on blinders). I also still seek out sponsors to help promote my work.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role? We’d love to hear a story.

I honestly did this before I became a Principal and I think it’s important to do no matter what stage you are in your career if you can. I wouldn’t be where I am if folks hadn’t sponsored me. I love helping people grow and I appreciate that I can continue to do this work even after giving up my manager role. I often find myself working on unfunded work (meaning I’m the only resource) and often have had more junior engineers ask to work with me. Recently I heard from one such engineer, who I had both mentored and sponsored, who let me know he had gotten promoted. He shared that he felt it wouldn’t have been possible without my support, which meant a lot. It also reminded me to thank people who are helping me on my continued journey.

Do you spend time advocating for technology, practice, process or architectural change? Can you share a story of influencing an organization?

Recently, I’ve been spending time advocating for processes so we can build a better security practice. For example, when I joined my organization, I quickly discovered one of the main issues is we didn’t have a common language when referring to security vulnerabilities, which made data analysis next to impossible. We needed a taxonomy to drive standardization, however, work on this effort hadn’t been properly prioritized. I made the case for why prioritizing this work was important to many different efforts that were already running and how this work would pay off in the long run as we continued to grow. I drove the workstream to develop and deliver a vulnerability taxonomy with detailed descriptions in a compressed timeframe. All teams now use this taxonomy to document security vulnerabilities, making data analysis much simpler.