Adam Berman is an engineering director at r2c. In this role, he focuses on developing new products to help security teams work hand-in-hand with developers and scale their security programs. Previous to r2c, Adam led the engineering team for Meraki Insight at Cisco Meraki, using ML and AI techniques to identify and solve performance problems in networked applications. Adam holds an MS in Computer Science from the Georgia Institute of Technology and a BA in Philosophy from Dickinson College.
Exaltitude newsletter is packed with advice for navigating your engineering career journey successfully. Sign up to stay tuned!
Leadership is a skill separate from managing people. Leadership is setting an example, putting forth a compelling vision, defining culture, and motivating and helping those around you. I take a lot of inspiration from Charity Majors - she was in a leadership role at Facebook and now is the CEO of Honeycomb. She has a blog called Charity.wtf that I constantly send to people for advice on engineering leadership. She talks about something called the engineering pendulum, where instead of just going up the ladder, you move back and forth between IC and management as new opportunities arise. This mix of hands-on and people management makes great leaders, no matter their current role. Great managers are influenced by their experience as hands-on developers, and great developers are influenced by their experience leading teams and thinking about the people on those teams. This path might seem non-traditional, but it’s been really rewarding for me, and I think it produces really well rounded leaders.
One of the biggest differences is that as you get more senior on the IC track, it becomes less clear what is expected of you because that changes from company to company. It’s your job to figure out how to be influential, because going up the IC ladder doesn’t give you more authority, just more expected impact. Will Larson does a great job of laying out different ways to be influential in his book Staff Engineer, but at the end of the day, it’s up to every senior IC to figure out their own recipe.
But there’s a lot of overlap in what it means to be an IC leader and a people manager. Both roles are responsible for the culture, for the health of the technical organization, and for making sure that an organization meets its business outcomes. Both roles require taking on quite a bit of what Tanya Reilly calls glue work in order to be successful. Perhaps IC leaders are more responsible for the technical vision and people managers are more responsible for the strategy around growing and structuring the org. But I think managers and ICs are best off when they trust each other and collaborate on both technical and people strategy. A lot of the greatest frictions that arise in a technical organization are when decisions are made about technical strategy or people strategy without thinking about the implications that decision will have on the other strategy.
There were some parts of being a manager that I really loved: working with the team to figure out the mission, getting everyone aligned on our goals, and mentoring folks and helping them grow. But there were other parts of management that I found challenging and exhausting: hiring, firing, and promotions, especially within a big company. Reading Will Larson's Staff Engineering, talking to folks in the Rands Leadership Slack, and chatting with my current CTO, I realized that what I was looking for was a staff engineering role. In this role, I still get to do the parts of management that I love: helping figure out the mission, getting people aligned around it, and figuring out how to achieve our goals. And the second component, instead of people management, has me actually building the product directly and working on our long term product and technical strategy.
I was certainly afraid of making this transition. I was worried that I might have forgotten how to be an effective engineer, or that people would see it as a demotion, or that people would figure out I was an imposter. Eventually I realized that I was always going to feel imposter syndrome, and that fear of a new role was a good sign, because it meant I was going to try something challenging. I’ve really enjoyed the transition back to being an IC, though I’m excited about the next pendulum swing I’m on right now, taking me back to management.
Totally, I think anyone interested in being an engineering manager should try it. Even if you transition into being a manager and realize it's not for you and come back to being an IC, you have gained a lot of useful skills from the experience like running a meeting effectively, prioritizing, giving feedback, leading major initiatives, and understanding people’s desires. It’s just a great shift of perspective, forcing you to look through a broader lens. As a manager, I had to think about what my director needed from me, how the team was functioning, how we were executing against our long-term roadmap. It forced me to zoom out and think less about the details of any single project. When I went back to being an IC, I kept that perspective. Even as I went back to working on specific projects, I could more easily put my work in the context of the broader organization.
I think the worst managers often lead through authority, giving commands, micro-managing, just “making” people do things. The best managers lead through influence. By doing the pre-work to understand people’s needs, to articulate a compelling vision, to get buy-in. I feel like the interesting part of this, and I keep on coming back to this, is that this means the best leaders are great no matter whether or not they have the authority of management.
The best managers I’ve had or seen also had a few other skills. Great managers care about people management first, which means that they care more about the people on their teams than the technology. However, one of the ways a great manager shows they care is by treating their direct reports as adults and setting clear expectations. They give feedback readily and expect folks to be able to hear it and grow. Great managers challenge their team to achieve great things, things their team isn’t always sure they can do, and then help their team meet those challenges.
Everyone can be a leader, no matter the role, and there is no single path for success. Each career decision you make, each change of role or company, will color the way you look at the world in a new and valuable way. When I moved to be a manager, I shifted my mindset from technical implementation to thinking about the long term and roadmap, how things fit together, and other people-based issues like team culture, compensation, and hiring. Having these tasks be my first class priority reminded me that team health and culture have a considerable impact on producing the technical, day-to-day deliverables. Sometimes we take those things for granted, but we need to realize that getting those aspects of work to fall into place requires an intentional effort and shouldn’t be seen as second to technical tasks. Everyone at the company, whether an IC or manager, is responsible for the culture and health of the organization.
My undergraduate degree is in philosophy, but after graduating I quickly discovered that I wanted to be an engineer, so I attended and graduated from a bootcamp in 2014 and joined Meraki, which had recently been acquired by Cisco. At Meraki, I built a new product from scratch with a few other engineers called Meraki Insight and moved from tech lead to a management role as the team got bigger. Afterward, it was clear that I wanted to move back into the IC role, and I was excited about joining a startup. I took a staff engineering role at r2c, a startup focused on profoundly improving software security by building tools to help engineers secure their code. In the last few weeks, I moved into an engineering director position to start building a brand new product.
Exaltitude newsletter is packed with advice for navigating your engineering career journey successfully. Sign up to stay tuned!
.png)
.png)
.png)
