At Asana, we love applying mindfulness to our culture. As the engineering team has grown, we’ve identified a need to clarify the key attributes that are the foundation of our engineering culture. We particularly wanted to come to consensus around the following questions:
- How do we excel as engineers?
- Where should we focus our feedback to each other on how to improve?
- What are we looking for when we evaluate engineering candidates?
What we’ve come up with is a list of suggestions for how to be an effective engineer at Asana. Along with the broader Asana values, this list is our best attempt to make transparent the virtues we hold dear. We believe these are highly resonant in our culture, although some are more established than others. They’re inspired equally by our accomplished leaders and those who are just getting started.
This is intended as a guide to all who want to succeed as Asana engineers, but we understand that all values have a counter-value that contains its own wisdom.
Not sure where to start? Learn with curiosity. Struggling to get it all right? Strive for simplicity. Want to move forward? Articulate your mental model.
Not sure how to lead? Teach with compassion. Trying to win the marathon? Ship fast, sustainably. Need to inspire others? Fix problems, even when they’re not yours.
We’re excited to share the Asana engineering team’s values with you. What are your team’s core values?
Learn with curiosity
By Sri Raghavan, Product Engineer
Maintaining a learning, self-driven mindset is crucial to being a good engineer—whether you’re a newbie or have ten years of experience. When you join a new company, you will be working in an unfamiliar codebase. Once you settle in, you’ll be solving problems for which no one already knows the full solution.
When you become an Asana engineer, you’re paired with an onboarding mentor, who’s tasked with making sure you’re able to quickly ramp up and never blocked. My onboarding mentor, Cliff, helped unblock me. More importantly, he helped me learn how to unblock myself. He encouraged me to jump in and learn about things (how a particular framework works, where performance pitfalls lie, etc.) instead of simply asking for answers. Asana engineers take responsibility for their own growth and empower themselves to become better engineers.
We even encourage ourselves to continually look for new areas of expertise we can grow into. Opportunities like Polish Week, Grease Week, and Hackathons allow us to jump into unfamiliar parts of the codebase, work with new people, and learn new things. We change teams often enough to learn new approaches that we can in turn bring to other teams.
At Asana, we view failure as a crucial step towards success and an opportunity to learn. When things don’t go as expected, we practice an exercise called “Five Whys”, which encourages us to analyze a problem with a curious mindset without blaming.
What had to happen to create this situation? What can I learn from this? How can I shift my behavior going forward?
Strive for simplicity
By Dominik Gruber, Mobile Engineer, and Eric Pelz, Product Engineer
When contributing code, we always ask ourselves the question: “Could this be simpler?” Striving for the simplest viable solution requires time and effort up front but pays off in the long run.
Simple solutions are easier to understand, especially since as our codebase grows, we often spend more time reading than writing code. Having code that’s easy to reason about enables us to more quickly spot bugs and make modifications with confidence.
One way we practice manifesting simplicity is striving for functional purity in components, and by developing patterns that achieve this purity by default. Purity leads to more isolated and inherently simpler components, thereby bringing about a less-braided and simpler system.
By eliminating complexity we are able to create a more correct, reliable, maintainable, and testable application, and therefore a better experience for our users. As Rich Hickey lays out in his excellent talk “Simplicity Matters,” striving for simplicity is the most important work that we do as technical designers, and it will make everything else substantially easier.
What is the singular purpose of this entity? Will my teammates understand my code? How much context is needed to understand this?
Articulate your mental model
By Jack Heart, Heart of Culture and former Product Engineering Lead
Deep in Asana’s essence is clarity. We serve to give organizations clarity into their work. We do it by getting clarity about our own work.
At Asana, every non-trivial project starts with a design. We share designs through Asana projects like “Design Docs” and “Data Model Changes” to allow all interested engineers to engage in discussions about them and ask questions. We’re able to share wisdom and patterns effectively even across teams that don’t share code directly, and we can use these documents to jump start plans for future projects with related purposes.
Articulating our mental model helps us ensure that we understand the logic of our own ideas. It enables us to iterate faster than we can through writing and rewriting code. Once we’re clear on what we’re doing, we implement without needing to regularly check that what we’re building still makes sense.
What are the goals of this project? How does your solution achieve those goals? What are the implications of your choices?
Teach with compassion
By Marco Gallotta, Infrastructure Engineer and Manager, and Allen Li, Product Engineer
Teaching with compassion means sharing your knowledge and realizing the leverage of empowering your teammates. It’s not making someone feel inferior for not knowing what you know, it’s giving them the patience they need to make progress. To do this, we strive to understand from the learner’s perspective. Where they come from, what their learning style is, and how they absorb information are just a few salient elements we consider in our teaching.
We place a huge emphasis on mentorship, which results in a focus on teaching (and, consequently, learning as well). Not only do people care about mentoring others, we believe that everyone has unique knowledge and experience which they can impart with others. From onboarding buddies to managers to interview mentors, we look for every opportunity to create helpful relationships.
But, more importantly, our base assumption is that we are all mentoring each other all the time. We understand that there are multiple axes of skills and that we all have something to share and room to grow.
What would help this person grow? What might I take for granted that they don’t know? How can I have wider impact by empowering others?
Ship fast, sustainably
By Cliff Chang, Product Engineer and Manager
Shipping code is the most visible way that Engineering contributes to the success of Asana, and this value is at the core of how we ship.
Shipping fast starts with serious investment in tooling, like continuous deployment with multiple pushes per day. Our developer experience team measures success by minimizing the amount of time engineers spend waiting for tests to run while maximizing test coverage. Shipping fast takes focus and flow, the kind you get during a No Meeting Wednesday.
But shipping fast sustainably takes more than just effective work. Study after study shows that people, especially in creative jobs like software engineering, will actually get more done if they work fewer hours. When we’re focused, we write higher-quality code, and higher-quality code means less technical debt, faster iteration, and less time fighting fires. While lots of hours in the office lead to the illusion of a lot of work, it often results in a lot of energy spent just treading water.
This is a long-term investment. We have a lot of friends and peers who have quit Silicon Valley entirely after being burned out after very short careers in software engineering. That’s a lot of experience, mentorship, and leadership that gets taken out of our community because we have the pervasive misconception that shipping fast means working unsustainably. Software isn’t going anywhere, and Asana’s engineering culture aims to support people to work well for decades to come.
Do you have enough energy to be creative? Are you regularly achieving flow? What tools could make you more effective?
Fix problems, even when they’re not yours
By Rachel Miller, Product Engineer and Manager
Company problems fall into a few categories: problems you recognize as your own, problems you recognize as other people’s, and problems that don’t clearly belong to anyone. Fixing your own problems is easy: You’ve got context on them, and fixing them gives you pride in your work. At Asana, problem solving goes beyond that.
We value seeing problems beyond your own scope and getting them fixed—we’ve all got 100% responsibility for everything at Asana. This is an engineering instantiation of some of my favorite company values: egolessness and a company as a collective of peers. We’re all responsible for suggesting our next move. At Asana, I feel encouraged to see what could be better about the company; I feel empowered to strive for change I see as positive and to do the work necessary. We request ideas from the whole company for what our product roadmap should look like and how we can improve both Asana the product and Asana the company.
Within engineering, we manifest this in ways like refactoring code as we encounter it, in having all hands on deck to fix performance issues (which are notoriously difficult to pin down responsibility for!), and having several rotating on-call systems for things like our infrastructure, desktop product, mobile apps, testing systems, and helping developers fix their tooling.
We also put energy into trying to say “Thank you!” well, through our traveling Narwhals and Unicorns program. Each week, a group of “traveling” stuffed narwhals and unicorns make their way to a different co-worker’s desk along with words of gratitude about a recent achievement or contribution. Whoever receives the narwhal decides on the next recipient, helping us consistently share gratitude across the entire company.
What opportunities do I see? Do I think they should be prioritized? Am I equipped to act, or what do I need to see this accomplished?
What are your team’s core values? Tell us about them in the comments. If these values resonate with you, we’d love to hear from you.