What is an Area Tech Lead at Asana?
Since joining #teamasana 4 months ago, it’s become clear to me that successful areas (groups of engineering teams with a shared goal) tended to have many things in common, including the presence of an Area Tech Lead (ATL). ATL’s have similar technical expertise to staff engineers at other companies, and they use that expertise to set their area’s teams up for success. They’re responsible for setting technical direction, mentoring team tech leads, and partnering cross-functionally to create their areas’ roadmap.
As a new director of engineering (internally, we call them “engineering area leads”) focused on the people & organizational strategy of the Coordinate Area, I quickly realized that hiring an ATL to partner closely with me would be a surefire way to level up the entire Coordinate Area. I checked in with several ATL’s across the company, looking to better understand their unique role at Asana. Curious what I learned? Want to get to know some of our ATL’s? Read on!
John Whelchel, ATL for the Align Area
What do your days look like at Asana?
My day-to-day is a mixture of work focused on supporting the engineers and Tech Leads in my Area on design and delivery, as well as broader, long-term work about technical and product strategy for the collective Area’s roadmap. Generally, I act as an internal advisor, an information router, and an external representative for the Area’s technical work. I often find myself moving between design doc review, code review, unblocking folks with technical or organizational challenges, pairing with engineering directors on staffing and skill needs, broad technical strategy work, and general team and relationship building.
What does success look like for you in this role?
I consider my role a success when teams are shipping high-quality work reliably, collaborating effectively with other functions and teams to help ensure we’re getting the best business outcomes we can, and are continuing to improve in those areas as we go!
Tell us about an interesting project you worked on in this role.
I’m currently working on a cross-cutting project to help improve our product engineer’s velocity when extending “work graph” objects and features (commenting, favoriting, sharing, etc.). Today, teams often find themselves building similar features on multiple objects (or occasionally, vice-versa), but aren’t reaping the rewards of prior work. Instead, we’d like teams to be able to build new features once and extend them cheaply, with minimal work to support any custom behavior based on the object in question.
That sounds like the type of project I would have loved as an engineer. What’s the catch?
Understanding this problem requires some context on Asana’s technical history. When Asana was founded, JavaScript was immature, lacking support for OOP, Node 1.0, typing, etc. As a result, we built our own type system and filled in gaps in the language as part of our isomorphic, reactive JS framework called “Luna”. Over time we encountered velocity and performance issues, motivating evolution of the framework and ultimately a large re-write in React and TypeScript, while still keeping our custom data-loading and reactivity system.
Throughout this decade+ framework journey, we continued to iterate and build new work graph objects (Portfolios, Goals, Dashboards, etc.) and features on those objects. However, we didn’t rigorously define guidance for sharing code between them, and we inadvertently coupled various layers of our web-stack to our persistence schema. Today, we’re revisiting this coupling and working to disentangle our layers to let details between server and client layers change independently. As a result, we’ll be better able to write and share code against interfaces rather than concrete, persisted types – all while continuing to improve the product and interoperate with our other systems like our mobile clients, Elasticsearch, and our API.
It’s been a fun way to learn and collaborate with folks in different parts of the organization, and I’ve taken personal satisfaction from the feeling that though many people at different levels of our org and stack have a window on this problem (and are excited to see it solved), no one yet has the whole picture. I’m looking forward to making it clear so we can improve it!
Caleb Wang, ATL for the Pay Area
What do your days look like at Asana?
My top priority is ensuring that our systems architecture will be able to support the needs of the business on a multi-year time scale. Depending on the exact time, this could mean talking to stakeholders to understand their goals and related customer pains, synthesizing that information with my understanding of our engineering systems, or trying to socialize a technical strategy and express it on roadmaps.
There isn’t enough strategy work to take up all my time, so most of my time is spent helping projects in my area or adjacent to my area be successful. This could mean anything from jamming on solutions to address a customer need, or pairing with an engineer or tech lead on whatever they’re working on. I also lead a few meetings with engineering leaders from different teams in the area.
I do get to spend some time in code, but I’m usually either reading or reviewing code to make sure I keep in touch with how our systems actually work, or prototyping an idea that will never ship (at least in the form that I create).
Tell us about an interesting project you worked on in this role.
I’ve spent a pretty significant amount of time in this role working on a project (or series of projects, depending on how you look at it) to overhaul our billing and licensing architecture. Before I started in this role, Asana had made minimal changes in this area for nearly a decade, which meant that our conceptual model was pretty outdated, and was unable to support our ambitions for pricing and packaging going forward.
As part of this work, I dug into customer pains and spoke with our business teams to understand how our billing model should evolve, partnered with various PMs and engineers across the area to create a technical vision, and advocated for the work to be staffed with our leadership team. So far, we’ve shipped an update to our billing infrastructure to support additional product lines and add-ons, and recent customer feedback has made us even more confident in the vision.
Dominik Gruber, ATL for the Mobile Area
What do your days look like at Asana?
I appreciate and enjoy that I have a lot of autonomy in choosing the projects that I work on, and I make that decision based on the current and anticipated needs of the area. These projects can be very different, they range all the way from setting the technical direction for Asana’s mobile apps, over area engineering operational concerns, to growing our engineers and best practices. Executing on these projects requires collaboration with stakeholders inside and outside of the area, so I spend a good amount of my time communicating with them synchronously and asynchronously.
There is also a lot of reactive work to coordinate between and unblock teams and projects in addition to design doc and code reviews.
Even though it’s usually not the immediately most leveraged way to make an impact in my role, I also try to write some code regularly for important but non-urgent changes to stay connected to the codebases and development experience. This ultimately enables me to execute better on the main projects.
Tell us about an interesting project you worked on in this role.
Recently I drove the creation of an architectural strategy for what the mobile development experience should look like in two years. Our main goal was to drastically improve the speed and quality at which mobile product engineers can ship mobile features. I started this by surveying all engineers that have contributed mobile code in the past few quarters about the problems they encountered. The resulting ranked list was a major input alongside other technical, organizational, and product developments across the company. I worked with a group of engineers to identify six focus areas. For each one we created a vision, and a high level plan for how to get there. We are executing on multiple of these areas at the moment, and I am very excited by the progress we have made so far.
Another, very different project was driving the operational engineering changes for the reorganization of the Mobile Area. Until a year ago, the area consisted of three platform teams (Android, iOS, Mobile Backend), and we changed the structure to four functional teams where each team has a mix of mobile platform experts. To enable this change, we needed to carefully (re)design operational processes to work across teams. For example, we wanted to maintain a community and discussion forum for the experts of the three platforms which led to the creation of mobile platform guilds. Another example is that we designed a new process for how to track and triage bugs which included setting shared SLAs to maintain the quality and stability of our mobile apps.
Josh Smith, ATL for the Land Area
What do your days look like at Asana?
My day-to-day is extremely varied as I split my time between supporting technical decision making in the area and focusing on initiatives that I am leading personally. A big perk of supporting other engineers on their decisions is that I get to quickly jump into a lot of interesting technical discussions. Over the past couple days I:
- Put together a proposal for what url format we could use to unify the urls we currently have for projects without creating any security vulnerabilities. This was part of a larger project I have been working on with a number of product folks to create an updated vision for how sharing should work across Asana.
- Provided feedback on an internal blog post by the tech lead of the Intra Company Growth team that explained how we could improve code sharing between Read Only Links and the version of these links that we show to logged-in users.
- Met with an engineer on the Big Org Adoption team to brainstorm ways to use Elasticsearch to find projects that are relevant to new users, and then attended a follow up meeting with data engineering on how we can set this up to work with a machine learning model in the future.
Tell us about an interesting project you worked on in this role!
Towards the end of last year, I worked on a project to create a new team in the Land Area called “Working Relationships”. A PM in the area had already put together a product case for doing a large amount of work related to fostering peer-to-peer and manager-to-report relationships in Asana, but it was unclear what team this work would live on. I created a proposal to form a new team to own this work. I worked with the product managers of related teams to figure out how to frame this new team’s mission so that it would be able to work towards its mission autonomously. I also worked with the engineering managers of related teams to figure out what areas of the product this new team should own. I compared this proposal against a number of other options and then presented it to pillar leadership to get approval to create the new team and additional headcount to support it.
This was a really exciting and interesting experience for me. Before becoming Area Tech Lead, I sometimes felt like the roadmap for the team I was leading overlapped with related teams frequently and we ended up trading responsibilities between the teams a few times. As an area tech lead, I enjoy having the opportunity to try to craft these team boundaries intentionally, and hope that by creating the right boundaries I can help each team operate more autonomously and move faster.