Hillary Nussbaum

“Don’t see management as a promotion, see it as a shift in role, and acknowledge that it will be a bit uncomfortable for you, and give yourself space to be okay with that.” – Smruti Patel, Engineering Manager at Stripe

Many engineering leaders move into management unprepared for precisely that reason — it requires a shift in mindset and a new set of skills. To ease that transition for new and aspiring managers, and to help seasoned managers level up, Code Climate and Codecademy for Business interviewed engineering leaders about the key components of leadership success. We spoke to VPs and Managers at companies like Netflix, Intuit, GitHub, and Stripe to find out about their most successful management strategies and the skills that they deem to be essential.

Their best advice is compiled in our ebook, How 10 Engineering Leaders Build High-Performance Teams.

Highlights include:

“Having leaders on your team that are not managers is actually very useful because for you as a manager, that means you don’t have to do everything…leadership by influence or suggestion is actually a lot more powerful.” – Mathias Meyer, Engineering Leadership Coach, www.paperplanes.de

“I start my management relationships with the foundation of trust, respect, and accountability. A powerful way to show trust and respect for your team is by welcoming everyone’s opinions, ideas and feedback.” – Alexandra Paredes, VP of Engineering at Code Climate

“Don’t pretend like you have all the answers. Do that figuring out in front of the team because it’ll make them trust you more, not less.” – Nitika Daga, Engineering Manager at Stitch Fix

Download it now for wisdom from:

• Tara Ellis, Manager, UI Engineering at Netflix
• Brooks Swinnerton, Senior Engineering Manager at GitHub
• Gergely Nemeth, Group Engineering Manager at Intuit
• Lena Reinhard, Vice President of Product Engineering at CircleCI
• Mathias Meyer, Engineering Leadership Coach, www.paperplanes.de
• Anchal Dube, Senior Engineering Manager at Zocdoc
• Andrew Heine, Engineering Manager at Figma
• Smruti Patel, Engineering Manager at Stripe
• Nitika Daga, Engineering Manager at Stitch Fix
• Alexandra Paredes, VP of Engineering at Code Climate

It’s impossible to step into technical leadership fully prepared. The most successful technical leaders are always supplementing their own hard-earned expertise with the wisdom of others, drawing on the experiences of their peers and predecessors.

Over the past year, we’ve been speaking to engineering leaders from a range of industries, seeking out their advice on everything from fostering a strong company culture to helping your developers avoid burnout.

Now, for the first time ever, we’re making that collective knowledge available in one place.

It’s our inaugural Leadership Development Month – a December packed with resources for everyone from seasoned VPs to soon-to-be Engineering Managers. All of this year’s webinars and virtual events are now available on-demand, supplemented with blog posts and e-books, all aimed at helping you hone your leadership skills and build a high-performance engineering team.

Check out the materials below, and start preparing to be a stronger leader in 2021. There’s more to come, so be sure to subscribe to our newsletter and follow us on Twitter and LinkedIn for updates.

Data-Driven Leadership

• Roger Deetz, VP of Technology at Springbuk – Using Metrics to Reinforce Company Culture [Fireside Chat]
• Ale Paredes, VP of Engineering at Code Climate – Managing with Metrics [Fireside Chat]
• Juan Pablo Buriticá, Head of Engineering, LatAm at Stripe – Delivery Metrics [Fireside Chat]
• Edith Harbaugh, CEO and Co-Founder of LaunchDarkly – Continuous Improvement [Fireside Chat]
• The Moneyball Approach to Engineering Metrics [Blog Post]
• The Essential Data for Leading a Remote Engineering Team [Blog Post]
• How Our VP of Engineering Used Data to Support Our Engineering Team on a Human Level [Blog Post]
• So You Read Accelerate. Now What? [Blog Post]

Cycle Time: The Most Critical Metric

• The Engineering Leader’s Guide to Cycle Time [E-book]
• Perspectives on Cycle Time [Round Table]
• What is Cycle Time and Why Does it Matter? [Blog Post]
• The Virtuous Circle of Software Delivery [Blog Post]
• The Single Greatest Lever in Shortening Cycle Time [Blog Post]
• How to Stop Code Review from Bottlenecking Shipping [Blog Post]
• Keep Code Review from Wasting Everyone’s Time [Blog Post]
• The Last Mile to True Continuous Delivery [Blog Post]

Communicating with Executive Stakeholders

• What Your Engineering Board Slides are Missing [Webinar]
• How to Build a Leaner Process and Boost Your Engineering ROI [Webinar]
• Engineering Metrics are Business Metrics [Blog Post]
• Startup CEOs: Here’s Good News You Can Include in Your Q4 Board Deck [Blog Post]
• How to Choose Software Development KPIs for Your Board Deck [Blog Post]
• Hire People or Optimize Processes: A Cost-Benefit Analysis for Engineering Leaders [Blog Post]
• Hire or Optimize [Calculator]

Running Effective Meetings

• Running Remote Meetings with Data [Webinar]
• How 5 Minutes of Preparation Can Finally Make Standup Meetings Productive [Blog Post]
• Why Retro Action Items Fail (And What to Do About It) [Blog Post]

Leading High-Performance Teams

• Katie Womersley, VP of Engineering at Buffer – Be a Leader and a Manager [Fireside Chat]
• Dr. Aneika Simmons, PhD, and Anjuan Simmons, Technology Translator – Preventing and Addressing Burnout [Fireside Chat]
• Measure and Improve How You Innovate [Round Table]
• Developer360: Building a High-Performance Team with Data [Webinar]
• You Can’t Set Effective Engineering Goals Without Data [Blog Post]

Debugging Processes

• Continuous Delivery isn’t a process — it’s a culture [Blog Post]
• Rework is Costing Your Company Millions — It’s Time to Cut Back [Blog Post]
• Managers: Beware the Fallacy of Process [Blog Post]
• How Splice Applied the Scientific Method to Unblock Deployment [Blog Post]

Innovation is critical to startup success. To satisfy your customers, stay ahead of your competition, and keep your team engaged, you need to be shipping often — and at high quality.

But how can engineering departments measure and improve their ability to innovate?

With the right data, you can streamline processes and unblock your engineers, clearing the way for developers to work on fresh ideas and deliver new value to your customers.

In this 45-minute webinar, three startup leaders share how they use data to boost innovation on their engineering teams. You’ll hear from:

• Edith Harbaugh, CEO and Co-founder, LaunchDarkly
• Santiago García, Co-founder and CTO, La Haus
• Dalia Havens, VP of Engineering, Netlify

Here are some of the key takeaways:

Innovation requires iteration.

Edith Harbaugh: One of the things that really helped us innovate is we just had more swings at bat. If you’re in a cadence where you can release not every year, which is incredibly stale if you’re in the app store, but every month, or every week, and then do backend updates so you can update hourly – you’re going to win. ‘Cause part of the fact is that not everything you do is going to be perfect. But you just have to keep swinging and swinging and swinging, and one of those things is going to land.

Dalia Havens: One of the things I love about the way at Netlify we define innovation is that we focus on the simplicity of the solution to these complex problems…It’s about those quick iterations. It’s a learning journey. And it’s really hard to figure out which path will take you to the right solution if you’re not iterating.

Santiago García: To bring you some context, [La Haus is] in Latin America. So in this market, we have to invent actually everything. We don’t have [real estate] databases, like you in the US have…From here, we have to create everything from scratch. And that means you need to start to create everything with a good pace, with very fast experimenting because there are things that you don’t know.

Building a metrics-driven culture.

Dalia Havens: [Metrics] are operational measures. They are not punitive, they are very much a tool to help us improve at the end of the day.

Part of my responsibility is to create a quality of life for developers to do their best work. How are we measuring that? How are we removing roadblocks? How are we identifying that there was a roadblock? That’s where the data comes in. And when you bake it into the culture and not make it a taboo to talk about or hide it from this stakeholder or not communicate the incentive behind it, it creates a different shift…creating that metrics-driven culture is actually really important for the success of using metrics in your organization.

Edith Harbaugh: I think you really need to have metrics that people buy into in terms of, “How often do we ship?” because that means that I can feel pride that my code is out there. “How often are we able to roll back?” because that means that I can feel confidence.

Santiago García: What I think about it is what Peter Drucker said — “What you don’t measure, you can’t improve.” And that’s very important, that is very cultural. You can give feedback based on metrics, and people [can] feel comfortable with that. At La Haus, we have two values at the company…We have one that is, “Strive for more.” People want to improve, so it’s good to show the metrics, so they can see they are doing things [that] could have been better. Also, we have something that is called, “Extreme openness.” When you are open to feedback…you can take your data and make these data-informed decisions. For me, it’s very cultural.

Data provides objective insights.

Santiago García: When we started working remotely, some engineers started to complain — not complain, but they started to say, “Hey, we’re working more hours, we are exhausted, we have been working more.” My feeling was that we were delivering the same amount of work or less. But in that moment, I couldn’t measure [that feeling]. The first decision was to start measuring that, so I started using Code Climate.

Edith Harbaugh: When you get bigger, you just have to get a lot more deliberate about communication and about what you’re measuring and how teams work together. And then also still make sure that you are measuring, “Are we moving forward? Are we having meetings for the sake of having meetings?” So one question that the engineering side has to understand is, “How much new versus old features are you doing?” Like tech debt versus new, which is a really tricky balance. If it swings too far in either direction, you know that you’re going amiss. If 80% of my time is on maintenance, you’re not innovating. If 100% of my time is on innovation, and I’m not doing any code maintenance, stuff is going to start breaking in the field. So just keeping a close eye on metrics like that, in terms of “Does the team have the right pressure and direction?”

Dalia Havens: I fell in love with metrics because…through this organic journey to engineering management, I found that a lot of times without them, it’s a gut-feel conversation. And those are really hard to have without it seeming personal or you’re saying that someone is not putting in more hours or the right level of effort and so on. So what metrics have allowed us to do is sort of come objectively to the conversation. We are all trying to remove these roadblocks that are getting in your way and so on.

Transparency is critical.

Santiago García: [Transparency is] very important…I went with my team in a one hour meeting, I showed them the tool, how we are going to measure the process. And this was very clear, it was to improve the process. It was not going in a very punitive way or something like that. We wanted to improve our process, and everyone wants to improve. Actually, the next day, all the engineers were asking me for access to the tools so they could see their metrics and how they could improve them.

Dalia Havens: I’ve had an experience with an established team where it…the team was not talking about them being blocked to ship. And it was because we had metrics that we could see our week-to-week trend. And we’re like, “This is weird. For some reason, all of a sudden, we are not able to get things to production. Let’s talk about it.” So I found that it’s a really, really great way to be transparent and honest with everyone on the team. And also disarms sort of that tension. Because at the end of the day, just like all the the monitoring tools we have in infra, it’s to allow us to improve and iterate and create a better environment for development.

Innovation can be game-changing or destructive — make sure you’re moving in the right direction.

Edith Harbaugh: I think innovation in and of itself is a hard word. I think there’s the bright shiny answer that innovation is game-changing stuff that moves the business forward. The flip of that coin is innovation is sometimes harmful and destructive. And you don’t really know sometimes until you flip that coin, what way it’s going to land.

Dalia Havens: A product full of bells and whistles that are not really giving a seamless user experience is not going to be as effective or as useful to the potential end-user as one that is more thought out…Innovation is a big word for us. What I translate that to is iteration. Are we able to iterate? Are we able to learn? Do we have the tools to be able to learn to gradually get things out, or to decide on killing something? …having these tools allows the team to really define what is success or how are they working toward that success metric.

Santiago García: I think is very difficult to innovate in the tech team if you are not aligning with your business, with your customers…For my team, the engineering team, its mission is to deliver value to our customers as fast as we can, with the best quality.

To learn how to start gathering insights from your own data, request a consultation.

When teams go remote, the function of meetings changes. Lacking context, team members end up using meetings to play catch-up rather than to discuss and make critical improvements.

In this 45-minute webinar, Code Climate Co-Founder Noah Davis discusses how leaders can use data to better support their remote teams. He explains how to dig into engineering data from Velocity reports to get your team on the same page and keep meetings focused and productive.

You’ll learn how to use:

• Stand-ups to unblock engineers
• Retros to diagnose problems and process fault lines
• 1:1s to give constructive feedback and encourage career development

To start bringing data to your remote meetings, request a demo of Velocity.

Gathering context and showing empathy may be the most difficult parts of a performance review, but they’re also the most important — this year, more than ever.

Even in the best of times, performance reviews can be harmful. In the era of COVID, with team members already contending with external stressors and verging on burnout, a poorly-executed performance review is likely to be even more damaging to your team members’ morale.

With a little extra care, leaders can avoid giving a review that focuses on business goals at the expense of the individual — and hopefully, can take a few additional steps towards boosting their team members’ motivation and well-being.

After working with 1000s of engineering teams on improving performance, we’ve learned a few things about successful end-of-year reviews. We recommend that reviewers:

• Take measures to check assumptions and assume best intentions
• Contextualize the limited information available
• Be specific and focus on coaching opportunities

These strategies will help you give an effective yet compassionate review, and are worth keeping in mind any time you need to give constructive feedback.

Check your biases and assumptions with data

Most managers are aware that they have innate biases that can hamper their ability to fairly and accurately evaluate their team members. But awareness isn’t enough. The most effective way to reduce bias is to check your instincts against objective data.

For example, performance reviews are particularly subject to recency bias. The last few weeks or even months of work loom largest in your memory, which means they are most likely to influence your opinion about your team member’s performance, even if they represent a small sliver of the past year.

If your team member has been writing fewer commits than usual over the last month, you might remember them as writing less code for the entire year, even if that is not the case. Objective data can help you check that bias, as a quick look at your team member’s Commit Volume for the past year can confirm that their current drop in productivity is temporary and not representative of their performance as a whole.

You can use data to check other assumptions as well. Let’s say one of your team members has been taking afternoons off to supervise remote learning or to care for an elderly relative. You might fall prey to negativity bias, a universal bias in which negative impressions — in this case, your team member’s truncated working hours — make a larger impact than positive ones. As a result, you might overlook your team member’s positive contributions to the team and assume that they have been less productive because they’ve been working fewer hours.

But with objective data, you’ll know for sure. You might check their Pull Request Throughput over the last year and find out that, in fact, your team member has been just as productive than usual, if not more, because they’ve been hyper-focused during their limited working hours in an effort to get everything done.

Put everything in context

Of course, data doesn’t tell the whole story. It’s always important to put all quantitative data in context, but it’s particularly important now, when everyone is in need of a little extra compassion and support. With the right context, you can get a more complete picture of your team members’ circumstances, and gain a better understanding of their current needs.

Let’s go back to the example of the team member who has been writing fewer commits than usual over the past month. It might be helpful to use that information to start a conversation and find out why they’ve had a hard time getting into the codebase. You might find out that schools in their area recently shut down, and they’ve been struggling to get into a new routine with the added responsibility of supervising remote learning.

With that information, you can develop a plan to better support that team member, whether it’s temporarily taking some work off their plate or offering them a little time off until they can get their bearings.

On the other hand, your conversation might reveal information that has nothing to do with their personal circumstances at all. For example, you might find out that the team member who has been logging fewer commits has been taking time out of their workday to help with onboarding new team members and improving process documentation.

With that knowledge, you can have a more targeted conversation about your team member’s interests and professional goals. If it turns out your team member prefers working with new developers to writing new code, you might be able to help them reshape their role and find more opportunities for coaching and mentorship.

And don’t forget — positive data needs context too. You might be pleased to find that a team member has been more productive than ever over the past year, with a consistently high Commit Volume and PR Throughput, but it’s still worth having a conversation about why that is and how it’s impacting them. That team member might reveal that they’ve been feeling overwhelmed and insecure due to the current economic and political climate, so they’ve been taking on extra projects and working long hours to ensure their job security.

As their manager, you can use this information to help reassure your team member that their contribution is valued and to help take some of the pressure off. You might even want to discuss their priorities and reallocate certain tasks, so you can help your team member avoid burning out.

Use data to provide specific, actionable feedback

The most effective feedback is specific and actionable. Data can help you focus your conversations on certain aspects of a developer’s workflow, or specific units of work, so you can more effectively coach each individual developer.

For example, let’s say one of the developers on your team is consistently opening large Pull Requests. You could simply encourage them to “open smaller Pull Requests,” but that feedback might not be effective if they’re having trouble finding ways to break down their work. Instead, it can be helpful to identify some of their largest Pull Requests and bring them to your evaluation. That way, you can take a look at some actual Pull Requests together and discuss ways they could be broken down into smaller parts. With concrete examples and a bit of focused coaching, that developer will walk away from your conversation with actionable strategies for opening smaller Pull Requests, and you’ll be more likely to see them achieve the desired result.

In cases where your team members are seriously underperforming to the point where their job really is at risk, it can be helpful to set clear, specific performance expectations. With easy-to-understand targets, that team member may have an easier time doing what they need to do to stay afloat.

Think beyond the annual review

Even if you’re able to run objective, compassionate performance reviews that leave your team members with actionable feedback, annual performance reviews happen too infrequently to maximize their potential for positive impact. It’s not always easy for a team member to speak up and ask for support, and it’s difficult for developers to keep growing when they’re only getting feedback once a year.

If you don’t use them already, consider making regular 1-on-1s part of your management repertoire. With frequent 1-on-1s, you’ll get to know your team members on a more personal level, and with more frequent check-ins, you’ll be able to more effectively support them through difficult situations, whether it’s a personal challenge, like a sick loved one, or a professional one, like a communication breakdown with a fellow team member.

Re-evaluate your evaluation process

If there was ever a year to re-evaluate the way you handle performance evaluations, this is it. While current circumstances may have generated extra pressure to meet business numbers, they have also created extra reason to be compassionate. As a leader, it’s your responsibility to ensure that business pressure doesn’t compromise your team member’s well-being, and to create the best possible circumstances for your team member to do their job.

No matter what you do, some of your team members may be struggling due to circumstances completely beyond either of your control. It may not be the right time for them to boost their productivity or reach the next level of professional success, and that’s ok.

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 here.

Below is an excerpt from our conversation with Nitika Daga, Engineering Manager at Stitch Fix. Nitika spoke about helping developers learn from each other and being vulnerable as a leader. Edited for length and clarity.

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

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

Nitika Daga, Engineering Manager, Stitch Fix: I am currently the Engineering Manager for one of the merchandising engineering teams at Stitch Fix. At Stitch Fix, half of our engineers work on stitchfix.com, what you as a consumer would see, and then the other half of us work on internal tools. So my team owns the merchandising platform that our buyers use to place orders and track inventory. I actually started on this team four years ago as a junior engineer, so I kind of grew on the team and then got an opportunity to become a manager of the team, which is great because I have a lot of domain knowledge that helps me in my current role. Prior to this, I was an engineer at another retail tech company. That’s really what I’m excited about and passionate about and what I’ve spent my career in. And then prior to that was my first job out of school. I studied Computer Science at Berkeley.

Can you tell us a bit about your transition from IC to manager?

I got really lucky. I had expressed that at some point in the future I was interested in management. My ultimate career goals are to be a CTO one day, and obviously moving into management at some point is a prerequisite for that. And then my manager at the time left for his parental leave, which is four months at Stitch Fix, and we needed someone to step in during that time. So I got to kind of try it on, in a less pressured way. Usually you go into management and it’s hard to go back, but I got four months to see if it was something I wanted to do, and then after those four months I decided I liked it. My manager decided to become the manager of another team, so I got to move into that role full time.

What was it like starting to manage a team that you had previously been a part of?

It was interesting. Some things were really good. I had the domain knowledge. I knew the technology we were talking about. I could speak to it from experience, and then when doing things like estimates, I could say, “Yeah, that feels right,” versus, “I’ve never been in this codebase so I have no idea.” Some of the challenges were obviously going from being peers with folks to moving into managing those folks, and there’s some tension that can actually arise.

I’m really lucky that I have a great team and they never made me feel like, “Oh, this is weird. You used to be our peer.” They put their trust in me, which I really appreciate, because that could have been a big cause for imposter syndrome or just like, “Hey, I don’t actually think I’m cut out for this.” They never made me feel that way.

What interested you in becoming a manager? I know you said your aspiration ultimately is to be a CTO — why are you interested in that trajectory?

I think a few things. One, I think I’m just interested in the impact that can have. You hear stories about how a good manager can make or break someone’s career, both at a company and then in tech as a whole. A lot of people just leave tech if they have bad managers. The second thing is I have found it really powerful in my career when I have a manager or someone in leadership who I can relate to and who looks like me. Stitch Fix has a female CTO, I have a fully female reporting chain, and I think it’s a little bit of like — you can’t want to be what you can’t see. Being that person for someone really inspires me to be an engineering manager who doesn’t look like a lot of engineering managers.

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

I guess I see my role as two-fold. One is translating what the business needs at a high level into problems my engineers can solve and then clearing the way and enabling them to do what they do best and go out and solve those problems. My engineering team has way more technical knowledge than I do. So my job is to give them the problem and put it into a scope that they can understand and then let them run with it. I clear the way for them, give them the resources, make sure they’re talking to the right people, and they can go out and solve that problem for the business. The second part of my role is advocating for my engineers, whether it’s tactically for a promotion or an opportunity to work on an exciting project, or whether it’s advocating for the technical approach they have proposed and making sure all the other teams are bought onto it. Just advocating for them upwards and outwards.

Got it. Is there a difference between being a manager and a leader and if so, what’s the difference?

I think there’s a difference between being a people manager and a technical leader, and I think teams need both. This is something I learned the hard way — if I know the technical details of everything my team is working on, I’m probably not focused on the right things. That is not my job anymore, and so I need a technical IC leader, like a Principal Engineer who can be focused on the technical details and lead in a technical sense, where I kind of look at the future of what we’re building in more of the people management aspect of it. So I think they’re different but complementary.

What are the biggest challenges you faced since moving into a management role?

That’s a good question. So I transitioned into manager in January, so two months before COVID hit. So I’d say the whole time has been a challenge. Luckily one of Stitch Fix’s core values is, “Motivated by Challenge.” So it’s very much in the ethos of our company.

The biggest challenge for me is has been balancing compassion for my engineers as they figure out what their new normal looks like with homeschooling or sharing a space with their partner or having to move, versus being accountable to the business for deadlines. I’m balancing those two things and making sure my engineers don’t burn out while we’re still delivering value to the company. My first priority is making sure my team is happy and healthy and can take care of themselves and their families, but also we’re a business and I need to deliver things in order for all of us to keep having jobs.

Yeah. I’m sure it’s really, really tough. You’re talking about making sure developers are happy and healthy — how do you help them grow, both as individuals and then together as a team?

This is my favorite part of the job. Promoting people and helping people grow and achieve things they didn’t think they could do is so much fun. There are a few things I do. One is, I try to understand their aspirations. Something that’s really been clear in the last nine months is some people are just happy where they are. They’re not seeking that next promotion because there is enough going on in the world. So it’s about really coming to a common understanding, and giving them growth opportunities that are maybe still in their comfort zone and don’t stretch them too much. And then taking those engineers who do want to grow, and just giving them the right opportunities. Again, the technical knowledge of my team is stronger than mine, so it’s really matching them to the right opportunity and then letting them run with it within the right guardrails.

And then in terms of growing as a team, again I think it’s pairing the right people together. We do a lot of pair programming at Stitch Fix, especially now that we’re remote. So looking at the skills that I know a Senior Engineer has, and pairing them with the right Junior Engineer so that Junior Engineer can run and grow, and team members can lean on each other to grow their skill sets.

As a remote leader, how do you make sure you’re able to really understand what your team needs?

Stitch Fix engineering was 50% remote prior to this. I was living in New York earlier this year and I just recently moved back to the Bay, but only one person on my team is in HQ. Having more recurring one-on-ones and touch bases, and really leaning into async communication because we are spread across time zones. And then specifically for understanding how is the team working together and what do we need, we do retrospectives every sprint. I also really drive home the point that feedback is a gift for managers. We don’t get it that often, unless things have gone really terribly wrong. You can’t fix something if you don’t know it’s not working, and so I really work on building that trust with my team so they feel like they can give me that feedback, and then trying to get that feedback from different avenues so we can try new things and figure out what works for the team as the environment changes around us.

What advice do you have for new managers or for people who are looking to make the shift into a manager role?

I think one piece of advice I got from my current manager that I found really powerful was to lean into the vulnerability of being new at something. If you’re managing a team, it’s easy to pretend like you have all the answers, you have everything figured out. But I’ve been doing this for 9 or 10 months now and I’m still figuring out my management style and what works for me. Be upfront about that, let your team know, “Hey, I’m going try a few things out. Let me know if they’re not working until I figure out what’s working.” It lets your team know that you’re trying things out and that you don’t have all the answers. Being vulnerable as a leader gives your team permission to be vulnerable back to you, and that just builds more trust and you get better and more honest feedback that way.

So don’t pretend like you have all the answers. Do that figuring out in front of the team because it’ll make them trust you more, not less.

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

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 here.

Below is an excerpt from our conversation with Smruti Patel, Engineering Manager at Stripe. Smruti spoke about getting to know your team members, the importance of delegation, and the power of well-designed metrics. Edited for length and clarity.

For Smruti’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 currently lead the LEAP organization — that stands for Latency, Efficiency, Access & Attribution, & Performance — and Big Data platform engineering at Stripe. I came to Stripe after 11 years at VMware, where I worked on their enterprise disaster recovery solution and data protection for the cloud. So, looking back at my career, I’d say I’m a generalist at heart who loves bringing a rich, diverse set of people together to solve complex, ambiguous problems. And I’ve been leading teams and organizations for almost a decade.

Did you start out as an IC?

Yes, I started off as an engineer back at VMware after a Master’s in Computer Science. I moved from New York to California when I saw nice skies and better weather. I started off at VMware as an automation engineer. And then I moved to managing the team that I was working with. From there, I transitioned to managing and leading multiple teams.

What was the transition like from being an IC to managing one team? And then the transition to managing multiple teams?

VMware was very thoughtful, and still is, in developing its engineers and growing its engineers. There are dual tracks, where you can grow as an individual contributor, or you can pivot to the management track.

I was deciding whether I wanted to move to Staff Engineering or to be a manager. At that point, my manager approached me to manage the team I was on, and I was already owning a lot of the day-to-day tasks around technical design decisions, communicating to different stakeholders, figuring out release timelines, mentoring junior engineers, and in general defining the strategy for the team.

So it seemed like a logical next step, although looking back, I decided to switch to management in big part because I thought I’d have higher authority and autonomy in driving the product strategy. So I would say I probably got into it for the wrong reasons, because I soon realized I couldn’t do a lot of that.

But I stayed for the right reasons. I like seeing people grow, giving them feedback, identifying what made each engineer tick, and seeing an excited, motivated set of people come together to work magic to solve complex business needs.

And then another big switch came to me when a peer manager approached me to see if I wanted to manage one of the development teams alongside the automation team. And that was a second switch.

One thing I’ve learned, looking back, is always say, “yes.” Raise your hand when an opportunity comes knocking. I think the switch there was from managing engineers to managing engineers and managers or multiple managers. The shape of the challenge there is slightly different.

Got it, and how is it different?

One thing that is common to both is that you’re trying to walk that line of either being a mentor or a coach or a sponsor, and asking open-ended questions. The thing that I found different is that now there’s this level of indirection, so to speak.

Identifying how the team is doing, debugging team engagement or velocity required me to delegate a lot more. While managing managers, you have to let them drive some of the strategy and the vision for their team. So the scope of what you delegate changes.

What do you see as the role of a manager and the role of a leader? Are they different, or are they the same?

I think about that a lot, because walking that line and being one or the other at the right time is important. I’ll start with being a manager. Three to four things come to mind here. One is hiring the right set of people. The team composition based on diversity in skill set, in representation, in perspectives in experiences, is super crucial. That I think is almost the number one priority of the manager.

Now that you’ve got folks, and you’ve got them in the door, how do you then set them up for success? So the second thing that I think managers should focus on, which I personally do a lot of, is ongoing 1 on 1s. How do you set up expectations around what the business needs are? How do you determine what level each engineer is at? How do you support them through challenges, whether they are technical, or organizational, or even personal sometimes? You’re doing that by building trust through vulnerability both ways, and ongoing feedback. Radical Candor is a really good book on frameworks for providing that ongoing feedback, whether it is constructive or critical. Quite often managers focus on things that could be better, but it’s equally important to be able to reinforce the positive, and to say, “continue doing this,” or, “you’re doing great on this.”

So, once you set them up for success, the other thing I especially try to do is to provide access to opportunities to all. Having been — well, I still am — a brown woman leader in tech, I’ve had my fair share of not having access. So something I’m extra mindful about is ensuring access to opportunities, to those big risk, big reward situations, for every person on my team. I go ahead and identify those stretch opportunities that are uniquely catered to their strengths, or their interests, or their career aspirations.

And so that’s on the hiring and the team building side. The other big area that managers focus on is engineering. There’s the planning: Why are we building? What are we building? And there’s the execution, which is: How are we going about building? How are we measuring it? This is where engineering velocity comes into picture. Third, there’s delivery, which is: Is it really done? And making sure your feedback loops are actually telling you the story you wanted to tell, and that users are happy. And as you’re building all these new, shiny things, they have to last the test of time or the orders and magnitude of scale.

So, building teams, setting them up for success, and ensuring that we are doing what we are actually here to do. And then you have to bridge the gap. I think quite often I see a gap between what the team is doing and what leadership expects the team to do. So it’s important to bridge the gap between the business and the individual by being the advocate for the team, the team’s impact, and the engineers’ contribution. That can involve getting stakeholder buy-in, resolving conflicts, addressing concerns, and sometimes even marketing the team’s work.

That’s management. The way I think about it is, if you were to draw a Venn Diagram, all leaders are not managers, and all managers are not leaders.

Leaders are the ones who drive changes organizationally. They are able to influence others, not through authority, power, or control, but by motivating the right set of goals, elevating the collective ambitions, and then demonstrating success. And that’s the subtle difference that I see between managers and leaders. Where managers have to be focused on a lot of the tactical side of things, I’ve seen leaders bring along the strategic and the visionary elements. And that means ICs can be leaders too.

How do you drive high performance on your team, both at the individual level, and at the team level?

This one really keeps me up at night. It goes a lot to not having a cookie cutter approach in general. That’s why I focus a lot on regular 1 on 1s with every person on the team, because that’s where I develop a better understanding of what motivates each person, what challenges each, what drives each. Everyone is at different stages, in their careers and in their lives, and a pandemic doesn’t help. Each situation is very different at home. So it’s important to be able to connect with everyone and understand what their unique strengths are and what are they looking to grow into, and to take a longterm career view.

I tell a lot of my reports that once I manage you, I manage you for life. Because it’s not about whether you are on a team that reports into me. It’s about where you see your career, and how I can best support you for the longer term. I try to marry the team’s deliverables with their individual aspirations. And I try to do it in a very transparent and consistent way, and to make sure that all the voices in the room are being heard, and that the access to opportunities is going across the team.

It’s important for everyone to have the opportunity to be the DRI, or Directly Responsible Individual. You lead a project from design through execution, leading other engineers, both within the team and across. So, being a DRI is sort of a big deal. I make sure that the same set of folks are not always raising their hands. And that’s why I run a very transparent, consistent DRI selection processes while highlighting what is required. And I’ll sort of nudge people and say, “Hey, you would be good at this, why don’t you apply?”

And then what is more important is making sure that folks have the psychological safety to fail. High growth comes for individuals when they take on big, risky things. So I try to make sure that all people on the team are taking those risks as well, and I give them the safe space with good feedback and space to fail. If they succeed, that’s awesome, they’ve stretched themselves and in the process, they learn.

The meta thing in all this that I communicate with the team, is the growth mindset, which ensures that everyone’s learning and growing as we go, because that’s what the organization needs.

Now that we’ve talked a bit about performance — how do you approach engineering velocity on your team?

I manage six teams right now, and each team is in a different state team maturity, so the shape of all six teams is very different. At the planning stage, I work on getting alignment, and then prioritizing and focusing on the right things.

In execution, you drive speed and quality, how you’re doing things. This is where Dr. Nicole Forsgren’s Accelerate book is really awesome. It helps you identify whether you are tracking the right metrics and evaluating whether the team’s execution is where it needs to be.

I tie it back to: here was the metric we signed up to solve for, here’s the problem we were looking to solve, and here’s how the needle has or has not moved. Tying that feedback loop together becomes super crucial during delivery.

You also have to pay attention to operations and maintenance, and make sure that the less glamorous bits are not sucking up all your soul, because you do want to keep doing the strategic innovative work. At the same time, if 80 to 85% of your team is bogged down, just keeping the lights on for the stuff that you’ve shipped, then you’re not going to be able to invest in new things.

We frequently hear that managers worry their team members will be resistant to using metrics. How did you approach that? How do you get your team members comfortable using them?

This happens so often that it makes me smile. I personally view metrics as something that has to be used carefully. They can do a lot of harm, and the right metrics, when crafted correctly, can also do a lot of good.

A well-defined metric can drive alignment with stakeholders and leadership. It can help drive prioritization and focus within the team. But it can also help the team say, “Hey, here’s a metric we really care about, which the company cares about, and clearly we’re under invested. Here are the projects we need to do to move the needle.” When done right, they can really increase the overall impact the team can have.

But there can also be times when the team may not feel like it’s in full control of its own priorities, or when it could be over-indexed on some wrong metrics. That can have them start losing faith in the system.

One of our teams was measuring their overall efficiency in terms of how our standard infrastructure is increasing as a function of Stripe’s business. This is a very company-level metric, because it’s not that my team actually spends the money on all the infrastructure. It’s about the money that everybody at Stripe engineering spends. So, a natural question the team had is, “How are we accountable? And why are we accountable for the top-line spend when we do not have the agency control a lot of it?”

That was a very interesting thing. It was very true, we couldn’t move the overall needle. But we’re Efficiency, we’re sort of the last line of defense. So how do we then push the envelope and bring about organizational change, so we can see areas with pockets of inefficiencies? The only way to do that is to have a true North Star, company-wide metric, which we drive, which we provide visibility on.

So these engineers saw leadership acknowledge that this needle moving up and down is not solely Efficiency’s responsibility, but that Efficiency is an enabler to that change, and will be the voice of reason. Leadership communicated that if it’s down, you’re obviously responsible for it being where it is. But if it were to go up, hearing from you on the causes and the drivers is what we would hold you accountable for.

I’m going to transition a little bit more into general advice. But before I do that, is there anything else around metrics that you feel is important to say?

Metric design sounds obvious, but it can be very challenging at times to measure the right stuff. It’s hard to walk that line in designing the right metrics, which the team can own, and which really move the needle on impact. Word of caution, but you know, with great power comes great responsibility.

What advice do you have for new managers, or for people looking to shift out of an IC role and become a manager?

At least in well-designed engineering systems, management isn’t the only way to up-level yourself. I personally would suggest running away from such systems if you have the privilege to do so. Truly well-designed systems have an IC track, and a management track.

And then, avoid the new manager death spiral, which happens when you want to own and control it all. When you’re in IC, you’re in full control of your destiny, you know what your project is, you know how to scope it, how to design it, how to execute. But as a manager, I think the first thing you need to do is give some of that control away. It’s worse if you actually go ahead and do everything, because you’re not letting your team take on some of that.

You also have to get comfortable in the unknown, because you’re not coding day to day. And if you are, then you’re you’re not doing what you are uniquely positioned to do and accountable to do, which is be there for the team, be there for individuals on the team and grow them and motivate them. You need to delegate, and to share your trust and faith that your team will grow into it.

Don’t see management as a promotion, see it as a shift in role, and acknowledge that it will be a bit uncomfortable for you, and give yourself space to be okay with that. The output of the manager is not very tangible in the near term. It’s a lagging indicator of success, and the feedback loop is longer. So, it takes time for you to see how you are being effective.

Remember, you don’t have to have all the answers. And you don’t have to always be right either. You need to be open, be curious, and at times be vulnerable. The job is to find and hire the most brilliant minds with a complementary and diverse skill set, and get them together. And your unique responsibility is to create the environment for that set of folks to flourish as they work together.

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

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.

Continuous Delivery is the ability to ship code quickly, safely, and consistently, and it’s a necessity for teams that wish to remain innovative and competitive. It’s focused on delivering value to the user and starting that feedback loop early — the ideal state of Continuous Delivery is one in which your code is always ready to be deployed.

Many engineering leaders think of CD as a workflow and focus on the tooling and processes necessary to keep code moving from commit to deploy.

But CD is more than just a process — it’s a culture. To effectively practice CD, you need to:

• Convey the importance of CD to your team
• Create a blameless culture, one in which developers feel safe dissecting and learning from mistakes
• Facilitate alignment between business goals and CD.

With the right culture in place, your team will be better positioned to get their code into production quickly and safely, over and over again.

Explain why CD is important

Processes fail when developers don’t understand their rationale. They may follow them in a nominal way, but they’ll have a hard time making judgment calls when they don’t know the underlying principles, and they may simply bend the processes to fit their preferred way of working.

Code Climate’s VP of Engineering, Ale Paredes, recommends starting with context over process. Explain why you want to implement CD, reminding your team members that new processes are designed to remove bottlenecks, facilitate collaboration, and help your team grow. As they get code into production faster, they’ll also get feedback faster, allowing them to keep improving their skills and their code.

Then, you can set concrete, data-based goals that will allow you to track the impact of new processes. Not only will your team members understand the theoretical value of CD, meeting these new goals will help prove that it works.

Connect with individual team members

Ale warns that when an individual developer isn’t bought into the idea of CD, they’ll “try to hack the system,” doing things the way they want to, while working to superficially meet your requirements. This may seem like it accomplishes the same goal, but it’s not sustainable — it’s always counterproductive for a team member to be working against your processes, whether those processes are designed to promote CD or not.

She recommends using 1-on-1s to get a sense of what motivates someone. Then, you’ll be able to demonstrate how CD can help support their goals. Let’s say a developer is most excited about solving technical challenges. You might want to highlight that practicing CD will allow them to take end-to-end ownership of a project: they can build something, deploy it, and see if it works when they’re shipping small units of work more frequently. If another team member is motivated by customer feedback, you can remind them that they’ll be getting their work into customers’ hands even more quickly with CD.

Creating a blameless culture

Once your team is bought into the idea of Continuous Delivery, you’ll need to take things a step further. To create the conditions in which CD can thrive, you’ll need to create a blameless culture.

In a blameless culture, broken processes are identified so that they can be improved, rather than to levy consequences. It’s essential that team members feel safe flagging broken processes without worrying that they’ll be penalized for doing so or that they’re singling out a peer for punishment.

A leader can help establish that blamelessness in the way they communicate with their team members. Ale’s rules for incident postmortems clearly state that there is no blame. Names aren’t used when discussing incidents or writing incident reports because the understanding is that anyone could have made the same mistake.

Convince the C-Suite

Fostering the right culture on your team is essential to effectively implementing Continuous Delivery, but it’s not enough. CD also requires support from the top. If your company is looking for big, splashy releases every quarter, Continuous Delivery will be a tough sell. Frequent, incremental changes are almost fundamentally at odds with the roadmap that the organization will set out for engineering, and how it will measure success.

To bring Continuous Delivery to an organization like this one, you’ll benefit from applying one of the core principles of CD: incremental change. You won’t be able to drive a seismic shift in one push. Instead, you might try Ale’s strategy and look for ways to introduce small changes so you can start proving the value of CD. For example, you might try automating deployments, which should cut back on incidences of human error and free up developer bandwidth for writing new code.

The Virtuous Circle

Process may start you on your way to Continuous Delivery, but you won’t get far. Pair those processes with a culture of CD, and you just might reach the Virtuous Circle of Software Delivery — the point at which each improvement yields benefits that motivate developers to keep improving.