Working and Communicating With Other Teams at A8C

Best Practices

Below are some best practices for facilitating effective collaboration with product and service teams outside of the division but still within Automattic (A8C¹):

Scoping

• Internal projects should avoid using a project brief unless there is a compelling reason to. For more information, see the Project Briefs page.
• Although a project brief is not needed, there should be a conversation among all key stakeholders at the start of the project to establish scope and timeline expectations to ensure everyone is on the same page. The result of this conversation should be clearly documented in a P2 comment.
• If the project is going to be a fast-moving project or especially complex project, it may be beneficial to have a pair designer, and/or to ensure that the designer assigned doesn’t have any other concurrent projects. If that’s a possibility, that should be discussed with the design team up front as a part of the scoping, timeline, and availability discussion.

DRIs²

• Designate a DRI from the product or service team we’re looking to engage with (ping your lead if you’re having trouble identifying who this should be). Avoid cross-posting to teams unless it’s just for FYI and aim to at-mention an individual if help should be expedited.
• Consider posting a RACI³ to ensure folks are all aligned on the ways they’re involved in the project (there’s a great example on the project thread for: ███████████████, or for a variation that is based on project phase/action item: ███████████████).
  • DRIs on the Special Projects Team will push to be clear about who is doing what and when items are due.
  • In particular, it should be clear who is making any last minute copy changes: the Special Projects Team TAM, the product/service team DRI, or the developer.
• Unless stated otherwise, members of the Special Projects Team will be responsible for account management/partner comms (if the project involves a client/partner) and/or project management. Partner comms should come from one source, ███████████████, and avoid multiple cc’s (everyone can work in the shared inbox as needed).

Information & Sources of Truth

• Sync huddles: “This is happening now”
  • For fast-moving projects, it can be helpful to have short weekly calls. This can happen for the whole project on short, fast-turnaround projects, or just during key times, like the weeks leading up to launch.
• Slack: “This is what’s needed”
  • Create a public, single-use Slack channel for folks to coordinate quickly and in real-time. This can be archived later but is effective for making it easy for each party to see who is doing what. The Slack channel should be public. Include team leads and other stakeholders in the channel.
  • The Slack channel is typically the best place for small updates and requests, and QA conversations.
• P2: “This is what happened” (and long-form discussions)
  • Define a canonical P2 and include it in the Slack channel description and at the top of the project P2. Since the project is cross-team/cross-division, multiple P2s may be in use but the canonical P2 is where the group can expect the latest SITREP⁴ to be posted.
  • P2 is where final decisions should be documented.
  • In some cases, async, long-form discussion can be better suited to P2 versus Slack.
• Linear: “Bird’s eye view”
  • This is where project status and project management updates live.
  • This is the ultimate source of truth for project milestones and deadlines.
• Especially near the end, it’s important to have an authoritative document or single point of contact for final changes, whether that’s a Google sheet, Google doc, or some other medium.

Updates & Collaboration

• If teams are working on an urgent request or incident, employ our incident response process (███████████████) and make sure DRI hand-offs are clear.
• If our contractor developers will be working alongside internal developers, ensure that:
  • Our expectations for code quality standards are made clear to contractors up-front (the Special Projects Engineering Team can help).
  • Encourage the internal developers on the project to provide helpful, actionable real-time feedback to our contractors in GitHub as the project progresses.
• Ensure that the design council is informed and looped in on the project in the design phase.
• Other teams often are unsure of what our process looks like; it can be helpful to have a conversation up front about the level of visibility into our process the other team would like to have. Some are comfortable with simply answering questions when their input is needed, while others want to be able to actively follow along with our work.
• Perform an After-Action-Review (AAR) or retrospective with the teams collaborated with once the project is complete (or if friction develops). An example of an AAR can be found in our team’s P2: ███████████████. Action any learnings that would improve working together.
• On the off-chance an A8c-owned or internal site is launched on Pressable or WordPress.com, the site should be added to the list of most valuable sites that require pull requests to be manually reviewed. Please ping in P2: ███████████████ to have the action added to the repo.

---

Proposed Workflow for Internal Projects

The Special Projects Team is taking on more internal projects, which follow a slightly different process to external projects. As such, here’s a proposed workflow for internal projects. Internal project lifecycles may differ to that of an external partner. 

Feel free to share this page with the internal team you’re working with. 

Communication & Project Setup 

All internal projects will go through the steps in our team’s new project checklist. For a checklist on setting up the wordpress.com site, see ███████████████.

Slack / P2 / Linear

If a Special Projects Team Slack channel for collaborating with the team/division doesn’t already exists, please create a single-use Slack channel for the project. Slack is great for quick, real-time communication, such as planning meetings, follow-ups, or small clarifying questions. Keep any major decisions and comments in the project P2. Avoid DMs in Slack, as it limits our ability to fully support the project.

Avoid communicating via email with other a12s⁵, instead tag the necessary internal stakeholders in our project P2 and continue to communicate via P2/Slack until the project launches. This still gives the full team visibility of the project.

It can be beneficial to add a weekly SITREP⁶ to the project P2 to keep all stakeholders up to date on the status of the project. 

Where possible, try to use the same Linear project across divisions. If that’s not possible, they can be linked by added one project as a dependency to another.

RACI (Responsible, Accountable, Consulted, Informed)

Start putting together a RACI table so it’s clear who is doing what, and that every stakeholder is kept informed. The RACI table should be reviewed continuously to ensure the stakeholders’ accuracy.

Communication Style, Tone, and Philosophy

We always aim for high-quality interactions with site owners, so communication should be collaborative, empowering, clear, concise, and follow our team’s communication guidelines.

Special Considerations for Internal Projects 

Internal projects follow the same process as external projects. You can read through that process in our Project Life Cycle Handbook Page. Except as explained below.

Design

During the design stage, we’ll need to ensure the design council is informed of our work. They should also be given an opportunity to provide feedback on the design. The feedback should be both asked for and received by the designer.

WPCOM Hosting – Learnings

When hosting sites on WordPress.com, we generally use plans that enable the Hosting Features, which allows our contractor developers to commit code to the site (███████████████). However, for A8C-internal sites, we host the site on the WordPress.com platform with no plugins enabled. (███████████████). Please see what considerations go into determining hosting for internal A8c sites on our hosting handbook page (███████████████).

When we’re developing for a non-plugins enabled site, there are some extra steps in the project life cycle. ███████████████.

On the off-chance an A8c-owned or internal site is launched on Pressable or WordPress.com, the site should be added to the list of most valuable sites that require pull requests to be manually reviewed. Please ping in P2: ███████████████ to have the action added to the repo.

1. Migration to a Non-Plugin Enabled Site

Our contract developers will build out the theme on a site we create for them during development that has hosting features enabled, just like any external project. Once it has been QA’d and development is “finished”, we’ll need to migrate it to a non-plugin enabled site.

This step needs to be completed by our internal developers, who have commit access to the WPCOM repo. You can put in a dev request as normal, and they will triage the issue. 

Once started, the migration takes around a week or two. Some projects require some additional effort to move the code the WPCOM repo, so account for that in your timeline planning.

The initial site used for development (the site with hosting features enabled) should not be used for testing once the theme code has been migrated to the WPCOM repo. This should be communicated with the internal teams to avoid any confusion. 

Exceptions: Sometimes an internal developer may work on an internal site instead of a contractor. If multiple internal teams are working on the site while we build it, we should migrate everything to date to the WPCOM repo, and retire the site and repo used for initial development. Work should then commence exclusively on the WPCOM repo with the non-plugin enabled site being the source of truth.

It would be beneficial to add to the RACI table who’ll be doing what and when. E.g. note which contractors will work on the site during the initial build on the development site, and then when the theme is migrated to the WPCOM repo, update the chart to reflect the internal devs and additional teams.

Choosing a WordPress.com Plan for Non-Plugin Enabled Sites

Often, non-plugin enabled sites will utilize a Personal plan. However, at times (such as when we need to utilize the Custom HTML block), it is necessary to use the WordPress.com Business plan, combined with the ███████████████ sticker so it is blocked from being converted to a plugin-enabled site. If you are unsure of how to add that sticker, an internal developer can assist.

If it a WordPress.com Business plan is used, it is important that any Jetpack subscriptions be removed from the site if present, as they will conflict with the Jetpack connection that is included as part of the Business plan. ███████████████

2. QA – Round 2

Once the theme has been migrated to the WPCOM repo, there is another round of QA required. The site should be checked against the site used for development to confirm the design and functionality match. This can be performed by our QA engineers, and any adjustments that need to be done can be assigned to the internal developer.

Once the above two steps have been completed, we can move to partner User Acceptance Testing ahead of launch. 

Launch

When you’re ready for launch, here are some general guidelines.

• Before working on the Launch Checklists, discuss with the internal team if the Special Projects Team will launch the site or if it needs to go through Systems.
  • If Systems are launching the site, you can discuss a launch plan with them on their P2 (███████████████).
• Follow our Launch Checklists in the days leading up to and including launch day.
  • Remember, if the theme has been migrated to the WPCOM repo, the Project’s GitHub repo can be used for tracking issues. However, the code is linked to a redundant or deleted site.
  • Internal sites have an Automattic-specific footer, so there is no WordPress.com footer credit link required.
• If needed, involve the internal developer if support is needed before, during, or after the launch.

Post-Launch and Hand-Off

After a site has launched, you will generally remain available to the internal team for the first week to handle any immediate post-launch clean-up and issues.

Just as we would send a pre-def email to an external partner when their site launches, you can use the below to share with the internal team:

Hi [NAME]

Your site is now live at [DOMAIN]!

Our team will remain available to help with any additional updates or needs you have on your new site. Please reach out to us in the ███████████████ Slack channel whenever you have a question we could be helpful with.

We have monitoring in place that alerts us if there’s a problem preventing basic usage of the site. In that case, we’ll work to fix the issue as quickly as possible and keep you informed along the way.

And that’s it! I hope this was helpful.

As mentioned earlier in this post, on the off-chance an A8c-owned or internal site is launched on Pressable or WordPress.com, the site should be added to the list of most valuable sites that require pull requests to be manually reviewed. Please ping in P2: ███████████████ to have the action added to the repo.

Eventually, you’ll hand the project off to the Support Team, who handle ongoing maintenance and support for our partners.

Start a conversation with the Support teams to establish the best way for our internal team to reach out for ongoing support.

---

1. Short for “Automattic”. A8C: The first and last letters of the word, A and c, with 8 letters omitted in between. ↩︎
2. DRI is acronym that stands for Directly Responsible Individual. This is the person who is responsible for ensuring a particular task is completed, but may not be the one to carry out the task. ↩︎
3. RACI is an acronym that stands for Responsible, Accountable, Consulted, and Informed, a framework used in project management to clearly define roles and responsibilities within a project or process. ↩︎
4. SITREP stands for SITuational REPort; this is a broad-view update about the current status of a project. ↩︎
5. Plural for a11n. Short for “Automatticians”.  A12S: The first and last letters of the word, A and S, with 12 letters omitted in between. ↩︎
6. SITREP stands for SITuational REPort; this is a broad-view update about the current status of a project. ↩︎