Category Archives: Engineering

Yesterday’s downtime

Prashant Pandey, Dustin Moskovitz, and S. Alex Smith

Asana had a service interruption for approximately 90 minutes on Wednesday. We want to apologize, as we know your team relies on Asana and lengthy outages can majorly disrupt your workflow. It is our top priority to ensure Asana is up and running securely for you and your team, and we take these issues very seriously.

Whenever Asana is down or experiencing performance issues, we immediately dedicate engineers to fix the problem. We also aim to keep you as informed as possible–you can always check our status page and Twitter for up-to-date information. We also work to identify the root cause, so we can prevent the same issue from happening again.

We’re still investigating this outage, but we believe the root cause is related to transient connectivity issues between our app servers and database/cache servers. The most important complications we experienced yesterday have been resolved, so we don’t expect another serious interruption. However, the underlying network connectivity issue remains, and we are working closely with AWS to address the issue. This will be our top priority until it is fully resolved. Looking ahead, we do agree that offline access to Asana would be helpful, and this is on our long-term roadmap.

We apologize for the downtime yesterday. Thanks for your patience.


Building Asana’s foundation

Kasey Fleisher Hickey and Prashant Pandey

When software just works, it’s largely thanks to solid infrastructure. For Asana, a top priority is ensuring that our service is built on a foundation that is reliable.

Our infrastructure team operates behind-the-scenes to ensure that your team runs on Asana, every day. The infrastructure team’s efforts enable Asana to be secure, allow us to add new functionality without breaking things in the process, and pave the road for millions of intricate connections between people, tasks, teams, and projects. We’re focused on making a product that you can trust and we want to make sure the most talented people are working on its framework.

We recently welcomed the newest member of our team, Prashant Pandey, to help us take our infrastructure efforts to the next level and in turn, support growth across our product, team, and user base.
Read More

The new collapsable left pane: Happier laptop users and a streamlined experience

Andrew Watterson and Alex Davies

Over the last few weeks, we’ve rolled out a new design for the left pane that makes always having just the right data on screen much more seamless. People using smaller screens can now focus and navigate much more easily, and now everyone has more ability to collapse the parts of the Asana interface they don’t need.
Read More

Asana on Internet Explorer

Asana comes to Internet Explorer

Jennifer Nan and Greg Slovacek

Asana is the place for teamwork. We reduce your team’s frustration with email overload and the friction of trying to keep everyone on the same page while pursuing team goals. By putting conversations and tasks in a single place, Asana helps your team get more done with less effort.

Today, we’re excited to add Internet Explorer 10 to the list of browsers Asana supports. This means if you’re using the latest version of Chrome, Firefox, Safari, or IE, you can communicate and coordinate with anyone on your team.

Read More


A lost & found for Asana: New features to make tracking tasks easier

S. Alex Smith and Josh Smith

In keeping with our goal of making Asana the best place to track all of your work, we will be rolling out two new features in the next few weeks to help you keep track of task changes.  Soon, you will be able to recover deleted tasks and track changes to task names and descriptions!

Deleted Tasks View

Have you ever accidentally deleted a task? Searched for a task you know you created and just couldn’t find it anywhere? We have a solution for you: a Deleted Tasks view!

Read More

Introducing Asana Connect

Isaac Wolkerstorfer and Greg Slovacek

Just under a year ago, we launched an API to allow developers to build new tools on top of Asana. Since then, we’ve seen companies and independent developers use the Asana API to integrate Asana and their internal tools, add features like time-tracking and reporting dashboards, and even build separate products.

But until today, the only way to grant another application access to your Asana account was to use your API key.

Today, we’re introducing a better way to authorize other applications to use your Asana account: Asana Connect.

Read More

Asana Search Views

David Braginsky, S. Alex Smith, Jackie Bavaro, and Stephanie Hornung

Imagine if, with one click, you could answer the question “What work is due today for everyone on my team?” or “What are all the tasks that are more than a day behind schedule?” Wouldn’t it be amazing if you could get that information without having to ask for it, even if you hadn’t been on the original email threads?

Today, we’re excited to announce Asana Search Views – a powerful new way to manage the work you track in Asana. Search Views take the power traditionally found in more complicated, specialized tools and deliver it with the same focus on simplicity, usability, and design that we bring to the rest of our software.

Read More

Release the Kraken! An open-source pub/sub server for the real-time web

Kris Rasmussen

Asana Kraken

Today, we are releasing Kraken, the distributed pub/sub server we wrote to handle the performance and scalability demands of real-time web apps like Asana.

What problem does Kraken solve?

One of the key promises of real-time web applications is that users will see changes made by other users as they happen, without hitting reload or refresh. Many of the up-and-coming reactive web frameworks initially accomplish this by periodically re-executing queries against the database. When we were building the early prototypes of Asana, our reactive framework (Luna) was no different.

Unfortunately, most production-ready databases, from Mongo to Mysql, are unable to keep up with the query volume that even a moderate userbase creates when you frequently poll the database for changes. We recognized this problem early, and worked around it by designing an algorithm that incrementally updates queries in real time without putting any additional load on the database server. Key to this solution is the requirement that every query be notified about changes to objects that could potentially match, or stop matching the result set of each query.

That’s where Kraken comes into play. Kraken is responsible for routing data-invalidation messages between the processes that are running these queries so that they stay up-to-date.

Why is Kraken the right solution?

Before building Kraken, we searched for an existing open-source pub/sub solution that would satisfy our needs. At the time, we discovered that most solutions in this space were designed to solve a much wider set of problems than we had, and yet none were particularly well-suited to solve the specific requirements of real-time apps like Asana. Our team had experience writing routing-based infrastructure and ultimately decided to build a custom service that did exactly what we needed – and nothing more.

The decision to build Kraken paid off. For the last three years, Kraken has been fearlessly routing messages between our servers to keep your team in sync. During this time, it has yet to crash even once. We’re excited to finally release Kraken to the community!

You can get Kraken yourself at Github

If you want your new engineers to hit the ground running, give them a soft landing

Greg Slovacek

This is the status quo at many a fast-moving startup: new engineers plunge into their positions bracing for a harsh reality. Fresh from an environment in which they were confident in their day-to-day work, they must hope to succeed in spite of gnarly legacy code, inadequate documentation, unintuitive raw tools and processes, and co-workers that help only reluctantly (if at all) because they are too busy. It is an awful first impression.

But paying careful attention to the on-boarding experience pays dividends, and is a key to transforming new engineers into strong, effective contributors. Positive patterns are easier to establish early on, not once the engineer has settled into a routine.

At Asana, we strive to build a culture centered on focus, productivity, growth and development—and that starts on day one, not some unspecified time when you become a “real” employee. We’ve put a lot of thought into our on-boarding process, which we’ll lay out below.

Minimize Chores

The first step is to remove as many rote tasks as possible from the new engineer’s list of responsibilities. We want him or her to focus on being a member of the organization, not on doing chores.

To facilitate this process, we have all of the components of their workstation acquired and set up ahead of time. We give them a $10,000 budget to customize it and then get them what they need before they show up. In the days before their first day of work, we set up their desk, install a standard disk image and run a standard setup script on their machine. All that’s left are the unavoidable personal customizations.

The goal of the whole operation is to ensure that the engineer doesn’t spend most of their first day “setting up their workspace.” We have much bigger plans for them.

My Buddy And Me

Those bigger plans start with a buddy. Each new engineer is paired up with a colleague with at least several months of tenure at Asana. For the next few weeks, this buddy will be be the primary person responsible for the new hire’s experience.

The buddy system provides benefit in two ways:

  • New hires never have to wonder “who should I ask” and “is it worth taking this person’s time?” When we pair the new engineer with his or her buddy, we clearly communicate that we expect the buddy to spend a significant amount of time and energy on the onboarding process. Meanwhile, we give buddies the leeway they need to reduce their other commitments.
  • It puts a single Directly Responsible Individual in charge of the new hire’s experience. Because buddies are invested in the process, they notice when the new hire is struggling with a problem. They facilitate discussions with experts on the team. They spend extra time pair-coding. Since someone is tasked with paying attention, it’s much easier to optimize the experience.

The buddy system also creates explicit opportunities for the new engineer to give feedback to the organization. New hires provide unique value: the ability to see the organization without the curse of knowledge. They cycle in new ideas and help prevent institutionalized biases. Valuing a new hire’s opinions early on sets the tone for their future contributions.

Adding Value On Day One

We have a rule at Asana that all new engineers must ship something on their first day. It could be a tiny product improvement, or a fix to a bug or a typo—anything. But it has to get out to production.

This practice is part of a commitment to continuous deployment and is inspired by other companies who have done the same. The rule serves multiple purposes:

  • Demonstrates the entire lifecycle of a change to the software, from idea to launch.
  • Provides confidence to the new hire around putting code in front of users. The worst that happens is something actually breaks, the code is quickly reverted, and everything’s okay again.
  • Re-enforces the culture of continuous deployment within the organization, which has many of its own benefits.

Meet the Tech and the Team

A lot of what we accomplish together is grounded in trust and in our working relationships. Good tools (like Asana) facilitate these relationships, but are not replacements for them. We kickstart our fellow engineers’ effectiveness by seeding their relationships early on.

During the new hire’s first few weeks, the buddy schedules a series of learning sessions on various engineering topics, such as a walkthrough of our codebase, our cluster architecture, our datastore, reactivity, our testing framework, and so on. Each session is a one-on-one with another engineer.

Like many processes at Asana, the functions of these sessions are stacked, yielding many different benefits from one activity:

  • The session leader and the new hire get one-on-one time to discuss something technical, establishing a relationship.
  • The session leader gets to exercise being an authority, a component of developing leadership.
  • The new hire gets high-quality information about a topic highly relevant to their work.

Of course, to scale our knowledge transfer across all employees (not just new hires) we also maintain a solid base of internal documentation. And each new hire is assigned one of the sessions that had inadequate written coverage, and cooperates with the expert to write up what they’ve learned. This process distributes the onerous chore of documentation, and helps us build our knowledge base over time.

The Starter Project

After a new hire has been exposed to an organization’s principles, tools, and and processes, there is often still a sizable gap between learning and synthesis. Many organizations are content to let this gap close incidentally, in fits and starts, wherever the engineer happens to be focusing their attention at the moment. While prioritizing learning based on needs is a passable default, we think introducing some core concepts in a safer environment can be more effective.

To that end, every new hire gets the same starter project: to build a small chat application using Luna, our in-house framework. They are expected to spend about 2-3 days working on it. The project is fairly open-ended, though the engineer is given lots of hints about things they can try building.

We designed the chat project to expose new engineers first-hand to many of the core concepts of building an application on our framework. The project’s open-ended nature allows engineers to direct their own exploration of the system. Since building a chat app on Luna is very similar to the day-to-day work on Asana, the skills the new engineers learn are directly transferrable. However, because the scope is much smaller and the environment more controlled, the engineer can learn the concepts more easily, without distraction.

Great Success

The benefits of our approach are real: our new engineers tell us that they were invigorated by their on-boarding experience, instead of exhausted, and they are excited by how quickly they become productive. Though our on-boarding process requires a lot of upfront energy, we’ve found that it pays to think carefully about how a new engineer is introduced to the organization, and how the experience might shape their mental model of the company.

They are, after all, its future.