Anthony Barbieri - Principal Security Architect at Grainger

Anthony Barbieri: Twitter, Polywork, Github, Dev.to 

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 am currently a Principal Security Architect at Grainger, an industrial supply and equipment provider. I am currently responsible for guiding our cloud security efforts, partnering with internal platform teams to build security into their offerings, and IAM initiatives relating to our customers.

The role is a combination of both enterprise architecture and solution architecture. On the enterprise architecture side this includes helping define strategy, set standards, and drive alignment across the organization. In the solution architecture space it involves helping support key cross cutting initiatives, ensuring requirements are met as part of designs, and helping teams to threat model and improve the overall security posture of their solutions. Since the team does not have operational or engineering delivery responsibility, goals are usually tied to definition/adoption of standards, and the delivery of key strategy or alignment artifacts like conceptual architecture diagrams.

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

My day to day schedule can vary greatly. A typical day might include any of the following: consulting with teams on their solutions to ensure security controls are being met, developing required security baselines for an emerging cloud service or technology, formal risk reviews of proposed solutions, helping align multiple teams on a larger technological vision, identifying and designing improved guardrails that can be added to our internal platforms, helping to evaluate tooling during POCs, supporting incident response questions related to the cloud, and a variety of other “glue” work. There is a mix of working with teams both inside and outside of the security organization.

You first got the title Staff engineer at Cigna. What was the process of getting promoted to Staff? (e.g Did you have a staff project? Did you have to put together a promotion packet?)

The staff engineer roles at Cigna were part of a group called the IT Principal Program. Similarly our staff engineers were known as IT Principals, Senior IT Principals, and Distinguished Engineers.

In order to be accepted into the program, I did have to put together a promotion packet. This packet outlined various projects/efforts I was involved in and how they benefited the organization. While putting the packet together, a current member of the program helped guide me through the process. After the packet was submitted, there was also a panel component where current members were asked to assess if I was a good fit for the program.

While we did not have a formal requirement for a “staff project,” most folks accepted into the program were usually part of high impact initiatives. In my case, I got involved in the ground floor of Cigna’s move to the public cloud. As a cloud security engineer at the time I helped establish foundational guard rails, review processes, and security automation to help us manage workloads at scale as more and more teams moved into the cloud. Although I formally reported to the security organization, I was deeply embedded in the cross functional team that owned and operated our cloud platform.

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?

The most important factors that helped me reach Staff were networking, reliability, and empathy. By building a network across our technical organization I was able to drive change well outside of my direct team. Security teams will always be smaller than the full roster of development teams, so it helped to accept early on that I could not do it alone.

In terms of reliability, earning and keeping the trust of those partners helped when I asked them to take a chance on a new approach that might be a little out of their comfort zone.

Similarly, empathizing with development teams and meeting them where they are helped me design solutions that fit their operating model. This often helped reduce and/or eliminate the friction of the control I was trying to implement.

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

I feel most impactful when something I’ve worked on becomes self-sustaining. If a control or guardrail can help avoid a common security issue while educating the user on the right path, it helps free up time for deeper partnerships on complex issues. While at Cigna I led development of a rule library (which we eventually open sourced here: Confectionery) for enforcing best practices when using Terraform for AWS (and a bit of Azure).

Tools like this helped catch common issues where a role might be overly permissive, or encryption of storage might not have been enabled. This freed up more of my time when meeting with teams to dig deeper on their use case and focus on new services and technologies to capture best practices. These in turn would then become rules in the library.

An “innersourcing” model was used for the library, so anyone could propose a new rule or modification to an existing one. The policy library was also versioned and had an exception mechanism which helped avoid unexpected disruptions and false positives. The repository included positive and negative test cases to ensure updates did not change the outcome of the policy evaluations. Initiatives like this helped scale my impact, by removing the requirement that I be present. By “removing myself from the equation”, teams were able to move faster, while also being more secure.

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?

While a title can initially get you a spot in the room for certain conversations, your actions and ability to drive needed change are more important in earning trust with your leadership and your partners across the organization. I was exhibiting the behaviors of a Staff-plus engineer before I formally had the title.

So in short, I don’t believe the title should be a means of gatekeeping. I worked with many brilliant engineers that might not be at Staff level yet and helped champion their ideas if it was the right direction forward.

What Staff Engineer archetype do you consider yourself? Why?

In my current role I find myself mostly acting as an architect and solver, with some occasional right hand responsibilities. While I set strategic direction in a few areas, I regularly get “air-dropped” into various initiatives to help the involved teams succeed and find a path forward.

For example, when log4j happened I coordinated an effort to help identify our exposure across all our container images. We were able to get insight within a day or two.

I’ve also assisted with M&A efforts when determining how to bring the subsidiaries’ cloud instances into standard without being overly disruptive. I enjoy the problem solving aspects of the solver, but the architect responsibilities also present another way to problem solve beyond a purely technical implementation.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

During my last year at Cigna I managed a small team of engineers. While I’m glad I had the experience, I felt like I was not done growing as an individual contributor. Therefore when joining Grainger I decided to switch back out of management in order to gain additional breadth of knowledge in other areas.

I’m not sure I’ll ever be done growing, since I’m naturally curious and love to problem solve, but I wouldn’t say that I’ve closed the door on ever going back to management. It’s great to enable others to succeed as a manager. However being able to dig in and tackle a complex problem with others is extremely rewarding too. I really enjoy the variety of initiatives I am involved in, and as you progress up the Staff Engineer ladder the scope only gets larger with increasingly challenging problems. So I’ll probably find myself continuing down that road toward something like a Distinguished Engineer role.

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

At both Cigna and Grainger there are early career programs for employees that just graduated college. At Cigna the program is called the Technology Early Career Develop program or TECDP. The program allowed members to rotate between different roles before formally “posting out” to a role. I came through the program but ended up staying within security the whole time as part of an “area of focus” initiative they had within the program. While I was in the program I benefited from a number of mentors supporting my growth. Therefore during my time at both companies I’ve served as a mentor to members of the programs. It was great to learn about their career goals and connect them with the right folks across the organization, or recommend a particular resource to learn more about a topic.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

Books

• Team Topologies

• Nudge

• Devops Handbook

• The Art of Leadership

Role Models

• Kelsey Hightower

• Lesley Carhart

• Rachel Tobac

What about advice for someone who has just started as a Staff-plus engineer?

Learn how your business makes money. It will help inform why systems and teams operate in the way they do, and why they may push back on certain changes.

Understand your management’s goals so you can remain aligned with their vision.

Your voice carries more weight now, but good ideas can come from anywhere. Make sure to leave room for others in conversations. If you’re amplifying someone else’s idea make sure they get the credit.

As a Staff-plus Security Engineer you will likely be asked to represent your security organizations viewpoint in various meetings. Make sure you are aligned with the wider management team to ensure you correctly represent their stances.

Consider who you can partner with in other parts of the wider organization, and start building trust and a relationship with them.

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

Yes. I recently partnered with a member of our product architecture team to help set the vision for how we modernize our customer identity and access management approach. This involved ensuring everyone understood the different terms and concepts, creating diagrams to explain how the different components would interact, ensuring alignment on what certain terms ment, and explaining the why behind the approach we were taking. We also socialized the approach with the wider organization. These efforts helped guide the company’s decision making as we considered the right combination of tools to support the vision.