Building Asana’s framework: Malcolm Handley

Over the last few months, we’ve given you a look inside the day-to-day lives of Asanas including Frank from our Sales team, Yev on Customer Success, and Phips on Engineering. Today, we’re sitting down with Malcolm Handley, a member of our Framework team. Malcolm is working on building the technical framework that Asana runs on.

Malcolm joined Asana six years ago as our very first engineer. Originally from South Africa, he made his way to the Bay Area by way of New Zealand, where he lived for 10 years. We asked Malcolm how he uses Asana for the most efficient grocery shopping experience ever and how many times per day he checks his Inbox (among other things).

Malcolm lives in the Tenderloin. It takes him precisely eight minutes to bike to work. He can be found on two wheels, rain or shine.

Daily life

Tell us about your daily routine. In the morning, I get up and do personal things, like browsing my email. I exercise, and then I make sure I get to work before breakfast is over (before 10 am). Then, I look at my Asana Inbox because if I don’t check it before getting into the fun stuff, it never happens. I go through my Inbox once a day, for two hours at most. And then I focus on real work for the rest of the day.

Do you have a lot of meetings over the course of your day? Besides daily team check-ins, our team strives for no meetings three days of the week to maximize our productivity. This means Thursdays and Fridays are packed but the tradeoff is we have confidence that we’ll be able to chip away at a significant amount of work without distraction the other days of the week.

Joining Asana

What brought you to Asana? Having left my previous position, I wasn’t sure what I wanted to do next. I was considering starting a company, joining a startup, or working at a lifestyle company. I was referred to our founders by a mutual friend, which was followed by a two-month-long cycle of courtship and rejection on both sides. I oscillated between wanting to work with Asana and doing other things, but eventually I made up my mind and joined. I was the first hire at the company.

Why did you choose to work at Asana? What was exciting about the company and product? After sitting at home alone tinkering for two months, I had concluded that it’s actually not that fun. I wanted to work on interesting things, things that were big enough that I couldn’t do them alone. I also wanted to work on something useful, and something that mattered.

Asana had (and has) a lot of interesting technical problems. Our expansive product vision convinced me that here was an opportunity to go after just about every product category that I thought was interesting. To be building something that would feed into and improve everything I cared about was the biggest reason I joined when I did.

Did joining Asana at such an early stage seem risky to you? Joining a two-person company is always a risk. In addition to sharing my excitement for the vision and technical challenges, I spent a lot of time talking to Dustin and Justin (our co-founders) about the role of management and how I could be involved in growing the company.

Growing the team & shifting roles

How has your role changed since you joined? In the beginning, we only had a little bit of code — 3,000 lines or something. You couldn’t even use the product! At that time, I worked on infrastructure, UI, and our framework. When we began hiring engineers, I mentored them a lot, showing them around the code. Then, I became a manager and stopped writing much code.

Recently, I moved away from my manager role and am focusing much more narrowly than I have in many years on upgrading our framework, Luna. I have shed almost all of my responsibilities outside of that.

Having gone back and forth between being an individual contributor and a manager, how do both of those roles resonate with you? Are they equally rewarding? The thing about being a manager is that there are many rewarding aspects, but for me they are rewarding in retrospect, not in anticipation. Personally, I get most excited about technical work, even if it includes more mentorship.

That said, I don’t foresee or wish for my focus to be this narrow forever. I’m enjoying the process of shipping something, supporting it, and then gradually spreading my responsibilities out again. It’s a cycle I enjoy being a part of.

What are you most excited about now? I’m excited about the package of three big changes we’re making: changing our server stack, our infrastructure running on the client, and simplifying and beautifying that client. By the end of this year we should have a whole new experience: it’ll be faster, more scalable, and prettier. I can’t wait to see that.

How does Asana’s culture compare to your previous experiences? What sets it apart? The two things that make Asana unique are our company culture and the fact that we have only good people working here. We focus on conscious and mindful debate about processes we want, how to achieve cultural goals, how to engage everyone, and how to distribute responsibility. Most important, I think, is how we manage conflict, agreement, and disagreement through things like coaching and feedback (both 1:1 and in groups). The result is something I never thought could exist: I don’t see politics, backstabbing, or dysfunctional behaviors.

These practices are so novel to me that they’ve even bled outside of my work life. They’ve improved me as a person, in how I relate to people, have difficult conversations, and achieve my goals.

Teamwork with Asana

Describe the team you work on. There are five of us, which is the biggest team that I’ve ever been on at Asana, and it’s the biggest Eng-only team. It’s challenging because we all have different work styles and energy levels, and we’re making a lot of technical decisions which we have to communicate and record. Luckily, we have Asana for that.

The challenge we’re up against is that we’re working on a lot of new components at once (the server, client), from scratch, which have to interact with existing components (databases, our app code), and are closely tied to various other teams. That’s what makes it interesting, though!

How has using Asana as an engineer changed how you work on a team? For a long time I dreamed of combining the work I was doing with the communication that was happening around it. Even before Asana, my fellow engineer, Greg Slovacek and I prototyped something similar, which included documents that could be edited and would then notify followers of changes.

I used other tools, too, but there was always another state, like a whiteboard, to accompany the software we were using. Product managers would come around and get you to update the content in the tool, but we all had our text files or whiteboards as well. Things came together but it was painful and invisible.

In my opinion, Asana is the first thing that has successfully combined the two, is usable, and team friendly. That’s a big difference and improvement. The way my teams at Asana have done their work is far more efficient than any other team I’ve been a part of.

Do you use Asana outside of work? Of course! At home, I use it for everything I’m trying to get done. One example is grocery shopping. I have a project with all my groceries, cross tagged into different projects based on the different supermarkets I shop at. Each supermarket project is organized by department, aisle, and wall.

What do you enjoy most about building Asana? In my opinion, there is no better way to live than writing products you use. It’s so nice to make improvements and get to benefit from them yourself. Beyond that, I don’t think I’d have the user empathy I’d need to make a product that I wasn’t using: the best way for me to understand how to improve a product is if I’m using it and feeling the pains, too.

I also really enjoy working on something that people use to help them achieve really meaningful goals. For example, I attend climate change events where I meet people who use Asana in efforts to protect our planet, which is really compelling. These encounters reinforce that I’m solving a meta problem that so many teams face each day.

What is a misconception you think people have about Asana? I think people think we’re not facing scaling challenges, or that we don’t have technically interesting problems.

I beg to differ: if you set out to write a high quality application in a labor efficient way, it’s very technically challenging. It’s also not how the world normally writes software, which creates even more interesting problems. I’ve been privileged enough to work on these problems and it’s been super fun.

Interested in working on these problems too? See our job openings here.