Introducing Asana’s Fall 2024 Release. Discover what's new.Explore now
Why I joined Asana: Kshitij Grover, Software Engineer
Welcome to our monthly “Why I joined Asana” series! Every month, we talk with Asanas across teams and offices to learn who they are and why they chose to pursue careers at Asana.
Kshitij Grover is a Software Engineer on the Infrastructure team based out of San Francisco. He is a huge fan of reading and working in cafes, always on the lookout for the perfectly lit spot in the nook of a cafe. In his time at Asana, Kshitij started a new team, LunaDb Framework. LunaDb is the data loading and reactivity system that most components of our system use to read data. Learn all about Kshitij, his team, and how he’s making an impact on #teamasana.
What was your journey to becoming a Software Engineer?
Before I graduated I had internships at a variety of companies, including Asana in 2015 working on mobile infrastructure. During my internship, I got to work on different projects ranging from shipping a feature on the iOS app, to working on our API. Asana felt like the right place to kickstart my career because I could gain visibility into how systems across the engineering stack worked, instead of staying isolated to my limited view of a single service.
I spent about a year on the Mobile Infrastructure team where I got to contribute to building out the mobile calendar, speeding up our API, streamlining mobile login, and transitioning Asana to a more reliable push notifications stack. From there, I transitioned to program lead of the Mobile Infrastructure team where I helped to scale team processes and onboard new engineers. I also worked on features like Milestones on mobile, Portfolios on mobile, and proofing (annotating attachments).
Recently I’ve spent the last year starting a new team: LunaDb Framework. LunaDb is the data loading and reactivity system that almost all components of our system use to read data. LunaDb Framework’s goal is to make our product engineers work faster, by polishing the system’s rough edges, adding framework features, and documenting and simplifying existing concepts.
Related to the theme of how we can move faster, I’ve worked on advising some of our New York teams on large data model migrations that reduce technical debt in our systems. My contributions here were, in large part, built on context I gathered from my work on mobile and LunaDb. Asana has been a remarkable place for me to grow as an individual contributor into a role where I can mentor other engineers.
Describe what a day is like in the San Francisco office
When we were working from the office, it was always super energetic. I loved working at a desk, especially when there were a lot of people around. Whenever I needed a change of scenery I would head to the co-working couches or the whiteboard area, to draw large maps and diagrams. These helped me understand what I was working on, and they invited questions.
I always got a lot of energy from the desk drive-bys and the daily coffee walks. These conversations are really where I got to connect with people outside of a formal 1:1s.
Although we’ve been working remotely recently, I’ve seen some of the office culture transform to a remote setting. I used to love the mobile team’s Friday happy hours. We would find a corner of the office and joke around about the week’s events—it was a really great, laid back vibe. Now, even remote, we’ve been able to continue this. Our team still does a daily end-of-day ‘hang time’ for a half hour. It allows us to unwind and have casual conversations outside of work. We’ve also extended our team standup so team members have more space to really ask questions and dig into their work.
What is something unique about the team you are on?
The LunaDb Framework team uniquely serves our internal Product Engineers, instead of building things that Asana’s end-users directly interact with. Knowing what will help other engineers move faster is still a hard problem, and it’s often difficult to judge whether the things you’re building are going to help until a few months after you’ve shipped them. Just like you can run user research to figure out what’s important to the users of your product, we try to do the same thing to learn about other Product Engineers.
Aside from my technical work, I organize the monthly Engineering All Hands meetings. It requires having a lot of context on what’s happening around the Engineering organization to curate and help speakers prepare their talks. So far I’ve revamped the agenda, changed pre- and post-event communications, and added different types of speakers and content. This experience has given me a broader view of the Engineering org and all of its moving parts.
How do you use Asana in your day to day work?
We use Asana for sprint processes and scheduling on our team, and I use it to schedule talks for our Engineering All Hands. There’s a central project that folks can follow where I’ll assign tasks with a due date, representing when that talk is scheduled to happen. In this way, it becomes a lightweight announcement system. Closer to the event, I’ll assign an expected time, so it doubles as a schedule. It’s also a great way to make explicit announcements. I use status updates in a project to communicate updates on our top-level goals.
What does Asana’s mission mean to you?
I love how Asana’s mission is focused around helping others collaborate better. I’m also a big believer in the claim that our Co-founder and CEO, Dustin makes—that nothing difficult is done alone. This convinced me to join Asana because I know that even the small changes I make to improve people’s efficiency will make a huge difference across organizations.
What are some of your biggest learnings at Asana?
Every year I compile a list of the top lessons I’ve learned. Here is my most recent list:
Constructing a growth plan is hard. In the right environment, persistent curiosity can be a sufficient replacement.
Assume everyone is entirely too busy. This should affect how you write, what you ask, and what you deliver.
Holding others accountable may be helpful, but you should be willing to shoulder the ensuing burden of change.
It’s said that you shouldn’t mistake motion for progress. This doesn’t mean you can ignore the value of momentum.
If you’re pessimistic and loud, you’ll be right. It’s all too easy to look predictive of the future if you say it’s going to be horrible and you’re vague about the consequences.
Start big conversations but make sure you end up with small steps.
It’s much harder to clean up a system before you’ve added to its mess.
Convincing others to take on responsibility is not disingenuous; in fact, it can be your biggest lever.
Long projects require constant, uncomfortable adjustment, not just up-front careful planning.
Understanding the constraints imposed by the local context is a much harder problem than applying the general engineering principle.
Don’t mistake the most solvable problem (or the problem you can solve) for the most important problem.
What’s your mantra and where did you first hear it?
One mantra I aspire to is simply, Keep moving. I’ve been able to grow and succeed at Asana by staying curious and moving around from project to project. It’s allowed me to gain a large variety of knowledge and context.
I do struggle with it, though. I find it very easy to get caught up in the past mistakes. Maybe it’s something small like, why did I phrase my feedback like that? or something that hits harder like, why did I ask the team to invest in this project without understanding its consequences?
In all of those moments, I have to make sure that I keep moving. That’s not to say we shouldn’t learn, assess, or reflect, but to me, those are all still forms of movement. I always try to be mindful about how much time I spend looking at past mistakes. I think the best thing to do is pick myself up and use my learnings to gain momentum.
If you could give a new Asana one piece of advice, what would it be?
Something I’ve learned over the years is that building relationships with your co-workers makes you more effective and also makes your work more enjoyable. I often think about the Annie Dillard quote, “How we spend our days is, of course, how we spend our lives.” If you’ve joined Asana, you’ve joined a dedicated and hard-working team that keeps it fun and real.
Work with Kshitij—join our team!
Check out opportunities to join the Engineering team. We have open roles in San Francisco, New York, Vancouver and Reykjavik!
