At Dyspatch, we use Asana to track all tasks and projects within the company, from Sales to Marketing to Operations, including Product Development (but that’s a separate blog post). Asana allows us to funnel tasks to the right people, making sure no task is ever lost while ensuring cross-team collaboration and approval.

General Company Structure

At the time of this writing, I’ve been with the company for just a month, but the stark departure from management systems I’ve experienced in the past has been a refreshing revelation.

Dyspatch has a fairly typical structure for a startup: Marketing, Engineering, Sales, etc. The company employs roughly thirty people, with offices in Victoria, BC, and San Francisco, CA.

Because of this geographical split, we have rallied around Slack for chat, Zoom for conferencing, and, the subject of this post, Asana for project management and task tracking.  

There are a couple of unique things worth noting about Dyspatch that allow us to make the most of Asana:

1. Every workday, Dyspatch has an all-hands meeting we call Stand-Up. Let me say that again: The entire company. Every. Single. Day. This may sound excessive, and past experience has shown me that getting executives to agree to a monthly company meeting can be difficult. But the meetings here are nearly always under ten minutes and they always start on time.  
2. Everyone uses Asana, in every department, at every level, for everything we need to track. This allows us to work a bit of magic.

Dyspatch Hierarchical Stand-Up

In addition to the Company Stand-Up board in Asana (see Fig. 1, below), each department also has an individual Stand-Up. Items actionable by a specific department are discussed at the company level, then moved into the Stand-Up project for that department. If two departments need to take action on an item, it’s put into both Stand-Ups.  (“A task in two projects without cloning? Witchcraft!” – a Jira user with Stockholm syndrome.)

Each of the Stand-Up boards mirrors the Company Board, which includes the following subsections:

• Done – Task complete.
• Testing / Review – A task that remains visible to the entire company, is mostly complete, but needs some kind of sign-off before being marked as ‘Done’.
• Doing – A task that’s in-progress and that needs to remain visible.
• On Hold – Something we want to postpone but that’s still critical enough to be seen every day.
• Needs Discussion – This section is for new items that need to be presented to the entire company.  

Adding something to the Needs Discussion subsection guarantees it will be brought to the attention of the entire company and addressed the next business day. The person who submits the item is asked to talk about it during Stand-Up. It’s then assigned to a department, if necessary, and either kept at the company level for tracking or not.

The Engineering Stand-Up board (Fig. 2, below), is almost identical to the Company Stand-Up board, but with an additional section called ‘Tech Talk’, a place for recent learnings – cool stuff that the rest of the team would benefit from. Things that are brought up in the Company Stand-Up that the Engineering team is responsible for will move into the Engineering ‘Needs Discussion’ section and be processed in a similar way.

Hierarchical Stand-Up Example

Here’s a great example of the power of this process (see Fig. 3, below):

1. Sales received an outraged email from a customer stating that we were sending spam emails to their contact list. After confirming the spam didn’t come from us, our Sales team needed help diagnosing the problem.  
2. Sales took the issue to their manager, who did some research on SPF and DKIM. The manager was unable to definitively identify the problem so they did the Dyspatch thing and…
3. Put an item in the ‘Needs Discussion’ subsection for Stand-Up the following day.
4. At the next Stand-Up, the item was briefly explained and the Engineering team agreed to take ownership of the issue, which was then moved to the Engineering board.
5. In the Engineering Stand-Up, we created a team to investigate.  
6. The next day, day 3 of the issue, the team decided that the solution was to update our SPF records to have stricter spoofing requirements. At the same time, however, we determined that this solution could potentially impact all systems that legitimately send emails as both Dyspatch and Sendwithus, i.e. Salesforce, Pardot, Google Drive etc.
7. Again, we added an item to ‘Needs Discussion’ for the next Company Stand-Up, to discuss the risks associated with the proposed solution and decide, as a company, how to proceed.
8. The item was addressed at the next Stand-Up and as a company, we decided to implement the solution and check all systems over the weekend, to minimize the impact if something went wrong.  
9. Over the weekend, a multi-department task force checked all potentially-affected systems and, after everything was deemed okay, another item was placed into the Company Stand-Up to let everyone know all was well but the situation should be monitored.
10. In the end, this complex, cross-departmental, high-blast-radius change was handled within standard operating procedures, with minimal impact to company velocity, and all within five business days.

Consider how a more traditional company might have handled the issue. Same complaint from the customer and same escalation to the manager. The manager still decides they need Engineering’s help but with no defined process to ask for that help, they go directly to the VP of Engineering. The VP Eng might say something like, “I’d love to help you out but your priority is not my priority. I don’t have resources right now.” So the Sales manager escalates the issue, continuing up the ladder until they reach someone with with both the will and the authority to tell the VP Eng that they must deal with the issue. This takes time, and erodes relationships.  

Ultimately, the solution would likely be the same but it would have taken much longer and resulted in weakened relationships between departments.

Our Stand-Up process provides a direct channel to engage the broadest audience and have actionable tasks decided upon and delegated within ten minutes, every day. This specific example involved four departments and required engaging the entire company three times. Anything less, on either axis, could have been disastrous.

My point is that this entire workflow is accomplished with vanilla, out-of-the box Asana. This hierarchical, iterative, cross-departmental ownership system is *easy* in Asana but in other tools, as experience has taught me, can be a nightmare.