As an engineering manager, I need to keep track of so many things. I have my own personal to-dos that I need to prioritize, making time for focused work while also handling incoming requests and other messages. I need to manage projects, which involves keeping track of work on my team and giving support or direction. I also need to make sure my team is tracking toward high level business goals. I’m constantly collaborating, both within my team and cross-functionally.
In my experience, self-management is a big factor in how impactful I can be. With only eight hours in a workday, I can’t sustainably increase my effectiveness by working more. Rather, my impact increases when I manage my time and my focus better. I do this by relying on tools that help me take a systematic approach.
Since joining Asana (the company), I’ve upped my self-management game; Asana (the product) has been a big part of that improvement. Let’s look at how I use Asana to track and prioritize my work, collaborate with colleagues, and create clarity for myself and my team.
One of the key ideas in task management is capture: when you think of a to-do, put it in your system. By not relying on memory, you reduce stress, free up brainspace for other things, and forget fewer things. When I started consistently capturing tasks, fewer of my to-dos (and ideas!) got lost—and more of them got acted on. Capture makes me more reliable. Any good task management tool will help with capture, and Asana is no exception: just hit Tab-Q and type in your task title.
Capture has a dark side, though. I’m sure I’m not the only one who’s felt the pain: the task list grows faster than you can work through it; stress goes up with the accumulation of undone items; important to-dos get lost in the mess. The fact is that we can’t do everything—our lives are too complex.
To get a grip on the sheer number of tasks, I use two key features of Asana: due dates and My tasks. My tasks is an area of Asana that shows every task currently assigned to me, regardless of what other projects it might be part of. I can organize my tasks into sections, apply custom fields (labels), see what projects tasks belong to, and even apply automations to them. And of course, I can add due dates to tasks and sort them by due date.
Here are my principles for task management using My tasks and due dates:
Use “due date” as a “do date.” In other words, when I plan to actually do the task. If a task has a hard deadline, I capture that elsewhere in the task, like in a custom field or in the task description.
Everything has a due date. The only exceptions are “tasks” that don’t actually need to get done, e.g. tasks I’m using for reference. If it’s a task I need to do, it has a due date.
Keep My tasks sorted by due date. This way, I can easily see what the “top” items on my to-do list are at any given time. Essentially, My tasks functions as a priority queue for my work. I also have a custom automation that pulls tasks due today into a special “TODAY” section. This helps me focus on the things I’m supposed to do today.
No overdue tasks. If a task is past its due date, I change it to a realistic due date. This prevents me from getting lost in a sea of overdue work.
Big tasks go on the calendar. If a task will take more than 15 minutes, I put it on my calendar. Otherwise, I may never carve out enough time to do it.
Groom My tasks at the start of the week. Your mileage may vary, but I can never make myself do an end-of-week review. Instead, the first thing on my calendar on Monday is to plan my week, which includes making sure all of the above assertions are true in My tasks. I use this time to think about my priorities for the week and make sure they’re reflected in my week’s tasks. If I have too much to do, I delegate, drop, or defer tasks to subsequent weeks.
The benefits that I’ve seen from using this system include:
I start every day with a list of my priorities.
Dates on past-due items turn red, which incentivizes me to reflect and reprioritize, making it easier to keep my priorities straight.
I know tasks aren’t going to get lost, because they’ll eventually come up in my queue for me to do.
Similarly, I don't have to worry about cruft accumulating—I have a natural reminder to drop (or defer or delegate) a task if it’s not worth doing when it rises to the top of the queue.
I don't have to be absolutely correct. If I plan too much work for this Wednesday, and don't get to all of it, I can revise the due dates on the remaining tasks.
Effectively, the priority queue encourages continuous review.
For this system to really work, I need all my work to be in my system. But a lot of my work involves others, so task management at the individual level isn’t fully adequate. In the past, I've used software that focused on my individual tasks; as a result, my work became fragmented between tools, and my system was less effective. By addressing two other key needs of my role—collaboration and alignment—Asana allows me to take a more comprehensive approach, making my self-management more effective.
Work doesn’t happen in a vacuum; this is especially true for engineering managers. While Asana lets me have private tasks as to-dos for myself, most of my work requires collaboration with others. This is where Asana shines—it’s a work management platform, not just a task manager or to-do list. Asana facilitates collaboration at a task level, project level, and beyond.
Every task in Asana has an associated comment thread. This means that if I have a status update on a task I own or need to discuss the scope or requirements for a task with stakeholders, I can do that on the task itself, which has all the relevant context. Or if I have a question about a task that one of my team members owns, I can ask the question on the Asana task. Compared to having these conversations in Slack or email, it’s a vast improvement in organization and findability. Having the conversation embedded in the task reduces the time readers need to spend to understand the discussion.
Tasks can also have any number of followers, which by default include the task creator, the assignee, and anyone @-mentioned in the task’s description or comment thread. (I can also add other followers to the task.) Followers get updates if the task is modified in certain ways, like if it’s completed, the due date has changed, or if someone leaves a new comment. This allows me to stay abreast of updates on tasks I care about and loop others into conversations as needed.
Asana also aids in collaboration at the level of a project. Projects in Asana are collections of tasks, with a variety of possible views. Some examples of projects I use regularly:
A backlog and sprint planning project, which contains a section with a groomed list of tasks representing upcoming work for the team and a section for the upcoming sprint that we pull tasks into during our team’s sprint planning meeting.
An Asana project for each actual project my team is working on, which contains all the implementation tasks and other relevant tasks for that project. We can use due dates and the timeline feature to put together a timeline view of the whole project.
1:1 projects. For each of my team members (and my manager and peers I meet with regularly), we have a project that is private to me and that individual. It’s where we can add agenda items in advance of the meeting and use the comment thread to take notes on those items when we discuss them live or asynchronously.
Other initiatives. If I’m driving a cross-functional initiative or some other piece of work that isn’t one of my team’s projects, I’ll keep an Asana project with the list of tasks that I or others need to do for that initiative.
Given all these different types of projects, my favorite Asana feature is multihoming. This means that one task can be added to multiple projects. My task to optimize the FooBar widget can be in my backlog project—and in the project representing the overall “Foo retrofit” initiative that this task is a part of. Same task, same comment thread, different projects for different contexts and purposes. This saves an incredible amount of duplication of information and effort. And in cases where multihoming isn’t appropriate, I can easily create a follow-up task that links to the original task. For example, if I want to follow up privately with someone, I might add a follow-up task to our 1:1 agenda project.
Like tasks, projects can have followers, so I can easily provide project-level status updates to interested stakeholders. Asana also allows me (or my stakeholders) to group related projects into a portfolio and get a bird’s-eye view of the progress of all of them.
We’ve talked about tasks, projects, and portfolios, all of which help create clarity about what needs to get done and how. But as a manager, I also need to communicate the “why” of our work. Why is what we’re doing important? How does it relate to our business goals?
To make this alignment explicit, I use the Asana Goals feature. Every quarter I can define our team’s key results as Asana Goals, and I can link these goals up to parent goals, which usually represent the goals of the organizational unit in which our team sits. Those parent goals, in turn, can be linked up to goals representing company objectives.
I can also link my team’s goals to the projects representing the work that needs to be done to achieve those goals. And if I define certain tasks in those projects as milestones, then the goals system can automatically calculate progress toward the goal based on the percentage of milestones that are complete.
All this is made possible by Asana's Work Graph® data model that allows companies to connect the goals at the top of an organization, all the way down to cross-functional projects and supporting tasks. It’s the best system I’ve seen for capturing the relationship between the how, the what, and the why of work in a single platform.
At Asana (the company), we use Asana (the product) as much as we can. We use it for all the purposes I’ve mentioned above, and more.
When I joined Asana, I had been using a different task management software for managing my individual to-dos. Understanding the ubiquity of Asana at Asana, I made the decision to convert over to Asana for all of my task management—and I’m glad I did.
Because of Asana’s comprehensive approach to work management, being “all in” means I get the maximum benefit of multihoming and the Work Graph. As an engineering manager, I’m constantly involved in individual task management, project management, collaboration both within the team and with cross-functional stakeholders, and laddering project progress up to high-level goals. Asana ties all these concerns together into a cohesive whole, making it that much easier to stay organized and create clarity for myself and my colleagues.
Special thanks to Jeremy Rosenbaum for helping me refine my own workflow; and Nathan Lawrence, Aaron Gurin, Steve Landey, Jake Cerf, Sarah Baron, and Ross Viator for their feedback on this post.