This article was first published on Medium.
My time at Asana was different from the beginning. Not only did it take me a year to finally wrap up the recruiting process —having stopped and picked it up again over the months — it was a fall Internship — meaning I skipped a term of school to work in San Francisco and with no other interns.
Oh, boy! Let’s zoom back to the first day. I knew what to expect going in — it was going to be the same story as always. One organizational meeting after another, until I get handed a laptop, told that I probably shouldn’t expect to get anything done for the first week.
Remember what I said about it being different? Here’s a glimpse at what my Asana onboarding project looked like on the first day:
Imagine if there were a meeting for each one of these, and that’s the first-week flow of many companies! There are a couple things to note here. Not only did this quickly get me familiar how Asana uses the product internally (the word ubiquitous comes to mind), but it also let me do this at my own pace. It told my mentor exactly what I was stuck on and what I was speeding through.
Alright — great — set up. Time to start coding, right? No, really, I mean it. Here’s my commit to master on Day 1:
In a sentence, the rest of my experience followed suit. The deeper I got into my Internship, the more I realized that Asana’s values are more than just words strung together so they look good (they do look good). I’m not going to highlight everything that stuck with me, but there are a few things I can’t help but mention.
Transparency in action.
Look, let’s be honest: every company I’ve heard about claims they’re open and honest with employees. Living up to that is notoriously hard. At Asana, you can see internal financials, recruiting discussions, and the company’s Business outlook from day one. No fancy permissions for “hidden projects”. No “all-hands-except-interns” meetings. This wasn’t obviously a good thing at first glance: what if someone leaked some numbers? What if private conversations came into public light? After all, there is a lot of attention on these high-growth tech companies from the media.
After a couple weeks here, I knew why my fears were misplaced. It comes down to the fact that every policy is (can be) risky. It just happens to be the case that folks here at Asana place more value on empowering individual employees to participate in discussions than everything else. If everyone feels trusted, valued, and empowered, it’s easy to stop fretting about the smaller things.
Learning as a team.
Over the last couple of years, I’ve come to appreciate the interest companies take in helping employees learn and grow at whatever they may do — engineers, designers, writers — but also as people. I think Asana takes this learning mindset to a different level.
Rather than simply concentrate on helping people do their jobs better, Asana is focused on figuring out how the team and company can consistently improve processes to achieve goals. The key insight here is that a team of intelligent people stuck with poorly thought-out processes falls victim to that weak link. In action, this looks like:
5 whys:
Before joining Asana, I wrote something about how humans are susceptible to the “XY” problem — a rephrasing of the tunneling effect — citing the solution as: Ask why 5 times.
Turns out, Asana lives this ideology. When something goes wrong — be it unusually high-recruiting load, a significant Engineering failure, or simply missed deadlines — the team gathers to discuss. What went well? What broke? What are the actionable items? Not only does this help to set a clear understanding of the situation, it prevents unnecessary blame from being thrown around. It stops fragmented communication between teammates about a problem. Fragmented communication is miscommunication.
Roadmap Week, KRs
Being a fall intern was a blessing in (heavy) disguise. Not only did I start on the week with the most exciting recent launch (a redesign of the product), I also learned how Asana thinks about organization.
Before I move on to the concrete process, let’s take a look at the Planning Fallacy, first proposed by Daniel Kahneman. It’s quite simple, really:
Predictions about how much time will be needed to complete a future task display an optimism bias (underestimate the time needed). Kahneman and Tversky originally explained the fallacy by envisaging that planners focus on the most optimistic scenario for the task, rather than using their full experience of how much time similar tasks require.
If you have industry experience, you’ve seen every company and every team fall victim to this.
Now, the golden question: how do you fix it? The Wikipedia article, in fancy words, says “Implementation Intentions” and “Segmentation”. Really, this boils down to what Asana does at Roadmap Week.
Three times a year, every team at Asana gathers for a week to discuss how they’re going to approach the episode. Here’s where the team sets Key Results, publishing and presenting tangible goals as to what they want to accomplish over the next few months. The team is asked to imagine and create a story about how the world would look if everything went to plan. How would the world look if it was a disaster? At this point, you’ve gotta be thinking — this is just the act of costing. Every team does that!
Yes and no. The point here is that it’s purposeful. Of course, teams can do this ad-hoc at any given company, but it’s crucial that the processes support and facilitate it. This is not an opportunity for specific teams to think about the work they need to get done; it’s a chance for everyone to be on the same page about where the company is going.
People, first.
I’ve been using the words “Asana” and “the company” throughout this post, and that makes it so easy to lose sight of an obvious truth: The company is nothing more and nothing less than the people that make it so.
Most companies, somewhere down the line, lose track of this. In trying to build a “good culture”, they forget that employees evangelize. In trying to have “a fast moving technical team”, they forget that engineers have to constantly learn and grow. None of the goals of “the company” can be realized without the people that build and support it.
Asana is astonishingly good at this. There’s an emphasis on Work Life Balance. The perks, from simple things like a gym membership to mentorship and executive coaching, are centered about making better people, not better employees.
I’ve never been in a 1:1 where I’ve spent more than 20% of the time talking about work. The conversations are centered around how you’re doing, not how you’re working.
In a more subtle way, this extends to how Asana thinks about company structure. The trap of having an extensive hierarchy of managers and bosses is a tempting one. When you’re constantly worried about moving from SE1 to SE2, it’s easy to understand how the company prioritizes work more than your personal well-being. Asana’s system is (yeah, you got it — ) different. Asana is focused on giving individuals responsibility over real domains rather than just responsibility over a group of people. Any engineer — including new hires — can gain ownership of important parts of the company’s work, anywhere from AORs like “Onboarding Process” to “iOS Bugs”.
One last thought: maybe it’s telling that, in writing this post, I didn’t even think to mention what team I worked on or what I did. Maybe it gives you a little insight into how different this Internship really was. Although the technical aspects of my work were far from mundane, 5–10 years from now, I’ll look back and be thankful that this is what I remembered.
The post “4 Reasons why internship at Asana was different from any other other internship.” – by Kshitij Grover. appeared first on Student Resource - Learning Centre | Letsintern.com.