We use a wide range of software to complete our work. We have a core suite of tools that we use on almost every project, plus individual platforms that we integrate for specific reasons, and client platforms where we interact with specific clients.

Resources

Computer Provisioning

Production Tool Philosophy

We do our best to remain flexible about allowing new platforms to be a part of our workflow when helpful, while retaining a muscle memory for our core tools and how we use them to get things done. We don’t want to force every need to fit the same tools, but we also don’t want to be so scattered that we can’t operate smoothly.

So our approach is to be have a toolkit that is both wide and deep – we want to have expert knowledge in our main tools, like Asana/Slack/Notion, while retaining the flexibility to add something we rarely use, like Framer or Storybook, when a project calls for them.

Our Tools (Open for more info on each)

Integrating More Tools

From time to time our normal software won’t meet a particular project need. For example, we may need to use Premiere Pro to handle some video editing, or Storybook to showcase React components. When we integrate a different tool into a project, it should be connected to our core toolkit by linking. For example, if we create a Storybook link for a specific project, we should describe that and link to it from the Notion ‣ record for that project. In any other tools, we should use the shared Project & Client Codes to ensure that the data in those tools is trackable back to a project in our main toolkit.

Using Client Tools

Often clients will ask that we work within their existing tools for communication or getting work done. For example, clients may prefer for their documentation to be written in Coda rather than in Notion. We have a few rules about this:

• By default, only the client’s PM and Strategist should have access to these tools. Adding individual team members is dangerous because their workflow then becomes fragmented.
• By default, we only do this for clients who have an associated strategy retainer with us. Being willing to work within their tools is a part of what they pay for when they have a strategy retainer.

When we opt to use a client tool, we should try to stay within their existing workflow while mapping information back to our core tools, and observing the general workflow for integrating secondary tools. For example, a project manager may maintain a Jira ticket within the client’s Jira board, but keep their own task in Asana for the same work, and assign it to the right staffer there. For certain clients this becomes onerous to manage, and we’d rather just work within their tools to begin with.

Using Vendor Tools

Sometimes a vendor or partner will want to communicate differently with us than our normal methods. For example, a social media company might want to use Discord to chat with their internal contact rather than Slack. This is fair, if it’s their domain. The relevant DRI should assess the need and determine whether it is feasible for us to work in their tools, or better to push back and accept the consequences.