Working together: project managers, sales, editors, administrators and developers #

This page is for everyone who works on an Exponential site with other people: project managers, sales and marketing, editors, administrators and developers. It answers four questions. Who hands what to whom? When do we meet, and about what? Which documents and records do we share? And who owns which part of the administration?

Exponential itself already draws many of the lines between the roles: what a person sees and may do in the administration is decided by roles made of policies (Roles, policies and unactivated users). This page builds the team's way of working on top of those lines, so that the process and the permissions say the same thing.

Contents #

1. The five roles at a glance
2. The handoffs
3. Who owns what in the administration
4. Shared artefacts
5. Meeting cadences
6. Worked example: from a sales promise to a published page
7. Worked example: an error on the live site
8. When roles disagree
9. Checklists per role

The five roles at a glance #

One person may hold several roles on a small project. That is fine; the handoffs below still happen, they just happen inside one head. Write them down anyway: the next person will need them.

The handoffs #

A handoff is the moment work moves from one role to another. Most project trouble starts at a handoff where something was assumed instead of written down. The table lists the handoffs that happen on almost every Exponential project, with what must travel along.

Rules that make handoffs work #

1. Link, do not paraphrase. When a promise rests on a feature, link the help page of that feature. The help is the shared source of truth for what the product does; every page is in the installation's own doc/ directory and shown at /exphelp/dashboard (The help system).
2. Name the role and the policy. "The editor can do it" is not enough. Say which role, with which policy and which limitation. If nobody can name it, the administrator decides before the work starts.
3. One owner per handoff. The sender owns the handoff until the receiver has confirmed it, in writing.
4. Never send secrets along. Passwords, keys and personal data of customers or users do not belong in issues, chat or e-mail. The help's Report an error page and Setup > System information produce summaries that leave them out (When something goes wrong).

Who owns what in the administration #

The administration shows each person only what their roles allow: "Admin links already follow permissions, so a user never sees a link to something that would be refused" (Security and audit). The table below lists the places a team usually divides between its roles, the policy that opens each one where the documentation names it, and who holds it in a new installation. The last column is a suggestion for your team.

Sources for the quoted holders: the pages linked in the last column and the README section "Exponential Intelligence" (README.md).

Owning a place means #

• You decide who else gets the policy for it, and you ask the administrator to assign it.
• You watch it: the editor watches My pending items, the administrator watches the error digest and the audit alerts, the developer watches the CI checks of the pull requests.
• You are the person others ask first. Write your name next to each row in your project's RACI (Project templates).

Shared artefacts #

These are the documents and records the whole team shares. Most of them already exist in the product or the repository; the team only has to agree to use them.

Meeting cadences #

The product does not prescribe meetings; these are suggestions that fit the handoffs above. Keep each meeting short and end it with written decisions in the tracker.

A template for meeting notes #

Meeting:      <name>            Date: <yyyy-mm-dd>
Present:      <roles, not personal data you do not need>
Decisions:
  1. <decision>  - owner: <role>  - due: <date>  - recorded in: <issue link>
Handoffs agreed:
  - <from role> -> <to role>: <what>, with <what must travel along>
Open questions:
  - <question>  - who answers: <role>
Product pages referred to:
  - <help page or administration page>

Worked example: from a sales promise to a published page #

A prospect asks during a demo: "Can our editors build campaign pages themselves, without a developer?"

1. Sales answers only what the help says: Exponential Layouts lets editors arrange blocks in zones, and rules decide which pages get a layout, "so editors rearrange pages without touching templates" (README.md, "Exponential Layouts"). Sales notes the promise and links The layouts editor.
2. Sales hands over to the project manager: the promise in the customer's words, the link, and the question the customer really has (campaign pages per period).
3. The project manager checks the rule conditions in the README ("siteaccess, content class, query parameter, time") and writes an issue: "Campaign layout by time rule", with acceptance criteria.
4. The developer checks that the Layouts extensions are active on the project's installation (they are required in composer.json, but each site switches them on, see README.md, "How to enable it"), adds any block type the design needs, and opens a pull request.
5. The administrator deploys, and gives the campaign editors a role with the Layouts policies they need.
6. The editor builds the layout as a draft, previews it, and publishes it (A tour of the administration).
7. The project manager accepts it against the criteria and tells sales it is delivered; marketing asks the customer whether it may be told as a story.

Worked example: an error on the live site #

1. An editor gets Something went wrong on our side with a reference ERR-.... They note the reference, the time, the address and the steps, and tell the administrator (When something goes wrong).
2. The administrator finds the request by its reference (Finding an error by its reference) and reads the log around it in Setup > Log files.
3. If it is the site's own setup, the administrator fixes it and tells the editor. If it is in the software, the administrator hands it to a developer with the log lines and the system information report.
4. The developer files it in the right public tracker, or sends the fix as a pull request; the help's Report an error page (/exphelp/report) prepares the issue.
5. The project manager records the incident, its time to resolution and the follow-up in the operations review.
6. If it is a security problem, nobody files it publicly: it goes privately to the address in SECURITY.md.

When roles disagree #

Checklists per role #

Project manager #

• To do: Every team role is mapped to an administration role, with its limitations, in the charter.
• To do: Every open handoff has an owner and a date in the tracker.
• To do: Every promise made to the customer links a help page.
• To do: The meeting cadence is agreed and in everyone's calendar.

Sales and marketing #

• To do: I can name the help page behind every claim I make.
• To do: I hand each promise to the project manager in writing, the same day.
• To do: I demo only on an installation my team controls (Demo scripts).
• To do: I write the product names as the brand rules say (Brand and naming rules).

Editor #

• To do: I know which sections and subtrees my role covers.
• To do: I keep unfinished work as drafts and check My pending items before each content stand-up.
• To do: When an error appears, I pass on the reference, the time, the address and the steps.

Administrator #

• To do: Roles follow the role matrix; no one got extra access by editing the Administrator role.
• To do: The frequent cronjob group runs, so the audit trail indexes and alerts (The audit trail).
• To do: The weekly checklist of Operating a site is done and reported.

Developer #

• To do: Every change is a branch and a pull request; commit subjects start with Added:, Updated:, Fixed:, Removed: or Renamed: (CONTRIBUTING.md).
• To do: Every deploy note names settings, database updates and caches.
• To do: Fixes that help everyone go back to the project (Working with the community).

Related pages #

• Project managers: start here
• Sales and marketing: start here
• Project templates: charter, RACI, checklists, launch and handover
• Running a team on Git
• The leadership reading path
• Roles, policies and unactivated users
• A tour of the administration
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.