Asana

Especially for a company of Asana's size, the engineering processes and systems are refined and intentional. There are a few things that stand out in terms of helping engineers grow:

• Engineering design process
• Incident response and learnings
• Distribution of responsibility

Building a framework around writing, reviewing, and approving engineering designs requires a delicate mix of autonomy (so engineers feel empowered) and guidance (so engineers don’t feel lost or stuck). At Asana, there’s a support system to make sure that the author understands the goals of the project and is informed about the set of decisions they’re trying to settle. On the other hand, Asana doesn’t shy away from giving members of the team ownership over decisions and preventing an overly consensus-focused decision process.

Asana’s philosophy around the end-result is also different. Design docs are not intended to be internal-to-team-facing documented decisions. Instead, they’re a place for the entire engineering team (when relevant) to leave feedback and have a discussion. As a new engineer at Asana, you have the option to read docs and comment threads, even in areas of the system you're not directly involved in. This really helps you gain visibility into system architecture thinking (both current and historical trajectory) and exposes you to challenges and tradeoffs in areas you'd usually treat as a blackbox.

As any other company serving realtime traffic, Asana has its share of production incidents. Though there is a lot of work that goes into running that realtime response smoothly, the meat of interesting discussion happens afterwards in a post-mortem. Asana is mindful about when having these in-person post-mortems are useful and doesn't do them as a matter of process obligation.

Internally, Asana has an “Areas of Responsibility” Asana project to outline who is responsible (i.e. often the decision maker or triage-point-person) for which area — technical and not. This helps newer engineers get involved quickly with technical decision making (less HiPPO effect) and also avoids a cycle where people are using entirely cultural knowledge to figure out who has relevant context when working in a new system area.

Asana has some engineering debt on its hands. The company has been around for approximately a decade and has built some pretty complex things on its own, including a web reactivity framework and a GraphQL-like data loading system. Navigating that tribal knowledge can be tough at first, especially for engineers who are new to the core concepts.

As Asana grows, there is also some pressure being put on the current set of leadership and responsibility constructs on a team level. Teams are now being split into “areas of work” with separate eng, design, and product leads, which is a step towards helping alleviate that.

The biggest thing is to continue recognizing that engineers perform best when feedback (positive or negative) is immediate. So, more touchpoints are better. Generally, I'm happy with how responsive Management has been to concerns or general feedback.