Engineering leaders and managers here at Asana are focused on creating a product that helps our customers work together effortlessly, empowering their teams (and themselves) to do great work, and helping the business grow. They’re responsible for inspiring and developing team members, while ensuring that everyone is aligned and achieving results together.
How do they juggle these responsibilities, day in and day out? This was the topic of our recent Real Talk, an event series that provides space for speaking openly and candidly about the challenges and successes we experience in the workplace, including what it’s like to identify as a member of an underrepresented group.
Our most recent panel discussion featured Rachael Stedman, Bella Kazwell and Kate Reading from our San Francisco office, and Rachel Miller from our New York City office. Here’s what they had to say about empowering yourself and your teams as an engineering leader.
Bella Kazwell, Core Features Engineering Lead: I joined Asana seven years ago as a Product Engineer. Since that time I have been a program lead, a manager, and now the core features engineering lead. I run mobile, client framework, and a part of the web engineering teams. The best analogy for how I see my role is curling. I smooth out the ice so that the stone can move in the right direction. This means that I work behind the scenes coaching my team on specific skills, helping them prioritize their work, and clearing obstacles.
Rachel Miller, Engineering Manager: I’ve been with Asana for six years. I was Asana’s first new grad hire, coming straight from a masters program at MIT. I moved to the East Coast last July, and I am currently one of two engineering managers in our office in New York. We are focused on growing the team and shipping excellent products. I initially joined Asana’s Product Engineering team, specializing in growth teams before shifting my focus to people management on a wide range of projects. I’ve been managing engineers at Asana for about three years and managing engineers in New York for the past year.
Kate Reading, Engineering Manager: I’ve been at Asana for five months. I support our API team and our Platform Apps team. The teams I support have really strong technical leadership in places, but are growing and changing. I am new to our stack and I have a lot of responsibilities, so I’m focusing heavily on helping my teams become stronger and helping the leads grow in their leadership roles. For my extracurriculars, I’m getting involved with growing our engineering brand (I’ll be speaking at Tapia and Grace Hopper this year), and working on programs that will positively benefit our women, trans, and gender non-conforming engineers, and evangelizing our company values.
Bella: I love it when my cup is full and overflowing, so delegation has become a key tool for me. With delegation, I know I can’t shadow the person in what they are doing, which means I need to communicate the exact expectation, how much freedom the person has in decision making, and what success looks like. By trusting this process, it allows me to make smart compromises. I don’t have to second guess every decision this person makes, which in turn allows them to grow because they know what clear success looks like. It also provides a coaching opportunity for me, because I’m not giving them a solution—they can tackle the challenge on their own and give it the appropriate time and energy required.
Rachel: I think about growth and development as a tool to cultivate ownership. The more responsibility you give someone, the more ownership they have. Asana provides a wide range of growth paths for engineers. They get to really think about the details of what they want to do, instead of feeling like there are limited ways for them to have high impact. Having clear goals and direction are important tools as well, so that each person knows what success looks like and how to get there.
Kate: Our Areas of Responsibility (AoR) system helps people take ownership and make an impact outside of their program teams. We have them for everything from Scala, to testing to our Open Source presence, to team camaraderie events. Owning an AoR doesn’t mean that you have to do all the work for it, but it means you hold the context and ownership. Things often fall between the cracks of teams and departments, but AoRs prevent the head of an organization from owning everything, giving everyone on the team the autonomy to make change happen, along with credit for the impact that they have.
Bella: The people who report to me are different than I am, so I shouldn’t coach them into following my career path. Not everyone wants to be a program lead or a manager. Sometimes they just want to be really strong technically, so I need to support them in reaching that goal. I am consistently connecting with my team about their goals. I look at the work they’re doing, what their strengths and challenges are, and what excites them. I then relate this back to the needs of the larger organization and how we want to evolve, and from there, I play matchmaker, which is one of the most rewarding parts of my job. It’s important to think about what aspects of a new responsibility align with the person’s growth path, and then make sure we are intentional in making things happen.
Rachel: To me, career growth is helping people have broader impact in the work that they do. With career growth, goals are very important. Goal setting often connects someone to both the external and internal reasons they’re doing work, which is crucial for motivation. I find that goal setting draws in opportunities and allows you to have a clear ask of those around you. It also feels awesome to have a measure of progress—real growth isn’t linear and isn’t always measured for you, so you need to find your own way of feeling good about what you’ve done.
Kate: Some people know exactly what they want, and some people don’t. What I’ve been thinking about recently is how I can make it more concrete for them by asking the right questions to draw out their goals. For senior engineers that are becoming team leads, I’m helping them figure out how to delegate, and how to create a strong team out of a group of people. For senior engineers who are going down the more technical path, it’s more about balancing their own need to focus vs. spreading their knowledge to their team. What patterns and technical investments need to be made in the code base? What is the scope of influence they want to have and how do we make that happen?
Bella: Managing managers is hard—the work is a lot more opaque. With an individual contributor (IC), I can check out their code reviews or read their design documents, but with managers I can’t sit in on their 1:1s to see how they’re going so we can support their reports better. One of the things we look for in managers at Asana is people who are self-reflective and growth-minded. So my manager reports will often bring up things that they think they can improve on, and they’re very open about it.
Rachel: My new role in New York is my first time supporting multiple programs, and that’s given me a range of challenges. Lately I’ve been focused on balancing how much structure to suggest to teams I work with: how much planning they need to do and how quickly they need to be reflecting vs. executing. One thing that I’m working on is giving more transparency to other managers into what I’m focused on, the challenges I’m seeing, and what my approach to addressing them is. As a manager, I wasn’t used to giving that visibility outward and upward, but it’s important context to share and has allowed me to get more feedback and confidence on my plans.
Kate: I’m working on balancing my personal growth between technical and leadership impact, and figuring out what the right opportunities are that will give value to the company, the engineering organization, and myself. I’m also working on saying no to more things. One of the things I’ve enjoyed the most, both inside and outside of Asana, is building up my cohort of peer engineering managers with whom I can be totally real and share lessons, triumphs, and failures. I’ve joined some engineering manager Slack groups, and Rachael Stedman (who moderated the panel) has organized some small dinners. I also have an engineering manager team at Asana that I meet with every week. Especially as a new manager, having multiple touchpoints and ideas for how to get better at the craft of leadership in this type of role has been invaluable.
Bella: I recently took over as the Mobile Engineering Lead, and I decided to manage a lot of the ICs directly for some time. I’m really glad I did because it gave me the opportunity to really get to know the people, their strengths, and where they are struggling. I really care about them as people, and I’m invested in their success.
Rachel: Personally, I got a dog! Professionally – I’m loving the intimate feeling and new challenges of growing a tiny office. I love the pull of helping to hire and then help teams gel with lots of new engineers – it’s been pretty amazing to feel the growth really tangibly.
Kate: The best decision I’ve made was joining Asana. But the key point here was that I was able to identify the moment where a new challenge would help me leap forward in my own growth. I feel like I picked the right moment to make a change, and even though I’m doing a whole bunch of learning and growing at once, I feel both challenged and supported.
Interested in working with Kate, Rachel, and Bella at Asana? We’re hiring for technical roles in San Francisco, New York, and Vancouver!