We're proud to be recognized as a Leader in the 2024 Gartner®️ Magic Quadrant™️ for Collaborative Work ManagementGet the report
Welcome to “Why I joined Asana”: a monthly series where we talk with Asanas across all our teams and offices—from Dublin to Sydney—to get to know the people inside the company and learn why they chose to work here.
Engineering Managers play a distinct role at Asana. They think strategically and enable their team to grow and succeed, while Program Leads focus on the more technical aspects of building our product. Mentors provide another support system that help our engineers tackle challenges that further their careers.
Kate Reading is an Engineering Manager on our Platform team in San Francisco, working on users’ holistic experience of Asana and beyond. Read more about Kate and her journey to becoming a part of #teamasana.
I first heard about Asana at a Girls Who Code event, and then looked online at Asana’s profiles on places like Key Values to learn more.
During my interview process I had such great conversations—about managing conflict, about career growth for engineers—and I felt heard and appreciated for the way my background was different. The Engineering leadership team, and specifically Bella Kazwell , who was the first person I talked with in person, had imagination. I went into the interview process and was honest: There are some things I have a lot of experience with, and some things you’ll be surprised I haven’t done. And the reaction was, “OK, cool, let’s talk through that and see what makes sense.”
The AoR system is really cool because it gives you the opportunity to invest in something that’s important to the company and make it a part of your job.
I’d read some articles about how Asana tackled the really thorny technical problem of moving from luna1 to luna2 (an old technical stack to a new one), and it was so interesting to read about how they tackled the issue of needing to make some important engineering investments, but still needing to make business investments in the product. During my interview sessions, I also got to hear about the Data Model Success team, hearing examples of how Engineering is investing in engineering. Plus, Asana has really good retention for engineers, which was a great sign.
Asana serves fantastic three meals a day thanks to an in-house Culinary team, but when I first started interviewing, this made me really concerned about work-life balance. Does the whole Engineering team stay really late? Will I be expected to? But the real goal is nourishing your body to fuel your brain, and there’s no expectation that you’re present for all of those meals. I leave before the 6:30pm dinner every day. One of the reassuring aspects of this to me was that there were several parents on my interview panel. Babies are celebrated on our feature delivery board, and when I got an offer, the team gave me a tiny t-shirt with an Asana unicorn on it for my daughter.
I’m an Engineering Manager, so my first priority is making sure that the engineers on my team are engaged and growing in the way that they want to grow. After that, I’m thinking about our strategic next steps for the apps team. And I’m thinking about what areas of responsibility (AoRs) I want to get involved in. The AoR system is really cool because it gives you the opportunity to invest in something that’s important to the company and make it a part of your job. That can be a technical goal (e.g. developer tools, our Github integration) or a non-technical one (e.g. interview process improvement).
My team is in the Workflow product pillar, which has us thinking about the user’s whole experience at work—what are the tools they use, who are they trying to communicate with? Having had the experience of trying to manage my own workflows and to-do lists in multiple different tools (Slack, email, Github, to name a few), it’s really interesting to think about how we can we integrate those different pieces of work into one place.
I’m really excited for the mix of thinking strategically and thinking tactically. I’m not leading the execution of features; the Program Lead Engineer and the Technical Lead Engineer are doing that. So I get to observe and think about ways that I can help the team help themselves.
There are a lot of other Engineering Managers to learn from and share perspectives with, but they’re also interested in learning from me. At my first Engineering Managers meeting, we dug into some deep topics, and because my background is different, I have some different ideas to offer and was able to discuss these openly with the group. Part of this comes from Asana’s commitment to Conscious Leadership training, which the company offers to everyone, not just managers.
I’ve always been someone who loves thinking about how I organize my work. It’s really interesting to be working with a product whose goal it is to be my work dashboard. There’s no checking multiple tools to figure out if there’s anything new in there.
I love working at a company where we use our own product. All the beta features are at my disposal, which is really fun because I can play with the new things as they’re being designed and tested. And I can put myself in the shoes of our users, feel their joy and their pain, and learn that not all users are like me.
I’ve always been someone who loves thinking about how I organize my work—I bullet journal, I love personal kanban, I use custom inboxes with Gmail, the list goes on. In previous roles, I’ve used all kinds of different tools to prioritize and organize my work. It’s really interesting to be working with a product whose goal it is to be my work dashboard. It shows me the things—from every source—that I need to take care of. There’s no checking multiple tools to figure out if there’s anything new in there.
I worked as an in-house software engineer for the federal government for over a decade. I started not long after September 11th, which was a time of a lot of growth in the government, and because of that, it provided me with a lot of opportunities for leadership early in my career. I worked on some things that became flagship products for my part of the organization, and became a subject matter expert. I solved problems that we weren’t sure had solutions, I took advantage of lots of opportunities for leadership training and attending technical conferences, and I got to travel all over the world.
As my sphere of influence grew in the government I got involved in setting the technical direction for larger teams, but I was also starting to hit my own growth ceiling there.
I left the government in 2016, for a new adventure in San Francisco. For two years I worked at Lever where I got deep technically again, and then got involved in technical leadership again. Now I’m excited to manage a team and help them grow in the ways that mean a lot to them.
“You can’t sell someone the solution until they’ve bought the problem.” I feel like this is one of the most important lessons I’ve learned in my career. I got a lot of practice with trying to introduce novel ideas when I was working in government, and just believing that you’re right isn’t enough. You have to understand where other people are coming from and whether they see the same challenges that you do before you can work together to implement a new way of doing things.
We hired you for a reason and if you don’t know what it is, ask. Don’t lose sight of it. There’s this balance between sitting back and learning the culture and the perspectives of those around you and then offering up opposing opinions. Also, bring it! Your unique experience and ideas are why you’re here!
Come work with Kate and the rest of the Engineering team, in San Francisco, New York, and Vancouver. We’re looking for passionate, creative people to help us grow. Check out all our open Engineering roles!