This guide is designed to help the marketing team plan, manage, and execute cross-functional projects at Sourcegraph. This guide is focused on the fundamentals and is not exhaustive as every project is unique. Please contribute to it by adding best practices and resources.
Follow these three steps to set your project up for success from the very beginning!
| Activity | Why this matters |
| Step 1: Assign roles and responsibilities | Every project should have a single DRI (directly responsible individual) or driver. The DRI is not responsible for executing everything themselves, but they are responsible for making sure the project is executed. This person is likely setting the strategy for the project.
Be clear about all other roles and responsibilities upfront - and document this in a project brief. Knowing who the contributors are will help with accountability. Knowing who the approvers are will make it easier to finalize decisions and push the project forward. Knowing who needs to be informed/consulted will ensure the project team is working cross-functionally throughout the process. |
| Step 2: Scope the project and create a brief (template) | Align the project team around the roles, strategy, audience, goals, deliverables, and milestones. This will help ensure alignment early in the process. Keep this brief updated as the plan and strategy evolve. |
| Step 3: Kick the project off and begin planning | This is when the team will iron out the specifics of the project and commit to key deliverables and timelines. |
Best practices for execution: Sourcegraph’s async and remote culture makes organization and communication even more important. Make it easy for anyone at the company to learn about the project, understand the status, review the plans, or even drill into in-flight work.
- Stay organized
- Keep projects moving forward
- Think about dependencies
- Communicate frequently
- Be clear about roles and responsibilities
- Avoid making decisions by consensus
Before the project kicks off, be explicit about roles and responsibilities. Once roles and responsibilities have been identified, be sure to document everything in the project brief.
| Role | Overview | Details |
| DRI/Driver | The DRI (directly responsible individual) is not responsible for executing everything themselves, but they are responsible for making sure the project is executed. |
|
| Approver(s) | Responsible for approving major decisions and strategy. | |
| Contributors | Contributors are the people responsible for planning and executing the work. Contributors will also be the DRI or driver for aspects of the overall project. For example, a contributor from the content team may be the DRI or driver for coming up with the content strategy for a given program.
In addition to contributors on the marketing team, think about other teams that will play a role and be sure to include them early. |
|
| Consulted | To make sure our work is connected to what other teams are doing, identify consultants outside of marketing that can help. |
|
| Informed | Think about how the project will impact or benefit other teams - and make sure they are informed. |
|
Once the DRI/driver has been identified, they should create a project brief to help align the project team around the roles, strategy, audience, goals, deliverables, and milestones.
Here is a standard brief template you can use.
In addition to the project brief, there are additional/specialized briefs used for certain projects:
The purpose of the kickoff is to ensure everyone who is working on the project understands the strategy, goals, roles and responsibilities, milestones, etc. This can happen via a meeting or async by sharing the project brief.
During the planning process, the team should check in with key stakeholders, brainstorm ideas, discuss strategy, etc. You’ll likely come up with more ideas than you’re able to execute against, so it’s important to be really clear about what each contributor/team is actually taking on. That’s where the project plan comes in.
During the planning process, the DRI and the contributors should also work to create a cohesive project plan in Asana. The project plan should include the following for all committed deliverables:
- Roles and responsibilities
- Timeline
- Dependencies
Sourcegraph’s async and remote culture makes organization even more important. Make it easy for anyone at the company to learn about the project, understand the status, review the plans, or even drill into in-flight work. The best way to do this is to minimize sprawl.
- Create a “homepage” for the project. This can be a doc, an Asana board, or even a deck. Keep the homepage up-to-date and link to relevant content from it.
- Create a shared project folder in Google Drive - and make sure anything related to the project (meeting notes, project plans, content, etc.) is stored there. Helpful sub-folders include:
- Planning
- Messaging
- Execution
- Create a single Slack channel for the entire project - avoid having sub-channels.
- Track key deliverables and timelines in Asana. Feel free to track more granular tasks if helpful.
- If you’re having synchronous meetings, create a single doc for notetaking and record every meeting.
- Make everything easy to find - cross-link wherever you can! The Asana board, homepage, Slack channel, and meeting notes should all link to each other.
The DRI/Driver is responsible for keeping the project moving forward. Here are a few tips:
- Have a weekly standup - this can be done async on Slack or live during a meeting. The DRI should lead the standup and check in on the progress of key activities. This will also give the team a chance to surface blockers or ask questions.
- If you’re doing a Slack standup, tag people and ask specific questions (example)
- Proactively flag blockers and risks - check in with everyone to understand if there are any blockers, anticipate potential blockers, and continuously work to unblock the team.
- Help connect the dots - as the DRI, you’ll have the best understanding of everything that’s going on across the team. Share that knowledge with the rest of the team (example).
As soon as you start planning, think through every dependency and loop in the necessary stakeholders from the very beginning. Here are a few questions to ask yourself:
- Who else will need to contribute to what you’re working on? If you’re building a new landing page, you’ll need support from design, engineering, content, analytics, and more.
- Who needs to know about what you’re working on? How will this impact them?
- Who needs to approve what you’re working on?
- Overshare! Share updates in the project slack channel, and then re-share in relevant channels along the way (#marketing, #sales, #product, etc.).
- Work with Amie and the Comms team to find opportunities for internal comms (posting in #general, speaking at a company meeting, etc.).
- Post in #progress when your project goes live.
- Report back on results after the project ships.
Going back to Step 1 (assigning roles and responsibilities), it’s important to continuously check back on roles and responsibilities. Here are a few times where this really helps:
- When decision making slows down or stalls: this often happens when there isn’t clarity on who the approver is.
- When teammates/the company aren’t sure what’s going on: Are all the people that should be informed informed?
While it’s important to get feedback from key stakeholders, it’s equally important to have the right person make a given decision. This handbook page is a great resource for making decisions at Sourcegraph.
Here are tips for collecting feedback without making decisions by consensus:
- Be clear about who you need feedback from.
- Be clear about what type of feedback you’re looking for:
- 20% feedback: Feedback on the strategy, approach, and overall direction.
- 80% feedback: Feedback on the specific content (words, design, etc.).
- Be clear about the role of feedback: while feedback is an important input, you do not need to act on every piece of feedback you receive. In many cases, this will be impossible because you’ll receive conflicting feedback from different stakeholders.
- Set and communicate a timeline for when you want to receive feedback. This will make it easier to review and incorporate all feedback at once and then move forward. It may make sense to have two rounds of feedback at times.