1:1 with Lena Reinhard, Vice President of Product Engineering at CircleCI

For our series, 1:1 with Engineering Leaders, Code Climate and Codecademy for Business are speaking to managers and VPs about their career journey, leadership strategies, and advice for the next generation of engineers. Check out our previous interviews with Tara Ellis, Manager, UI Engineering at Netflix, Brooks Swinnerton, Senior Engineering Manager at GitHub, and Gergely Nemeth, Group Engineering Manager at Intuit.

Below is an excerpt from our conversation with Lena Reinhard, Vice President of Product Engineering at CircleCI, who shared her thoughts on leadership, running distributed teams, and helping team members level up. Edited for length and clarity.

For Lena’s advice for early-career engineers, visit the Codecademy blog.

Tell us about your current role and how you got to where you are.

Lena Reinhard, Vice President of Product Engineering, CircleCI: I’m VP of Product Engineering with CircleCI. I joined CircleCI in June, 2018, so I’ve been here for two years and a quarter. I initially joined as Director of Engineering to help scale the organization, and then formally moved into this role in March this year.

I lead a globally distributed team, and the biggest part of my work is making sure that everyone in the organization understands our strategy direction, where we’re looking to go, and that they have the context that they need.

I noticed your personal website showcases some of your creative hobbies, so I’m curious, how do you blend the creative and the technical sides of your interests? Is there a creative side to engineering? To leadership?

I am not an engineer myself, that’s one thing probably worth highlighting. I have dabbled in engineering, but I am not as good as even our more junior engineers on the team, and it’s also not my main job. Of course there’s a lot technical about my work, and a there’s a lot that’s about the business side of things, but at the same time, as you mention, I do have that urge to be creative and live out those things.

To me, it’s more about what being creative actually means. A lot of my job is about being imaginative and using that imagination to solve problems. There’s a lot of really interesting problems to solve, and to solve at scale. I also have to be imaginative about not only what we’re seeing today, but also what’s to come: How’s the organization going to evolve? What does that mean for our business overall, for the people on our teams? So I use a lot of creativity to approach problem-solving.

I make time every day for strategic thinking. I usually start my day with that, doing some free-form writing, then working through a few questions that I answer every day around how the organization is doing, and what I need to pay more attention to.

A big part of my role is also about imagining the organization we want to be and helping people understand that. And then I work with my team to determine how we’re going to get there.

Can you talk a little bit about how you came to be a manager? Where did you start, and then at what point did you start managing people? And did you know that you always wanted to do that?

I have always gravitated towards leadership. I used to lead projects in school, and in the sports that I did, I was the captain of the team. But I never thought I would be a manager. I wouldn’t have known what the role would entail, and what that actually would mean, I would’ve thought it meant bossing people around all day because of the kinds of things you see in movies.

Early on, I started by mentoring some people and coaching trainees at one of my first jobs, then I moved towards growing and managing open-source communities, and slowly gravitated towards more formal leadership roles. I ended up co-founding a company and becoming a CEO there, and with that it became a bit more formalized. From there I moved onto building engineering teams.

I built skills around managing people, so things like project management, how to work with people, dealing with conflict, setting direction, and those kinds of things. I developed those skills through other roles, and so I had kind of accumulated important skills and traits by the time I actually moved into a management role. It wasn’t a career goal, but I’m really glad I ended up there.

That seems to be a common theme. People tend to not know what managers do, or don’t trust them.

I think I’ve learned the most about being a manager from the worst managers I’ve had. Having talked to many managers about this, it also seems to be a bit of a common trait. The actual training is not really formalized, and there’s not necessarily been a lot of role models.

I also think there’s been a big shift in management’s role, even just over the last five years, let alone the last 10 or 20. My understanding of how management works and what makes a good manager has changed dramatically from where I am now versus the first Hollywood movies I saw with managers yelling at people.

What do you believe is the role of a manager on an engineering team, if their role isn’t to be the most senior technical expert? And then, what’s the role of a leader, and what’s the difference between the two?

Management is a role, it’s a function, and it comes with a certain set of responsibilities and accountability. I personally treat it very distinctly from leadership, because leadership in itself is a very distinct skill. It’s a way of behaving yourself, conducting yourself in the world, and it’s also about how you interact with others. Ideally managers are leaders, but not all leaders need to be managers. I often tell my teams, because we’re a globally distributed team, I believe we need leadership at all levels. We have a career growth framework for engineers where leadership skills are a trait that’s required of more junior engineers, up to being very senior, because I think it’s a fundamental element of what we need to carry the organization forward as a distributed team. The more people are connected with what we’re looking to do, the more they can understand that purpose and rally the rest of the team, the better for us. That’s why I encourage people to build out leadership skills, no matter what role they’re in.

I also think that it’s important for engineers specifically to be able to grow their careers without having to move into management. I view management and engineering as two distinctly different career paths, and I’m very happy to support people switching back and forth between them — we’ve had that multiple times in my current organization and it’s been really great — but it shouldn’t be that in order to move forward and progress in your career you have to become a manager. I think it sets people up for failure, worse case, and it sets them up for doing work that they don’t want to do because it’s just not everyone’s cup of tea. I like my job, but I also know not everyone wants it.

Managers are ultimately responsible and accountable for the business success of our teams. We have to focus on connection, communication, and collaboration on teams. There’s a lot of research, of course, on high-performing teams and what those teams need to be successful, but basically it’s about supporting teams in growing and becoming cohesive, helping engineers on the team grow, and helping teams deliver against the business’s goals. And then it’s everything that goes into that, because that’s, surprisingly, a lot of work.

What are your biggest challenges as a leader?

The one thing I keep saying is just scale. I lead an engineering organization at a hyper-growth company. We’ve been in a state like that for a couple of years now, and it impacts us in a variety of ways. It impacts us from an organizational perspective, since we want to make sure we’re appropriately supporting the people who we already have in the organization, as well as the ones that we’re looking to bring on in the future. And so that’s related to our processes and how we hire and onboard, and how we support career growth.

The other side of it is of course the technical side, making sure that our systems are set up to support the user base that we have, as well as the user base that we’re striving to have in the future.

So scale is definitely a big thing because it comes with a lot of change. It basically means being in a state of continuous change, always evolving and always adjusting how we operate as a team. Within that, I also have to maintain a good sense of what’s going on, since I’m relatively removed from a lot of other leaders in our organization.

With the growth that we’re going through, I also think a lot about scaling culture. We want to maintain parts of our culture, but then also constantly adapt in a way that’s healthy and that’s aligned with our values. Because I also don’t believe that trying to preserve the culture that you had as an organization when you were 20 people should be the goal.

We also have to make sure that we are always working on the most impactful thing for our customers, as well as for our organization. In a state of hyper growth, it’s easy to get into an “everything is important and urgent” mode, and it’s a challenge to work through that, for myself but also for my team, making sure that they know the priorities and that they’re able to shift their work accordingly.

I also put a lot of work into managing my reports, my staff, and my peers, and then of course upwards and then around into other parts of the company. That’s probably one of the biggest parts of my job.

Are any of these challenges remote-specific? You mentioned you’re a globally distributed team, so how does that complicate things for you?

It complicates everything. I love it, and I always feel like I need to add that as a disclaimer. I’m a big fan of distributed teams, but it also means we have to be more mindful of how we work. We have to be a bit more intentional, because stuff just doesn’t happen organically. My remote-specific challenges are mostly around time zones. I fortunately have an assistant who helps with the logistics of global distribution, which has been great, but that’s more the day-to-day.

The other big challenge is everything around change management and cascading communication. In a co-located team, at least up until the end of last year I guess, people could easily summon everyone into a room and say, “Well, here’s the change and here’s what’s happening,” and then everyone gets on with their day. That’s of course a very simplified example, but for us, anything that we’re looking to change usually requires quite careful planning.

Especially in a constantly evolving environment, we also have to be mindful that there are limitations to how much change an organization can digest at any point in time. We try to be strategic about where we think we can evolve to a desired status quo, versus where we actually need to change something.

This is a very broad question, but how do you drive high performance on your team, and how does that change if you’re working with an individual or the team as a whole?

There are a couple different frameworks. One is a career growth framework that we use for goal-setting and expectation-setting conversations on a quarterly basis, and then we do check-ins again over time. We also use that as a basis for 360 feedback and career growth conversations for the longer term. So that’s one pillar, which is more towards the individual.

At the team level, we do OKR-setting as a goal framework, also on a quarterly basis. Though we don’t use OKRs at the individual level, we do try to align individual goals towards the team’s OKRs. So, for example, if a team has goals around delivering on a specific service and someone on their team wants to get better at knowledge management, they might work on documentation around that specific service, or make sure that they’re onboarding someone new to that area.

We try to connect the individual’s career goals with what the team is actively working on. It helps create opportunities for people to work on their career goals in the short term, rather than pushing that down the line.

We also use a lot of other practices from DevOps around high-performing teams and DevOps culture. So things like retrospectives. Check-ins on the team side are really important as well. Teams need to connect and build relationships and focus on learning continuously together.

We also have an internal mentoring program, and have expectations in the career growth framework around learning to be a mentor or mentee.

Do you use engineering metrics at all on your team?

Yeah. We make a CI/CD product, it would be a shame if we didn’t.

That’s very true. Can you elaborate a little more on how you use them, and how that works on your team?

We have been moving towards using more and more metrics over time. For me, that’s just been a part of maturing as an organization. I also think it’s a natural side effect of growing to a point where not everyone knows what’s going on everywhere at all times anymore. Plus, I also think part of maturing is about evolving our practices, and measuring what matters is a good industry practice. It’s probably one of the better ones. So yeah, we’ve been gradually quantifying much more.

We use OKRs. We are also building out technical backlogs for the teams with technical initiatives with measurable impact. We utilize different delivery metrics and engineering metrics, including the standard DevOps metrics set, as well as others around team health, and services health. It’s a relatively broad set, and I would also say it keeps evolving. We use them, in addition to them being good practice, because we’re evolving as an organization.

They’ve become an increasingly important factor in measuring team health and the overall health of the organization, because it helps us understand how teams are doing against their goals. But also, for example, we measure how the teams are investing their capacity across new features, escalations, and technical debt and maintenance. It helps us plan. It also helps from a staffing perspective, knowing if teams are in need of more support.

So yeah, metrics are a good tool for both spot-checks on the current state, as well as for planning. It helps in terms of understanding how long work is out, how well we’re doing on estimating our ability to deliver, how long things are going to take, those kinds of things.

What advice do you have for new managers, or for people who are looking to change their career path and become a manager?

I’d say learn a lot and try to constantly level up. Like I read different newsletters, I read books. Books on management and all facets of it. I’ve also been working with career coaches for many years. I’d say, it’s more of a pull situation than a push situation. People aren’t necessarily going to give a lot of support, and in many organizations there’s no structured growth frameworks. So finding ways to level up is really important.

Investing in building relationships is also really crucial, especially in distributed teams. Make sure to build connections with important stakeholders, and of course with the team that you’re leading as well. But the relationships are going to be the main currency that helps a manager be successful.

One point that I’ve coached a lot of engineers through has been recalibrating internal success measures, and what makes them feel accomplished. For me at least, being successful in my role is helping others succeed, but also that’s very different from pushing code to production once a day. In many cases the results take much longer, especially when you work at the organizational level; initiatives take a long time, things I work on may never actually come true. So finding ways to feel successful and to get a sense of accomplishment, especially when you’ve moved from an engineer role into management, is really important.

I have, in the past with people who I’ve coached with, I’ve basically pursued two angles. One is basically just being conscious of that happening and understanding that it’s a common feeling in such a career transition, but also setting clear goals and expectations, both for your own work and for the people who are reporting to you. And then it’s also about connecting with what motivated you to move into a management role — what are the things that made it attractive for you, and how can you get more of that?

The other main thing for such a transition is just always making sure you’re very clear on expectations and goals. You have to know what’s expected and what the business goals are, as well as be clear with people who reporting to you. So much of management going wrong is just expectations that are going sideways, and that can usually more easily be prevented than fixed afterwards.

For more of Lena’s advice for the next generation, visit the Codecademy blog.