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.
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.
To keep all work-to-be-done, plus all information and resources required to get it done (often linking to other tools)
Communicating quickly and staying in community with each other
Storing and organizing information and resources we intend to keep for a long time (company-related or project-related)
Email. Creating longer documents and creating documents on which we need to collaborate intensively. Spreadsheets. File storage.
Keeping track of time spent, invoicing
Keeping all of our credentials and secrets organized, safe, and easy to access for the right people
Completing design work. Serves as the repository for all Cantilever design
Holding all Cantilever code and managing the development workflow
Planning the studio project/staff schedule
Texting & Phone
Urgent Communication (<24 hours response time needed)
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
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.