Managing cross-functional projects

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.

TL;DR

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

Set your project up for success

Step 1: Assign roles and responsibilities

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.
  • Setting the strategy for the project
  • Setting goals for the project
  • Leading planning for the project
  • Ensuring there is a DRI for all of the different workstreams
  • Making sure the project is executed on time
  • Communicating updates to internal stakeholders
  • Connecting the dots across all of the various workstreams
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.

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.
  • Provide feedback on the overall approach
  • Review content/messaging
  • Share ideas to make the project more impactful
Informed Think about how the project will impact or benefit other teams - and make sure they are informed.
  • Sales
  • Product
  • Engineering
  • Design
  • Content platform team
  • Exec

Step 2: Scope the project and create a brief

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:

Step 3: Kick the project off and begin planning

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

Best practices for execution

Stay organized

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.

Keep projects moving forward

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).

Think about dependencies

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?

Communicate frequently

  • Overshare! Share updates in the project slack channel, and then re-share in relevant channels along the way (#marketing, #sales, #product, etc.).
  • Work with 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.

Be clear about roles and responsibilities

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?

Close the thread

As a project moves into execution and review, expect conversations and sub-deliverables to come up along the way that may create new roles and responsibilities. “Closing the thread” means not leaving these conversations without a clear resolution, action items if they exist, and who’s responsible.

  • If you’re closing the thread and taking an action item, this could look like: “Confirming that I will be reviewing the proposed copy changes and will follow up with feedback in this channel tomorrow by 3p UTC.”
  • If you’re closing the thread and an action it is not being taking, this might look like: ""Based on this thread and our conversation today (link to notes here), I’m confirming that there are no further actions to be taken. This project has been moved to the backlog here (Asana link).
  • It’s also entirely appropriate to confirm if someone else should be taking an action item from the conversation. This could sound like, “To confirm, Sam is on point for moving this forward and will be delivering a draft of the brief by EOW. Is that right?”

Avoid making decisions by consensus

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.