1:1 with Andrew Heine, Engineering Manager at Figma [Interview]

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, Gergely Nemeth, Group Engineering Manager at Intuit, Lena Reinhard, VP of Product Engineering at CircleCI, Mathias Meyer, Engineering Leadership Coach, and Anchal Dube, Senior Engineering Manager at Zocdoc.

Below is an excerpt from our conversation with Andrew Heine, Engineering Manager at Figma. Andrew shared his thoughts on setting learning goals, finding opportunities to take on management responsibilities, and the importance of getting enough sleep. Edited for length and clarity.

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

Tell us about your current role and how you got there.

My current role is Engineering Manager at Figma on the prototyping team. Prototyping is a feature in Figma where, once you’ve made your designs in the Figma editor, you can and see animations, interact with them, view them in a more focused way, and do user testing. I’ve been here just about six months. I started as an IC.

When I interviewed, I interviewed for the manager spot, which was going to open up in a few months. I came in as an IC, which was a win-win sort of situation. I was working with the VP of engineering to find the right way to get me into a role that was a good fit, and I thought it was a good bonus to be able to be an IC for a couple months. It’s pretty good if you have the chance to come into a company and understand the code and see what it’s like to be an engineer at the company. As a manager, you will get some exposure to writing code, but you’ll have way less time to do it. So it worked out well.

I had been a manager prior to this, at a company called Atrium. I had also run a startup of my own for a few years before that. That was when I stopped just being an IC. I was doing everything that needed to get done at a three-person company. It wasn’t anything like what my job is today, but I did like the kind of variety that you get as a founder, and you get a lot of that as a manager too.

That was sort of how I got started thinking about being a manager. I was like, “Hey, I’m not really just writing code anymore. Do I want to go back to mainly being a programmer, or do I want to continue to interact with different functions?” Being a manager is kind of like being the founder of a team, and you might do a variety of different things depending on what the problem of the week is.

What interested you about management? Was it that feeling that every day is something different and you have a lot of different jobs and responsibilities?

That aspect of it, and then I think it would be flawed to pursue management if you don’t have a strong interest in people and relationships. It’s valuable for any career path to invest in relationships. As a manager, you do have to really care how people are feeling. I asked myself, what kinds of problems do I want to be thinking about in the shower? What kind of problems do I want to be getting better at, and reading books about? At that time I was more interested in reading a book about management than reading a book about design patterns. I felt I had grown a lot as an engineer, and I was curious about management.

That’s a great way to think about it, can you talk a little bit about your transition from IC to manager? What was that experience like for you the first time around?

It was great because if you’re at a growing company, it’s super easy to get support in this because often times your own manager might be interested in saying, “Hey, I want to manage managers.” Not to say this is always the case, but it’s pretty common that if you see a company that’s growing a person might be managing eight people on a team and they might be aware that the next step for them is to hire their kind of ninth person or 10th person. There’s a tipping point where you really can’t have a team that’s that big. They start thinking about how to grow their own career, and they think they’ll be able to kind of scale themselves up by relying on you.

That was the case for me at Atrium, where my manager was at their limit of reports. That’s pretty common at a growing company, where there are opportunities that come up where it’s not just a new team, but your own team having to split into two.

What was it like to manage people who used to be your peers?

It’s interesting and mixed. There’s a trust that you have when people know you’ve done similar work to them. That’s a big pro. There could be potential downsides I imagine, if somebody else wanted the position, but that wasn’t the case for me.

You have to kind of feel it out. Do I walk in the next day and suddenly have more respect because I have a title? Probably not. But at the same time people do want to have a leader, and I think people are pretty encouraging, pretty supportive. And it’s nice to have your peers know how to work with you already and trust you.

What do you see as a primary role of a manager on an engineering team?

If you were managing a football team, there’s two puzzle pieces. There’s what you know you have to get done — you know you’re going to have to kick some field goals. If you don’t have a field goal kicker, you need to either hire one or train someone to do that. You also can look at the assets that you already have, look at the skills your team has, and make a playbook that that team is going to be good with. You can change your team by hiring and by training, and you can change the strategies your team uses based on the personality types and the skillsets that you have available to you. It’s about the known requirements, and being resourceful with the people who you have.

Ultimately, you’re kind of accountable for everything, even though you’re not doing much of the work. You were the person who said, “We don’t need a field goal kicker.” You could blame the quarterback for missing a field goal, but really you’re accountable for that quarterback missing the field goal.

Is there a difference between being a manager and being a leader and if so, what do you see as the difference?

There is a difference between management and leadership, but oftentimes it’s the same person. The things that I think of as my deliverables are the management aspect: coming up with a roadmap, with priorities, with a hiring plan. Things that you have to do are often management. Then the stuff that’s not really a deliverable is the leadership: How you are around the team? Are you creating a culture where people feel comfortable? Where people feel motivated? Are you building a cohesive team?

I think of management as being the deliverables and leadership as the style.

Leadership is a lot easier when you’re doing the management part well, because you don’t have a bunch of fires going on. It’s hard to be inspiring when things are falling apart.

What are the biggest challenges that you’ve faced since stepping into a management role or a leadership role?

One is time management. As a manager, you will never do everything that you could do, because your role is pretty unbounded. It’s always a challenge to decide what not to do, whether you’re delegating it, whether you’re saying we’re going to live with this for a little while, or whether you’re going to take it on yourself as a project. It’s pretty easy to over-commit.

Time management, and risk management — deciding what stuff to look at and what stuff to trust is going to be fine without your involvement. It’s a tough thing. On a similar note, the trade-off between giving folks autonomy and doing what you think is right is also a tough thing as a manager. A lot of people think that as the manager, they get to call the shots, but it’s definitely not the case. You don’t want to be a dictator. It’s not good for ICs, and it’s not going to help them grow. Oftentimes they do know this stuff better than you. You have to develop a good intuition for when you’re going to step in and say something needs some additional scrutiny.

My default is to trust people who I’ve hired and who I’ve worked with. Their job is doing their work. But you also can’t let go 100%. That’s a tricky thing because you don’t want to be a micromanager, but you want to know enough about what’s going on to support people.

How do you help your team members grow, both as individuals and together as a team?

As individuals, there are a couple of ways to grow. One is by doing a thing that’s challenging. That’s probably the way that appeals to me the most — finding a project for people to be excited about, that is high leverage for the team. Once you’re able to do that, it’s really important to find a balance where the teammate is able to be pragmatic and be motivated by impact.

Also, they should have some freedom to be curious and learn the area around what they’re working on. It de-risks the project a little bit and it helps them solidify what they’re doing. It’s a balance between making sure that people aren’t being perfectionists, while giving them the space to fully understand what they’re working on and savor the learning.

Being very conscious about goal setting is also important. It can be pretty tricky as an engineer to set goals. A lot of times it’s like, yeah, I should just be a better coder, I should code faster. Those things are pretty hard to quantify, and it’s hard to know if you’re doing better at them, and hard to know how to do better at them.

It does help to just put in the effort to state a few learning goals: I want to understand this part of the code, I want to understand memory management and C++, something very specific. It seems nearsighted, but it is valuable to pick one thing and at the end of the quarter to look back and evaluate how a project did for that learning, even though you probably learned things beyond that one stated goal. It gives you a framework for reflecting on how you’re learning.

Growing as a team largely involves a feeling of shared ownership over priorities. Everyone has their role, but if you have a team where the priorities are understood and shared, then people have a lot more positive reward out of other people’s contributions and they feel supported in their own. That creates a lot of empathy and creates a lot of flexibility in how the team helps each other out. Having a sense of shared ownership, shared celebration, and shared responsibility is really great for a team.

What advice do you have for new managers or people looking to shift their career path and become managers?

The number one priority is to build good relationships with people. Make sure that that’s something that you enjoy, because your number one deliverable as a manager is trust. You can mentor our new hires, schedule 1 on 1s with other people on the team, make sure that you’re bonding with your peers and understanding what their needs are.

Additionally, there’s opportunity as an IC to take a little bit of extra ownership over a project. And getting good at working cross functionally is good. Understanding the hiring process is also ultimately going to be a requirement, but at the end of the day, none of these things are individually super important because you’ll learn them on the job.

The biggest piece of advice I have is to express interest to your manager about this, because the opportunities for you to have impact beyond writing code will vary per company. Your manager will probably be pretty excited to have you want to help out beyond writing code, and they can help you find an avenue for that.

Is there anything else that you think is important to say that we didn’t touch on already?

Drink lots of water. Stand up every half hour.

All good advice for sure.

Oh, and get regular sleep. Software engineering is such a mental thing, but taking care of your body is going to pay off pretty quickly when you don’t have wrist issues and you’re not burnt out. So drink water, get plenty of sleep. Stand up every half hour. That is important as having learning goals.

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