1:1 with Anchal Dube, Senior Engineering Manager at Zocdoc

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, Andrew Heine, Engineering Manager at Figma, and Mathias Meyer, Engineering Leadership Coach.

Below is an excerpt from our conversation with Anchal Dube, Senior Engineering Manager at Zocdoc. Anchal shared her thoughts on the shift in mindset necessary to take on a manager role, the importance of having the right expectations, and the similarities between managers and tug boats. Edited for length and clarity.

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

Tell us about your current role, and your career journey up to this point.

I’m a Senior Engineering Manager at a Zocdoc, and currently I’m overseeing a couple of different teams. One team is focused on the Zocdoc video service we launched in response to the pandemic and the fact that a lot of care suddenly needed to go virtual. It’s something that we built and launched over a two-month time period, whereas more typically this would have been a two-year roadmap. The other team focuses on our provider touchpoints and how we can use the relationship that we have with our providers to build a better connection with their patients.

In terms of my journey, I have a Bachelor’s in Computer Engineering and a Master’s Degree in Computer Science. I started out in the healthcare space, working at Epic, which is an EMR company based out of Madison, Wisconsin. I worked there as a Software Engineer and then as a Team Lead for a little under five years. That was my first foray into a leadership role.

Early on, there was a honeymoon period where I was really excited about what I really perceived as the next step of my journey, with a promotion and more responsibility. But about nine months into that, I really started questioning whether the role was for me, and whether I wanted to continue. Around the same time, for family reasons, I was looking to move to the East Coast. And so when I moved to Zocdoc, I actually came here as an IC.

I joined as a Senior Software Engineer and wanted to continue down the individual contributor path, but was impacted by an incredible manager and mentor I had at the time. He really took the time to understand my challenges and pain points from my previous leadership role. And he gave me a lot of motivation and advice on how to navigate that transition again, and to do it much more successfully the second time around.

So after being at Zocdoc for about two years or so, I went the management route again, starting with the team that I was already working on as an IC.

What was it that turned you off of managing the first time around, and how did that change, other than having a great mentor? Do you feel like it was circumstantial, or a mindset that you needed to change personally?

I think mindset was definitely a challenge. One thing that I recognize now, that I don’t think I did in my first stint as a leader, was that I really needed to take a step back from owning everything directly. My path to creating impact is not going to be by executing on a given project, but by empowering my team so that they can do so. And the skill set that I need to rely on is less computer science and computer engineering fundamentals, but more around how to create influence within a group of people.

That shift was something that I didn’t recognize as necessary early on. In working with my mentor a few years later, he really instilled in me the importance of that skillset in particular. And I had to get into the right headspace for navigating some of those challenges, and not allowing myself to get sucked into a lot of frustration when I felt like I was taking on too much or juggling too many things.

Do you miss being more directly involved in the technical day-to-day, or in the kind of execution where you can check a box, as opposed to manager duties, which aren’t usually like that?

That’s evolved over time. Early on I definitely still missed being hands-on with coding. And so every once in a while, usually at least once or twice a week. I would pick up a small thing that needed to be edited on the website, or a small change that I could make.

I’m going to use an example from Grey’s Anatomy — there’s a scene where the doctors are talking about transitioning into the Chief role. And one of the pieces of advice that the former Chief has is, “start your day cutting. Start your day with surgery, and then let the rest of the day be given over to administrative stuff.” That’s something that helped me early on, so I was able to keep doing something that I really found rewarding and fulfilling. And over time, as I think about what is most important to me, and what is most important in order to make myself effective at Zocdoc for my teams, the more I’ve come to enjoy what I consider “people engineering,” as opposed to software engineering.

And so I’ve gradually shifted my balance too, in terms of what I enjoy and what I want to focus my time on.

Did you always know that you wanted to be a manager or was it something that just happened to you the first time around?

It was part of my expectations of the path to advancement and career growth. Through that lens, I wanted it, but I do think that it was a little bit misplaced to think of it as a linear growth trajectory, as opposed to recognizing how much of a role shift it is. That recognition is super important.

So now, as I mentor future leaders at Zocdoc, people who are going through a similar transition period, that’s one thing that I really try to keep front and center for them — it’s not really just the next step in the career ladder, it’s a pretty significant role shift that requires a shift in how they approach the problems that they’re going to be solving and changes the skillset that they’re going to need to rely on to get to the next level of success in their careers.

And what do you see as the role of a manager on an engineering team?

I’m going to be terribly mixed with my metaphors here, but I think that it’s a combination of coach and cheerleader. I see managers as the little tugboat that’s trying to help the larger ship, the team, navigate unfamiliar waters. It’s there all of that time to figure out where the obstacles lie, and to steer the ship away from them. So really it boils down to the manager figuring out whatever is needed to empower the team, so they can deliver at their best level.

Is there a difference in your mind between being a manager and a leader? And if so, what is it?

You can definitely be a manager without being a leader. And I think leadership comes down to the kind of thought leadership that you provide within a team context. I’ve noticed how the types of questions that I ask my team really start to influence what they consider important on a day-to-day basis.

One of the things that I took on as a side role at Zocdoc was to become a lead on our Operational Excellence Guild. And so I would bring that lens to my conversations with my team, and it was very telling to see how quickly my team adapted to that, and how those considerations became very top of mind for them as well. That illustrates to me the difference between just being a manager, where you’re doing very day-to-day organizational management things, and learning to be a leader and bringing in an element of influence.

What are the biggest challenges that you’ve faced as a leader?

The largest challenge is always that there are so many different things that are important that I would love to devote time and resources to, but we’re almost always capacity constrained. I imagine this is true for companies of all sizes, although I feel like I’ve seen that much more kind of in the Zocdoc context, where we’re still a relatively small team.

There are a lot of things that my team legitimately cares about, like keeping our tech debt appropriately low, or maintaining a certain level of code hygiene, or even which bugs we’re fixing and what type of turnaround time we’re fixing them on. But it’s a constant balancing act. It’s a constant juggle to balance that against everything that is most relevant to the bottom line of the business. We also have to think about how to keep our overhead low enough so we can continue to execute towards our main goals without getting too bogged down by the challenges posed by an unhealthy code base.

You’re talking a little bit about team goals — how do you help developers grow both as individuals and as a team?

A lot of that is very much a collaboration between myself and each of my team members. And it also hinges on how driven they are, and how much they understand where they want to be headed. I always find that for people who really understand what their trajectory is and know what they’re looking for, I can provide them with much more targeted feedback. And there are definitely other people who are really just figuring it out as they go, and for those individuals, it’s much more based on our conversations, and me picking up on the things that they are enjoying, so I can help them identify those areas and double down on their areas of strength.

How do you gain an understanding of what your team is working on at any moment in time, and then perhaps equally as important, how everybody is feeling about how things are going?

That’s been especially interesting with the pandemic and going remote basically overnight. I use my 1 on 1s with my team to get a feel for how they’re doing and what sorts of challenges they’re running into, whether it’s at work or even in their personal lives. Especially early in the pandemic, one of the things that I wasn’t recognizing very early on was how much people were starting to feel burnt out.

One thing that I did notice as a symptom was that a lot of people were working later hours than they typically would have been. And so without even really thinking about what the impact of that was, I made sure to impress on everyone the fact that it was okay to take time away from work and to just attend to their needs as well. And it was very interesting when multiple weeks later, the team brought that up as something that they found very, very helpful to course correct, and to give themselves space to take a breath and figure out what they needed to do to deal with everything that was changing around them.

Yeah, that’s something that we’ve heard a lot, and we dealt with it here as well. What advice do you have for new managers or people looking to shift their career path and become managers?

Yeah, I think I’ll go back to the thing that I said earlier, which was: Do they have the right set of expectations about what the role entails? A lot of that ultimately comes from talking to people who have somewhat recently made that transition, because they’re in the best position talk about what they enjoyed and what they didn’t and how different it was from their expectations. Having those conversations can be really crucial to helping the next set of people recognize what some of those pitfalls might be.

Apart from that though, for anyone who is interested in going down that path, my advice would be to work with their current manager to figure out what their team’s needs are on the leadership front. What are the areas where the team really needs support? Because like I said, I definitely see Engineering Managers roles as being about navigating a lot of obstacles. And so identifying those through a conversation with someone who’s already in that role is a great first step towards taking a stab at helping the team navigate through one or two of those obstacles.

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