The Mattermost Handbook is a continual work-in-progress for Mattermost staff (people who are paid to work on our open source software), contributor community, and end user community. We use it to document the processes that underpin our company behind our software. Its purpose is to iteratively increase clarity for Mattermost staff and community co-building the future of our company and our offerings, and provide a single-source of truth.

Some norms you'll see here in the Handbook:

Growing companies are a work-in-progress

It's Day 1 at Mattermost. We're a growing company and growing open source project out to support the massive transformation underway as open source software unlocks the massive potential of people and teams around the world. As an open source company we like to share early. Sharing ideas early gets us feedback sooner, so we can iterate faster, so we can better results.

When a section of the handbook is at less than the 50% draft stage you should see it labeled in the page description with the % draft status. When a section doesn't have a % draft status, assume it's over the 50% draft stage.

We believe this system has two key benefits:

1. Be more open to feedback and iteration: Having something published publicly can make it seem overly "final". By having pages in our handbook at 1% and 50% we make it easier to go through feedback and iteration cycles.

2. Engage more non-technical people in the discussion: In the past, we've done reviews largely in GitHub pull requests, which is friendly and familiar for technical team members, but more difficult for others. Sharing 1% and 50% drafts in the public for feedback makes our process more inclusive.

Sharing feedback and updating the handbook

Feedback on this handbook is immensely appreciated. There are two ways you can share your feedback:

Key links and materials

Below is a work-in-progress list of key documents and channels at Mattermost. The symbol * indicates material internal to Mattermost staff.

Current Terms

0/5, 1/5, 2/5, 3/5, 4/5, 5/5

We use “x/5” to concisely communicate conviction. 0/5 means you don’t have a strong opinion, you are just sharing an idea or asking a question. 5/5 means you are highly confident and would stake your reputation on the opinion you’re expressing.

Best Practices

AA

AOR

ARR

Annual Recurring Revenue (“ARR”) is a measurement for time-limited subscription contracts. ARR normalizes contracted recurring revenue into a one year period to allow for like-kind comparisons between contracts that have differing start/end dates and/or different contract lengths. In a recurring revenue model, ARR represents the anticipated total revenue from all active contracts for the future 12 months from any measurement period. “Active” is defined as starting from customer contract signing date, not subscription start date. ARR does not include revenue from non-recurring items such as one-time setup fees or professional services.

For example, total ARR from 3 separate customers would be as follows:

Customer A: 6-month contract totaling $60,000. ARR = $120,000 ($60,000/6 * 12) Customer B: 12-month contract totaling $240,000. ARR = $240,000 Customer C: 15-month contract totaling $45,000. ARR = $36,000 ($45,000/15 * 12) Total ARR for Company = $396,000 ($120,000 + $240,000 + $36,000)

Bookings

The ARR associated with sales transactions closed during the period. Note that Bookings and Billings are different, particularly for pro-rated contracts and multi-year contracts. Billings corresponds to the amount the customer is invoiced.

For example, Customer A signs a 3 year paid upfront transaction for $300,000. For Customer A, the bookings amount would be $100,000 ($300,000/3 years = ARR of $100,000) and the billings amount would be $300,000 (what we actually invoiced the customer at time of order signing). Customer B has a contract for 100 licenses at $50/year/license for 12 months, for total ARR of $5,000. They decide to add 25 more licenses after 4 months. For Customer B, the bookings amount would be $1,250 (25 * $50/year) and the billings amount would be $833.33 (25 * $50/year * 8 remaining months/12 months total contract).

Bug

An obvious error in Mattermost software that is typically a code defect. Changes required to accommodate unsupported third-party software (such as browsers or operating systems) are not considered bugs - they are considered improvements.

CAO

Churn

When an existing customer completely cancels and is no longer a continuing customer. Dollar value of ARR is $0 after the reduction.

COM

Contraction

When an existing customer decreases the dollar value of their ARR, either by decreasing the number of licenses, decreasing the number of products and/or the discounting being applied is increased. Note that the decrease is classified as “contraction” if there is still some amount of ARR remaining after the reduction.

Country/Region

Because the term "country" may be either controversial or incorrect when describing a geographic area governed by a state-like political entity we use the term "country/region" to avoid any accidental or implied judgement on the independence of a region. If the term "country" appears to be incorrectly used, when "country/region" is more appropriate, please contact info@mattermost.com.

Collapsed Reply Threads (CRT)

Core Committers

Core committers are staff or community developers with the responsibility to contribute and review Mattermost source code.

CSM

Customer Success Management function at Mattermost responsible for retaining customer revenue, with quarterly & annual targets, including customer relationship management, executive relationships, and quarterly business reviews.

Customer

The primary external audience we are focused on for an initiative, which could be an end user without budget (if our goal is adoption and engagement) or a buyer (if our objective for the initiative is revenue). A customer does not include internal staff, since staff are not external.

Dark Actions

The act of using non-web-discoverable formats (Mattermost channels requiring login, Google docs that aren't web searchable, Zoom call, email, etc.) to share non-confidential information or processes.

Example: Giving someone instructions on how to set up Okta for MFA on the community server in a DM rather than writing it into a handbook entry for all new staff to use and re-use.

DE

Deployment Engineering function at Mattermost responsible for accelerating seats deployed at $50K+ accounts, focusing on single customer pain points & needs by working directly with customers in partnership with post-sales and revenue retention teams, and providing expertise on how to run and deploy Mattermost and the platform as a whole.

Dead Tarzan

Decking

A term for shipping something that is far below quality standards. This term is used by mountain climbers to describe falling off the side of a mountain, which often involves a series of failures, not just one.

Dev Mana

DRI

Directly Responsible Individual means a human individual who is accountable for a given Area Of Responsibility. A DRI is a single person, not a group of people. If there is a shift schedule, define each shift as a separate AOR (e.g. Tier 2 Mobile Support Escalations Weekdays 8am to 5pm Palo Alto time). If you are unsure who is the DRI, make the AOR more specific until the DRI is clear.

Edge

“Edge Release”, a version of Mattermost which indicates the latest unstable release off of the main branch.

ESR

“Extended Support Release”, a version of Mattermost maintained for a longer period of time that will receive security fixes.

Expansion

When an existing customer increases the dollar value of their ARR, either by adding licenses, adding additional products and/or reducing the discount being applied.

Expert Mode

Expert Mode (also known as "Crimson Force Field") is when documentation or on-screen text is written for someone with considerable knowledge or expertise, instead of being designed for a new learner. In general, try to state things simply rather than speaking to just the “experts” reading the text.

If something is extremely difficult to understand, and yet still justified in the mind of the writer, we call it “Crimson Force Field”. This term is intended to evoke the emotional response of coming across something that is difficult to understand, so writers of Crimson Force Field material can empathize with the readers. Crimson Force Field is drawn from an esoteric episode of Star Trek and it is unlikely anyone but the originator of the term understands its complete meaning. Crimson Force Field is itself Crimson Force Field.

False Openness

FF

Fast Futures function at Mattermost responsible for prototyping and validating enterprise customer needs ahead of product engineering investment, which was the approach applied to Calls, MS Teams and OpenOps prior to adding the functionality to the mainstream roadmap.

GNN

Gross Margin (“GM”)-Weighted Magic Number

A measurement to determine sales efficiency. The GM-Weighted Magic Number is determined by taking the Net Change in ARR for the Period (or New Logo & Expansion ARR in the period less Churn & Contraction) times the Gross Margin percentage, divided by total Sales & Marketing spend in the prior period. This metric attempts to quantify how much Sales & Marketing spend is required to generate ARR.

Gross Margin & Gross Margin %

Gross Margin is determined by taking Revenue less Cost of Goods Sold (“COGS” or “COS”). COGS or COS are the direct costs associated with delivering the product or service to existing customers (e.g. cost of Success, Support, hosting costs, etc.). Gross Margin % is calculated by taking Gross Margin and dividing by Revenue.

Gross Revenue Retention

A measurement that attempts to quantify how well a company retains its existing customers. Gross Revenue Retention (“GRR”) is calculated by taking Beginning Balance ARR less Churn/Contraction and dividing by Beginning Balance ARR. Because both New Logo ARR and Expansion ARR are excluded from this calculation, this value cannot exceed 100%.

HW - Help Wanted

Improvement

A beneficial change to code that is not fixing a bug.

Iteration

Latest

“Latest Release”, a version of Mattermost which indicates the latest stable release.

LHS

The “Left-Hand Sidebar” in the Mattermost team site, used for navigation.

Majority Regions

Countries and regions outside the United States are referred to as "majority regions". We use this term for a few reasons, a) we use the word "majority" to remind everyone that the ~300M United States are only a tiny fraction (<5%) of the world's 7 billion people (many American companies refer to the U.S. as "domestic" and the rest of the world as "international" which is counter to the inclusive culture at Mattermost), b) we use "regions" instead of "countries" because there are political issues with some locations.

Mana

An estimate of total energy, attention and effort required for a task - not a measure of amount of code to be changed or cumulative time needed for a change.

A one-line change to code can cost more mana than a 100-line change due to risk and the need for documentation, testing, support, and all the other activities needed.

Every code change added has an initial and on-going mana cost in technical debt, test case coverages, and supportability, which is taken into account in feature decisions.

MBR

The “Monthly Business Review”, where senior leadership team and department heads work with functional leaders to clear escalations, make key decisions & have concrete next steps for the next review period.

MLT

MME

A customer that is any Midmarket ("MM") or Enterprise ("E") organization, including public sector, with 2,500 employees or more, buying a Mattermost subscription that's not on a non-profit or educational discount.

MOR

Monthly Operating Review. A monthly review of operations from each department including a GNN and metrics.

MQL

A Marketing Qualified Lead refers to a prospect deemed to have a higher likelihood of becoming a paying customer based on their marketing activities, e.g. certain website activities (content downloads, etc), trial activations, demo or quote requests, and more.

Net Dollar Retention

A measurement that attempts to quantify the ability to both retain and grow our existing customers. Net Dollar Retention (“NDR” or Net Revenue Retention “NRR”) is calculated by taking Beginning Balance ARR + Expansion ARR - Churn/Contraction and dividing by Beginning Balance ARR. Because NDR includes the impact of Expansion ARR, this value can exceed 100%. NDR does not include the impact of New Logo ARR. This measurement is typically favored by investors.

Both GRR and NDR are typically presented on an annual basis, using a static Beginning Balance at the beginning of the year. For annual presentation, this number represents total Churn/Contraction for the year divided by the beginning balance of ARR at the start of the year. For mid-year discussion and presentation, this number represents total Churn/Contraction for the period (e.g. first half) divided by the beginning balance of ARR at the start of the year. It is important to note that annual churn will naturally present lower than mid-year churn, using this method, due to the fact that the numerator is changing but the denominator is not.

Nerfs and Buffs

Nerfs and buffs are the framework for setting culture at Mattermost.

A "nerf" is a downgraded experience as the result of a behavior.

For example, if half of a team is traveling to a conference and holds a team meeting in a hotel room and the other half calls in remotely but they can't see everyone in the room and audio is low quality, then the team is "nerfing" their remote colleagues. The people in the hotel room are downgrading the experience of their remote colleagues.

Under this framework, we want to discourage behavior that nerfs remote work, so if your team is holding in-person meeting with remote colleagues, please split up to take the call from separate areas so everyone can be seen and heard.

A "buff" is an upgrade experience as the result of a behavior. If a remote team is meeting on a topic with a clear, concise written proposal requesting asynchronous feedback, people who share high-quality feedback asynchronously ahead of the meeting may have an out-sized influence on iterations of the document ahead of the meeting, compared to people who don't provide asynchronous feedback ahead of the meeting.

Here we want to buff asynchronous communication by focusing review on asynchronous comments ahead of live comments.

Culture is the set of behaviors that are nerfed and buffed. As a remote-first culture, we want to buff behavior that promotes asynchronous communication and remote work. We want to nerf behavior that creates unnecessary synchronous meetings.

New Logo Sale

A standard sale with a customer that has never previously purchased any kind of product or service from Mattermost, either directly or indirectly through a purchase by an affiliate on the customer’s behalf. A sale shall be deemed to be a New Logo Sale even if one of customer's affiliates is already a customer of Mattermost so long as (a) the entity making the purchase has never itself previously made a purchase or has had a purchase made on its behalf, and (b) the new sale is either a purchase of a license key to a new Self-Hosted server independent from other Mattermost installs or a purchase of a subscription to a new Cloud workspace independent from other Mattermost workspaces.

Open Actions

PE

Product Engineering function at Mattermost responsible for the software architecture, design and development of the product focused on delivering high quality, reliably built and maintained features, systems and improvements applicable to the broad range of ideal customers.

PgM

Program Management function at Mattermost responsible for leading and executing key cross-functional programs, working with cross-departmental stakeholders to increase operational efficiency and accelerate alignment towards customer and company objectives.

PO

Product Operations function at Mattermost responsible for infrastructure engineering and customer reliability engineering.

PTO

Renewal Success Rate

A comparison of the actual dollar value renewed compared to the total dollar value of contracts up for renewal in the period. This measurement attempts to quantify the “success rate” of renewals scheduled in the period, and cannot exceed 100%. Unlike GRR or NDR, this measurement excludes the impact of any multi-year contracts that are not up for renewal in the period.

RHS

The “Right-Hand Sidebar” in the Mattermost team site, used for navigation.

SAL

A Sales Accepted Lead refers to a prospect that a Sales team has spoken to either in-person (e.g. tradeshow, conference, dinner), or remotely (phone call, video call), and validated the prospect has a legitimate potential to convert to a paying customer.

SBIR

A Small Business Innovation Research (or SBIR) program funded by the U.S. government to accelerate technology innovation in partnership with small businesses. Funding takes the form of contracts or grants. The recipient projects must have the potential for commercialization and must meet specific U.S. government R&D needs.

The program includes Phase 1 SBIRs (concepts with no development work), Phase 2 SBIRs (development work to create a prototype with a potential for commercialization), as well as larger contracts via TACFI, STRATFI and more: https://afwerx.com/divisions/afventures/stratfi-tacfi/

Spinmint

SpinWick

SOM

Standard Operating Metrics are metrics tracked monthly by each department as indicators for operating health and status.

TAM

Technical Account Management function at Mattermost responsible for retaining & expanding customer revenue, including technical adoption & bottlenecks, technical onboarding, issue coordination and escalation.

Tombstoned

YouTweetInFace

Windows Vista Approach

Instead of working iteratively a "Windows Vista approach" attempts to ship significant changes in a complex one-time effort, which seems like a good idea at the time but ends up causing delays, wasted effort, and numerous avoidable errors.

This tempting, high risk approach is named after Microsoft’s “Windows Vista” operating system, one of its most famous examples.

Mattermost Cloud

Describes cloud infrastructure within AWS, where the Cloud Provisioning server, Mattermost Operator, databases, file storage, etc exist.

Installation

Workspace

Cloud Server

Cloud installation

Self-Hosted Installation

An installation, hosted in Mattermost Cloud, with the necessary configurations present to represent a self-hosted workspace (ie, configs, license, configurability, etc).

Tombstoned Terms

The following is a list of terms no longer used with links to their definitions or notes on their deprecation. Tombstoned Terms use H3 headings on this page to distinguish them from active terms, which are H2 in heading formatting.

Tomb-stoned

Vacation-ready

A team and process that is ready for a key member to go on vacation, or spend time away from work.

In the spirit of iteration and continuous improvement, after hitting a significant or repeated issue, we should write a mini-retrospective and share it with the team. This should take 5-10 minutes to prepare.

Following the resolution, the person with the most knowledge of the issue should send an email to the group with the following summary:

1. What was the issue?

2. What might be done to improve our outcomes in the future?

3. What are we changing in our process and/or documentation (if anything) to improve future outcomes?

By taking a moment to reflect, we have the opportunity to uplevel, and create lasting change and improvement.

Mattermost, Inc. is a company based on the Mattermost open source project, which is a messaging collaboration platform for team communication across mobile, web, and PC with instant search, continuous archiving, and unlimited integrations. Mattermost software is used by thousands of organizations around the world in 16 languages.

What we do: Mattermost, Inc. helps solve collaboration challenges for developers, operators & security teams so organizations can focus on business-critical tasks.

Who we serve: Our Ideal Customer Profile (“ICP”) is an enterprise, defense or governmental organization with 2,500+ employees in need of a collaboration platform for mission critical work that meets complex requirements for security, compliance and self-sovereignty. ICP organizations have significant in-house Dev/Sec/Ops talent and the ability to deploy and secure self-managed infrastructure.

We believe that mission critical work is hampered by one or more of the following;

• Risk from non-compliance

• End of Life of existing systems

• Lack of resilience at scale during infrastructure failure or breach

• Competitive Risk

• Need to preserve sovereignty

• Noise/gaps of MS Teams/general collab tools for tech/operational orgs

• Risk from gaps in Mattermost Team Edition for large organizations

• Low efficiency, high delay and error rates due to inflexible platform

• Need interconnect outside of AD domains and CAC systems

What we offer: Mattermost is a secure collaboration platform for accelerating mission critical work in complex environments. We connect teams, tools and processes on a self-sovereign hub with workflow, integrations, real-time messaging, voice, screen share and federation to deliver more focused, adaptable and resilient decision cycles and outcomes.

Mission

Mattermost’s mission is to make the world safer and more productive by developing and delivering secure, open source collaboration software.

Leadership Principles

Leadership principles are deliberate choices defining our behavior. When facing complexity, uncertainty, or ambiguity (CUA) we determine our point of view and our actions through the lens of our values:

• Customer Obsession: We exist to make customers successful. In everything we do, start with customer perspective and work backwards. Earn and keep their trust.

• Ownership: Own the outcomes of your activity. Don’t drop the ball. When we see a vacuum on something important, we jump in – we never say “it’s not my job.”

• High Impact: Align work to our shared vision and focus on those priorities. When deciding to work on low impact or high impact projects, choose high impact.

• Self-Awareness: We understand and seek to understand our strengths and growth opportunities, as individuals and organizations. We are open to critique and share critique constructively and respectfully.

• Earn Trust: Make decisions based on maximizing the trust of others in your judgement. Be open, self-critical, and factual. Earn and keep peoples' trust.

Market

We see a $30B+ market opportunity in the secure collaboration space and the growth of “open source collaboration” accelerating vs proprietary solutions. Open source has already commoditized operating systems, databases, tooling, and virtualization infrastructure. We see the entry of open source into the application layer driving fast adoption of a new generation of open source and open core solutions, inherently more flexible, trustworthy, and economical than past models.

Products and Business Model

Company

Mattermost is an open source, remote-first, communities-centered company based in Palo Alto, California and headquartered on the internet.

Remote-first means that the majority of our staff works from home, cottages, coffee shops and other personal areas, rather than at a shared corporate office location. Mattermost was born in an extraordinary age where remote-first organizations can attract, hire and enable remote teams to produce better technology, business process and business results in less time than office-based teams, while maintaining security and compliance standards.

Remote-first culture flourishes when we share one simple principle: Courtesy. Courtesy means Mattermosters are thoughtful about keeping our communities appropriately informed, following etiquette for discussions, calls and video meetings, and giving and receiving feedback on how to work better together. Courtesy also means we gladly accommodate those who prefer to work out of a dedicated office. We are remote-first, not remote-only.

Logo

Mindsets are “tool sets for the mind” that help us find blindspots and increase performance in specific situations. They’re a reflection of our shared learnings and culture in the Mattermost community and at Mattermost Inc.

To make the most out of mindsets, remember:

• Mindsets are tools: Use common sense to find the right mindset for your situation. Avoid using ones that don’t fit.

• Mindsets are temporary: Try on a mindset the way you’d try a tool. You can always put it down if it doesn’t work.

• Mindsets are not laws: Mindsets are situation-specific, not universal. Don’t use them to debate.

When you read about great leaders, they share mindsets relevant to success in their specific situations, which differ from their peers. Remember that “advice is personal experience generalized” so be mindful about what you apply.

In this context, here are mindsets for Mattermost:

Learn, Master, Teach

Learn a new topic quickly, develop mastery (be the smartest person at the team/company/community on the topic), then teach it to someone who will start the cycle over.

The best teachers can speed colleagues to surpass them. This mindset helps us constantly grow and rotate into new roles, while preventing single-points of failure where only one person is qualified for a certain task.

Slow is Smooth, Smooth is Fast

Rushing to get something done can create confusion, errors, and/or (paradoxically) delays.

When you feel rushed, consider slowing down and taking a moment to ask: What would it look like for this project to be running smoothly?

If you're running a collaborative project, consider:

1. Are the people I'm working with clear on the intent of this project or workflow?

2. Is everyone clear on who needs to do what?

3. Are we aligned on the measures that signal if our work is a success?

Getting to a "Yes" on these three questions can smooth out your process, and move things faster.

Boring Solutions

Use the simplest and most boring solution to solve problems.

The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology or methodology just to make your work more fun; using established and proven tech and processes that best match our needs to ensure a more stable and more familiar experience for you and other contributors.

When facing a high impact problem without a simple and obvious solution, focus your time on:

• Understanding the problem you're solving.

• Understanding how others have solved the same problem in an enduring way.

• What vital changes, if any, are needed to apply a proven solution that works.

Emotion, Assumption, and Priority

Consider when rational people disagree, the cause often comes from one of three areas: emotion, assumption, and priority. Understanding the underlying difference in thinking can help us get to agreement faster:

1. Emotion: Is there a strong emotion biasing the discussion? Talking through that emotion can often solve an issue. It’s okay to have emotions. We're humans, not robots.

2. Assumption: People may have different underlying assumptions (including definitions). Try to understand each other’s assumptions and get to agreement or facts when you can.

3. Priorities: Finally, people can have different priorities. When everyone’s priorities are shared and understood it’s easier to find solutions that satisfy everyone’s criteria.

While the emotions, assumptions, priority mindset won’t work for everyone in every case, it’s helped resolve complex decisions in our company’s history.

Likes and Wishes

An easy way to check in with team members about how things are going.

• What do you like about how things are going?

• What do you wish we might change?

Use these one-on-one or in a group as a way to open conversations about what to keep and what to change in how we do things.

Drafts at 1%, 50%, 99%

Being clear on expectations when asking for someone’s review can help speed and smooth the process. In this mindset, there are three types of review:

• 1% Draft: Completely open to ideas and changes in direction. Rework is inexpensive.

• 50% Draft: Half complete work. There is structure, but also a lot of room for change. Some rework is inexpensive, some is expensive.

• 99% Draft: Nearly completed work. Rework at this point is very expensive.

Shoulder Check

When a new owner takes over a process or a project from a previous owner, there are a finite number of “blindspots” of which the original owner is aware and the new owner will need to understand.

Using the analogy of changing lanes while driving a vehicle and learning to do a “shoulder check” for information that is not visible from standard controls, we have a process for the new owner and previous owner to jointly review processes until the transfer is complete.

• Repeatedly investing in mis-prioritized projects due to a misunderstanding of requirements from project stakeholders and insufficient confirmation of intended outcomes.

Brown M&Ms

A “brown M&M” is a mistake that could either signal dangerous oversights in the execution of a project, or be a completely innocuous and unimportant error. When a brown M&M is found, aim to rule out a dangerous error as quickly as possible. Do fast drilldowns and systematic checks to see if more brown M&Ms are found, and if so, an entire project may need to be reviewed.

Examples of brown M&Ms may include:

• Significant mistakes in process, consistency or documentation suggesting lack of review or lack of understanding of the pre-existing system.

• Ambiguous definitions that would make completion of a procedure difficult or unpredictable.

Correct Minimums: Medic, Field Surgeon, Plastic Surgeon

When making project investment decisions, we optimize for high impact in the context of customer obsession, empowered by ownership, while being constrained by “be proud of what you build”.

The failure case is over-investing in processes and infrastructure, stealing mana from higher priority work, reducing speed and agility for the company and unnecessarily increasing cost and bureaucracy.

The objective of optimization is to invest at minimal levels for efficiency and safety while maximizing impact.

In making these trade-offs, consider the following mindsets:

• Correct Minimum 1: Medic

  Safely fix something that is important, broken, and dangerous as fast as possible. Speed is critical - don't worry about “leaving a scar” on our architecture or business process, just own it and get it done. Solve the problem, do not overbuild.

  Example: Something incorrect on our public website with more than 100 page views a month should be fixed immediately and not delayed to be done with a longer-term project, such as a website redesign. If the staging server cannot be pushed, this means manually fixing production and duplicating that change on staging, rather than trying to fix staging.

• Correct Minimum 2: Field Surgeon

  Triage tasks that are important and broken but not dangerous, and fix the most important things with a minimum time and cost. Scarring should be a low-priority consideration – it's fine to leave scars and it's fine to spend a little energy to avoid big ones. Solve the problem for the next stage of growth, but don’t solve it in two to three stages ahead.

  Example: In Mattermost, spend 2 mana to enable automated messages over 4000 characters to be broken into multiple posts instead of being rejected, which is a problem every developer hits when they attempt to output log information via curl commands.

• Correct Minimum 3: Plastic Surgeon

  Fix and optimize critical, high volume flows in our customer experience and product with heavy investment if needed to make high impact changes. Scars can be avoided and removed to produce a high impact result.

  Example: Click-tracking traffic on about.mattermost.com and optimizing flows to direct visitors to learn about the product and downloading it is a flow that should be continually optimized.

Mini-boss, End-boss

After completing the initial draft of a project, there may often be more than one reviewer to approve changes. This may be for different disciplines to review the work (for example, both development and design teams reviewing code changes to the user experience) and it may also be for reviewers with different levels of experience to share feedback.

When reviewing significant user interface changes, code changes, responses to community or customers, or changes to systems or marketing material changes, it is ideal to have at least two reviewers:

• Mini-boss: Reviewer less experienced in domain or Mattermost standards for the first review.

• End-boss: Reviewer more experienced in domain or Mattermost standards for the final review for the discipline (e.g. development, design, documentation, etc.).

This system has several benefits:

1. The Mini-boss provides feedback on the most obvious issues, allowing the End-boss to focus on nuanced issues the Mini-boss didn’t find.

2. The Mini-boss learns from the End-boss feedback, understanding what was missed, and becoming a better reviewer.

3. Eventually the Mini-boss will be as skilled at reviewing as the End-boss, who will have nothing further to add after the Mini-boss review. At this point, the Mini-boss becomes an End-boss, ready to train a new Mini-boss.

The naming of this term comes from video games, where a person submitting material for review must pass a “mini-boss” challenge before a “end-boss” challenge for different disciplines.

Savor Surprises

When we make important decisions quickly it's important to run at least a lightweight analysis to identify blindspots that could put success at risk. "Savoring surprises" means discussing unexpected findings from an analysis and understanding root cause in order to de-risk our original plan and/or find new opportunities.

Example: In our early days, just months after launching our first commercial product Mattermost had a product roadmap for security and DevOps features that was vetted by customer roadmap reviews. We "savored the surprise" that custom emojis (which we assumed was a vanity feature to be cut) was highly important to support legacy processes that used them to communicate different outcomes of an automated process, like a build break. The surprise made our roadmap more valuable and effective.

A good analysis will result in surprises uncovering blindspots. An analysis that has no surprises is a surprise in itself and the blindspot should be determined. Did the analysis use the right data and methodology? Was it free from the unconscious or conscious bias of someone influential?

RAPID for Complex Projects

When practical, projects and decision-making should be run at the lowest possible level of the organization, by people who are closest to the facts and data.

When a project is complex and involves many stakeholders, a different approach may be needed. We use a RAPID framework for complex, multi-stakeholder projects where clarity in the roles of stakeholders is vital.

RAPID is an acronym for the five different roles a stakeholder might be asked to take on in a complex project: Recommend, Agree, Perform, Input, Decide.

Each stakeholder can take on one or more roles:

To add a new autolink on the Mattermost Community Server:

Vision

Our vision is becoming the leading solution for developer collaboration through an integrated suite of open core tools that accelerate developer productivity, increase software service levels, and raise workplace satisfaction among technical teams.

As the world moves more digital and remote, technical organizations face mounting challenges: stagnating productivity, increasing exposure to outages and service-level degradations, and declining workplace satisfaction leading to staffing churn and expanding talent gaps.

We solve these issues for customers by developing and delivering an open, flexible, developer-focused collaboration suite competing against both point solutions (Slack, Asana/Trello/Notion, WebEx/Zoom/Loom, RunDeck/Transposit/Firehydrant, Confluence/GitHuge Pages) and general-purpose collaboration suites (Microsoft Teams/Office, G Suite).

We deliver our solutions through an open core, product-led growth motion with freemium offerings that flow into usage and conversion from free-to-paid supported by Mattermost champions in customer accounts, frictionless self-serve purchase experience on both cloud and self-hosted instances, and both direct fulfillment and channel-based fulfillment depending on customer preferences and our ability to provide regional support. This motion is accelerated through our BDR and field sales motions with warm outbound into our freemium install base, plus cold outbound into named enterprise accounts driving awareness of the ROI of Mattermost solutions from like customers.

Market

Analysts project that in 2022, over $4.5 trillion USD will be spent on IT. What portion of that investment turns into productivity and results depends entirely on how well teams of software builders and operators can effectively collaborate.

Mattermost competes in a $15B market for "developer collaboration", a segment of the broader general collaboration market focused on accelerating developer productivity through agile workflows across application development, digital operations and security operations. Our focus is serving a market of 30 million developers with an integrated, open core collaboration suite across workplace messaging, project management, incident management, real time communication, and documentation available both in cloud and as a self-hosted component of an organization's digital infrastructure.

Many of these organizations are facing three critical challenges:

Flat or declining developer productivity in post-remote environments. While many technical organizations accelerated productivity in the initial move to remote work--decreasing commute time, onsite logistics, and interruptions--many post-remote environments now suffer from gaps in clarity and alignment that in-office environments provided in the past. The context created by in-person meetings, hallway conversations, war rooms--and even by physical whiteboards and post-it notes--continues to degrade in many organizations. Digital substitutes across meeting organization, note taking, workplace messaging, incident response, and project management have exploded as point solutions. They served as life rafts during the pandemic, but the misfit of teams, tools and workflows is now becoming an overwhelming tax--copy and pasting, inconsistent formatting, unclear access controls, redundancy of information, and the breakage of flow.

Increasing complexity, vendor lock-in and outage exposure. In many organizations the acceleration to cloud has dramatically increased vendor-dependency, data lock-in, and exposure to the business disruption. In some cases, there is risk of both a company’s technical infrastructure and online collaboration tools going down at the same time when they are outsourced to the same vendor, or share dependencies--especially cloud dependencies. These risks may be dramatically heightened with remote work if incident response teams don’t have either a secure physical location to work on mitigations, or online collaboration tools independent of the underlying outage. Moreover, as cloud vendors control more and more of their customer’s data and operations, businesses have fewer options to hold vendors accountable.

Gaps in workplace satisfaction for technical talent. Acceleration in remote hiring coupled with a surge in global demand has made staffing developer organizations an unprecedented challenge. Workplace satisfaction is now more important than ever as a leading indicator of organizational success. Satisfaction includes both conceptual factors, such as opportunities for impact, connection and growth, and concrete factors such as the technologies and tools teams get to operate. Winning on workplace satisfaction in conceptual and concrete factors is a leading indicator of meeting the capacity needs of digital operations organizations, which is a leading factor to market relevance.

Business model

Mattermost uses a buyer-based open core business model to deliver a high trust, self-managed messaging platform for developers and high security end users. We develop a portfolio of offerings at different price points (including free/open source) that align to the needs and budgets of different buyers.

Mattermost Free / open source

The free/open source version of Mattermost is built for developers as an innovative, flexible, high trust collaboration platform that accelerates the productivity and agile workflows of a tight-knit team, and includes the following capabilities:

Channels

Boards

Playbooks

For our cloud community, our "Free" offering is currently a hosted version of the open source Mattermost Team Edition available on demand from Mattermost.com with unlimited users and a flat rate hosting cost of $149/year. While the software is free, we currently do need to pay for hosting costs in this cloud offering, however we also have plans to provide a fully free offering in future subsidized by revenues from paid versions of Mattermost through our open core model.

Mattermost Professional

Our entry-level paid version, Mattermost Professional, is built for team managers - commonly managers of managers - who need additional controls and workflows specific to multi-team coordination. This version can be purchased via self-service, through resellers, or - for accounts over a certain size in certain territories - transacted through our sales team.

Mattermost Enterprise

As usage of Mattermost grows, we have a high scale edition, Mattermost Enterprise, providing enterprise compliance features and high scale support, including self-managed, multi-node, high availability configurations.

Customer journey

Our customer journey starts developers and IT admins seeking better collaboration tools for themselves and their teams. They may have used Mattermost personally, or in a previous role, or heard about the product through word of mouth, review sites, or discovered Mattermost through web search.

Self-served motions

For Mattermost Professional, we have self-serve options to purchasing subscription licenses by credit card.

Sales-served motions

We're focused on a number of sales motions to turn leads and prospects into customers.

Champion-led inbound direct

Prospect comes to us to buy. In this motion, developers or a System Admin deploys the open source or cloud free version of Mattermost, adopts its usage, and realizes value for a small group (~20 for cloud and 5-25 for self-hosted). When they want to scale usage beyond 25 and need administrative features like user management, SAML SSO, and the champion contacts IT and procurement to purchase. IT or procurement contacts Mattermost and is directed to the sales team to discuss a purchase, ask for volume discounting, answer security, compliance or technical questions, and/or negotiate MSA terms on their way to a purchase.

In the meeting, Mattermost AE probes to get a detailed understanding of the customer’s situation and needs using a MEDPPICC framework, and works with the prospect’s IT, procurement, champion, economic buyer and other stakeholders to help the customer envision their success with Mattermost, complete an initial purchase, and set up the account for success in the post-purchase journey.

Key Input: This process often begins with a Marketing Qualified Lead ("MQL") of a certain type (pricing quotation or "Contact Us" request) indicating a "hand held high" level of interest in a purchase, and a work email which can be used to determine the organization from which the MQL originates and can be used to identify the correct member of the sales team to lead and execute on our process based on territory and industry assignments.

This process can also begin with a Product Qualified Lead ("PQL") which is a type of MQL (has work email and can be mapped to a sales person) that has an indication of product adoption and ideally trial activation. In-product trial requests are an example of PQLs that can be used as a starting point for sales to accelerate this motion.

Champion-led inbound channel

Similar to Champion-Led Inbound Direct journey except prospect buys through a channel partner rather than working with our sales team directly. In some cases we don’t have MEDPPICC information nor relationships with the key stakeholders at the accounts, and need to build up that context in order to properly connect with the account.

Key input: The inputs for this motion are the same as for "Champion-Led Inbound Direct" (above) with the exception that PQLs and MQLs may be shared by our sales team with a channel partner, who may have relationships (e.g. vendor agreement with a prospect) or capabilities (e.g. speaking languages that the Mattermost field doesn't) that we don't have.

Sales-led warm outbound

Identifying organizations where the free version of Mattermost is used, contacting people who didn’t reach out to us, and selling our way to close a new customer.

In this journey, the Mattermost sales team, either BDR or AE depending on region and segment, identifies an account where someone seems to be running the open source version of Mattermost (through webchat, contact requests, E0 download data, cloud trials, enterprise trials, noticing “Mattermost” skillsets in LinkedIn profiles, etc.), identifies potential contacts (using ZoomInfo, LeadIQ/LinkedIn Sales Navigator, Demandbase and other resources), and outbounds (via email, LinkedIn, and social media) to different personas in the target organization to eventually connect with Mattermost champions, and for the AE to share the vision, benefits, use cases, ROI, and case studies of our commercial offerings, along with technical pre-sales support, and guide the prospect into becoming a customer.

Key input: The minimum input is a Marketing Qualified Lead ("MQL") with a work email (so organization can be identified and the right sales person assigned), indications of early interest in Mattermost (e.g. newsletter sign-up, unactivated trial request, etc.), and product usage in some form (after MQL identifies the organization, sales can review public information like LinkedIn bios, blog posts, social shares from company employees, open source contributions, etc.).

In an outbound motion the intent is to reach multiple people in an organization, not just the person taking an MQL-creating action, so that marketing and sales resources can be applied to accelerating early interest into envision and unlocking value into purchase and expansion decisions.

Sales-led cold outbound

Selling into organizations that aren’t known to be using Mattermost but who are similar to existing Mattermost customers and could potentially benefit from our offerings, and potentially showed early interest.

This starts with BDRs and AEs focusing on a list of organizations - ”Named accounts” - that aren’t known to use Mattermost, but are similar to existing customers who benefit from Mattermost, finding and contacting the right people at the organization to share about the ROI and benefits of Mattermost solutions, getting meetings, and getting agreement to run a trial to prove that Mattermost would solve the issues the prospect is facing, running the trial with technical pre-sales support, and closing customers who can understand the vision for how Mattermost solves their urgent needs, with a proof of value in the trial to validate the purchase they are making.

Key input: Cold outbound can be started with just a list of "Named Accounts" that we believe would have similar needs and buying patterns as existing Mattermost customers. Ideally there are also MQLs similar to "Sales-Led Warm Outbound" though without the requirement of free usage to start this process.

Channel-led outbound

In some countries/regions, channel partners may execute Sales-Led outbound motions in partnership with our sales teams. This motion can be particularly additive in countries/regions and organizations with languages and culture that can’t yet be supported with our internal sales organization, or to reach the existing customer base of a channel partner who are likely to have similar needs to existing Mattermost customers and likely to buy (e.g. Carahsoft/FedResults).

Key input: The key input for a channel partner is training, enablement and on-going support on how to idenitify and call on high potential existing customers to consider, evaluate and purchase Mattermost offerings.

This motion is not yet broadly used, as the majority of channel activity is currently from "Champion-Led Inbound Channel" (described above).

Frequently asked questions

What keeps other companies from using your open source software to create offerings that compete with your paid products?

We use the acronym "TACTICAL" to summarize the approach to maintaining differentiation of the paid version of our offerings to offerings a competitor may create from our open source code base:

• Alignment: Developer features are free. Paid features are for managers and IT pros, who are less likely to spend time and effort forking and maintaining an open source project vs. deploying budgets to purchase paid features.

• Innovation: Regular ship cycles and high velocity innovation rapidly lower the value of forks.

• Compatibility: Only genuine versions upgrade smoothly to new releases and security patches.

• Architecture: Modular architecture makes the need to fork rare.

• Licensing: Mattermost's trademark is registered internationally, forking requires renaming.

Company Key Info

How Mattermost uses Mattermost

Channels

Think of Channels like rooms in a building. Public channels are open rooms that people can enter and leave freely. Private channels are like private rooms that are invitation-only. Direct Messages are like popping your head into someone's private office to have a conversation. Group Direct Messages are like popping your head in to a shared office to have a discussion.

All channels can be used to communicated, some are better at specific use cases than others:

Public channels

Find public channels from + > Browse Channels and join and leave based on your topics of interest. Use public channels for "open door" discussions of information relevant to everyone in the channel, for example News and Buzz is a channel to share updates on Mattermost being mentioned on social media and in press.

Private channels

Use private channels to collaborate on work that would benefit from privacy, and not appropriate for an "open door" discussion. For example, planning manager training, organizing our next MatterCon conference, procurement processes where financial data could be shared, launch planning activities (which can be fast changing and confusing if shared ahead of launch).

Direct messages

Use direct messages (or "DMs") to send quick notes to someone to get their attention, like "Running late" or "Can you comment on this ticket? [Link]". Avoid using DMs for collaborative work, as it's difficult to share context from a DM discussion with others--use Boards or group channels instead.

Group direct messages

Use group direct messages (or "GDMs") very sparingly, and ideally to send only ephemeral notes to a group like "Running late" or "Please get your forecasts in by end-of-day. [Link]". Once a GDM is sent, it can be difficult for some users to find the channel again, so it's best if it's not a store of data.

Boards

Think of Boards like a project board on a giant wall, with "Tickets" that can contain all sorts of rich information. You can use Boards to managing any project--goals, tasks, interview candidates, SWAG projects--and organize things based on custom properties, like categories, status, dates, numbers and people. Here's some examples:

Playbooks

Think of "Playbooks" as a set of binder on a shelf with plans and procedures for different incidents and processes. Based on the type of incident or process, the context (e.g. time of day) Playbooks will include steps to follow, people to notify and automation to kick-off to rapidly flow through, resolve, and learn from different "Runs" of a Playbook. Examples include:

Email

Think of email like a physical piece of mail you'd want to send to individuals and groups, who might forward the message to others, or reply to the original group. Examples include:

• Cascading Content - If you're making an announcement across management layers and you want to give each layer and opportunity to add context to the message or choose the people to whom it's forwarded and decide on timing, then email is the best choice. For example, if you're announcing a "company day off" you want to give different managers an opportunity to customize the message as it flows through to their teams, some managers who have on-call staff might have to make accomodations (on-call people need to work, but they can choose a different day off) while another manager who's team has been working on a massive project might want to give an extra day off for their teams, etc.

• Approvals - Written approvals that need to be circulated and archived are an excellent fit for email. Offer letter approvals are a good example, which need to flow through different HR and manager approval chains and ultimately archived in our HR systems.

• One new topic - If you have a new topic to discuss in a small group and there's not a good public or private channel, email is an ideal way to start. Choose email over DMs and GDMs if it's an on-going conversation - but choose DMs and GDMs for urgent and ephemeral topics, e.g., "Can you approve this thing?" / "The meeting invite link is broken!", etc.

Documentation

Documentation is like the policy manual for a company. As much as possible, document things publicly.

• Product Documentation - docs.mattermost.com - Make product documentation as public as possible.

• Operating Documentation - handbook.mattermost.com - Document our internal processes and operations.

• Mattermost.com - mattermost.com - Document our customer-facing information.

The security team will assist you in removing access from your lost mobile device to your Mattermost resources, and walk you through the set up of a new mobile device.

At Mattermost, we are using our mobile devices daily at work. This how-to document provides guidance on what steps you need to take when planning to migrate to a new phone.

GSuite two-factor authentication

For GSuite two-factor authentication, please follow these steps:

2. Select 2-Step Verification.

3. You'll be prompted to log in again to prove your identity.

4. Select Change Phone and follow the provided steps.

5. (Optional) If you’ve changed your phone number, update the phone number in the Google Security Center as well.

Okta two-factor authentication

For Okta two-factor authentication, please follow these steps:

2. Log in with your Okta credentials and authentication code from your old mobile device. If you can't sign in, please reach out to the IT team.

3. Select your name in the top right and select Settings.

4. If the Edit Profile button appears, enter your password if prompted.

5. In the Security Methods section, depending on the two-factor method you're using, it will show you Remove or Set up another.

6. Please choose Remove to remove your old device and Set up another to add your new device and follow the instructions on the screen.

For detailed steps-by-step instruction, please go to the links below:

• Andriod user : https://help.okta.com/eu/en-us/Content/Topics/end-user/ov-reset-register.htm

• iOS user : https://help.okta.com/eu/en-us/Content/Topics/end-user/ov-ios-reset-register.htm

Mattermost Leadership Team (MLT)

This section outlines:

• Introduction to MLT

• The operations of administrative, tactical, and strategic meetings

• Process for alignment and cascading communications

• Process for quarterly business reviews, planning, and board meetings

Introduction to MLT

• Ian Tien: Co-Founder and CEO

• Corey Hulen: Co-Founder and CTO

• Kendra Niedziejko: CFO

• David Reardon: Chief Revenue Officer

• Nirosha Ruwan: VP, Legal

• Chen-i Lim: VP, Product

• Natalie Jew: VP Human Resources

Fiscal Year Planning (1%)

Preparation for the annual plan and budget for the next fiscal year begins in the second half of the current fiscal year.

Q3 Planning for Next Fiscal Year

In Q3 we have three goals:

1. Fiscal year defining objectives for company and departments based on our latest thinking.

2. Product Strategy and direction for next fiscal year.

3. D0 & D1 Goals by MLT and MLX Directly Responsible Individual

Typically there is not pressure for budget or headcount discussions in Q3, focus is strategy.

Q3 Punchlist for Next Fiscal Year Planning

1. The company 3-year aspirations are reviewed

2. 1% Next Fiscal Year Strategy and Plan are drafted

3. At Q3 Planning Offsite, MLT reviews Strategy and Plan for next fiscal year developed from 1% draft

4. Action items are documented and developed around obstacles to success of next fiscal year

5. Draft budget based on Strategy and Plan and financial investments required to bring plan to life

Q4 Planning for Next Fiscal Year

The focus of Q4 is arriving at a 99% draft of the plan for next fiscal with alignment across MLT and departments, with obstacles mitigated, and headcount and budgets reviewed.

1. MLT and middle managers work through key defining objectives and map out D0 and D1 goals for next fiscal year

2. Finance works with MLT to draft financials plan for next fiscal year

3. Department heads work with their teams, peer stakeholders, and CEO to develop department D2 and D3 goals.

4. 99% department D2 & D3 goals are reviewed by MLT peers and CEO and agreed

5. Plan for next fiscal year

• Our main company measures are defined and tracked by way of our Standard Operating Metrics (SOM)

  • SOM: Metrics we believe give the best overall understanding of how the company is performing across departments.

• Metrics LifeCycle

  • Choose them

  • Define them

  • Document them

  • Automate where possible

    • Reports and Dashboards

  • Monthly Going Well, Not Going Well & Next Actions (GNN) Review by MLT and MLX.

We have a number of different ways we communicate. Use the right side bar to jump to a specific area:

• Customer Obsession Meetings (COM)

• Surveys

• CEO Listening Tours

Customer Obsession Meeting (aka "COM")

This is a bi-weekly all-staff meeting focused on increasing alignment and awareness of how the company, departments, teams and individuals serve our customers.

1. Chair works 1-1 with presenters to prepare for them.

2. Team members can share meeting agenda topics with Chair via direct message. Must be shared at least 24 hours prior to meeting start and be aligned with the meeting objectives above.

2 - T-8: Chair and Vice Chair meet to review agenda. Vice Chair works with approriate presenters of agenda topics to develope slides for presentation

3 - T-1: COM prep meeting held with Chair, Co-Chairs, and Vice Chair and review the following items:

1. Meeting starts with thematic goal, including the theme statement, defining objectives, and actions the company is taking towards the goal.

2. Introductions for each Week 2 Welcome are confirmed by PeopleOps.

   1. If new hire or manager is away, introduction is postponed to the following meeting.

   2. New team members are introduced on their second week by their manager, including name, role, what they're working on, timezone, additional info as appropriate (max 2 minutes).

   3. New hire can opt-in to introduce themselves if they choose (default is not to require public speaking).

3. Material for each agenda item is reviewed, and contains a link for more information such as a post to a channel, documentation or a blog post.

   1. Each link shared in meeting notes should be publicly accessible to everyone in Mattermost.

4. If computer sound is shared during the call, test it prior to the meeting and install libraries or tools as required.

During meeting

2. (Chair & Vice Chair) Sign into their Zoom account to access recording and screenshare during the meeting.

4. (Vice Chair) Start Zoom recording at 8:00am Palo Alto time.

5. (Chair and Co-Chairs) Run through the agenda, which comprises one or more of the following items:

   • Introduction: One of the founders does an introduction to the meeting. Usually to align company on short and long term objectives, to reiterate larger vision for the company, or to emphasize leadership principles.

   • Good News: News or updates shared by team members.

   • Week 2 Welcomes: New team members introduced on their second week by their manager, or optionally by the new team member themselves.

   • Main Topics: Align and educate team around challenges faced by Enterprise customers and around department near-term goals. Examples include: FOSDEM event highlights and learnings; Enterprise customer's path from pilot to production; department VPMOM share; key updates, use cases or stories from customers.

     • Links to publicly shared documents or slides may be included in meeting notes.

   • Feedback: At end of meeting, conclude meeting with a reminder to share feedback via survey.

After meeting

3. (Chair) Collect feedback from survey and add to next meeting's draft agenda for Chair and Co-Chairs to review.

Staff enablement survey

• The enablement survey will be announced in COM one week before the survey goes live.

• The survey link will be shared at the beginning of COM.

• The link will be posted in the COM channel with "Thumbs Up" emoji reaction.

• All staff are asked to complete the survey and signal completion by clicking on "Thumbs Up".

• Ideally, the meeting will conclude after "Thumbs Up" count reaches attendee count but this is not a requirement.

• An analysis of the results should be prepared and presented within the next 2 - 4 weeks in COM.

Links to previous staff enablement surveys:

CEO Listening Tours

Listening to feedback is vital to iteration and to continually improve everything we do.

Feedback and listening is at the core of our self-awareness leadership principle. We have 1-1s with managers, regular pulse and engagement surveys, People team outreach and conversations, and annonymous feedback available in every weekly Customer Obsession/All-Hands Meeting. CEO Listening Tours are another way we listen.

CEO Listening Tours happen over Zoom in meetings around 25-30 minutes with different groups of 5-8 staff, typically within the same department or in a related function. Managers of the team members in the group are typically not included in the meeting.

Some notes about Listening Tours:

• It's an opportunity to hear from staff about their likes and wishes, which could be about their team, their department, the company in general, or on any topic. These could be likes and wishes off the top of your head, or maybe something you've been thinking about for a while. This simulates an open feedback session at MatterCon where we would ask people to share their thoughts and feelings.

• The priority of the meeting is listening. During these sessions the CEO takes notes and refrains from commentary, though may ask follow-up questions. Notes are "default open" to be shared with managers, executives, and anyone in the company.

• At the end of the session the CEO reads back what they heard. The notes are shared with the management team/s of the group.

• It's then up to managers to decide how to process and address the feedback at the team level. The CEO can also incorporate the information at the company level.

• In the past, participants and managers of listening tours have found the meetings productive for uncovering blindspots at the company and within departments.

If you're not able to make a particular listening meeting, please ping @amy.nicol to add you to a different slot.

How to participate in Listening Tours:

1. Join us: Attend the scheduled meeting, or if it's not convenient, ping @amy.nicol to join a different meeting slot.

2. Share about yourself: Please introduce yourself with the group (even if we all know each other), with your name, your role, the city and country you're in, and what time it is there.

3. Share a like and a wish: If you'd like to share feedback, in the form of a like and a wish, please share it when you feel appropriate. Your feedback can be about anything, something recent ("Wish Zoom was more stable") or something you've been thinking about or talking about for a while ("Really like the Social Coffee channel and meeting people across the company").

4. Confirm you've been heard: As feedback is read back, share if what you had to say has been accurately captured to be shared with our leadership team, execs, and managers.

Listening tours are just another way we gather feedback so we can iterate and improve everything we do. Thank you for helping speed us on our journey of continual improvement.

GNN Updates

A GNN Update is a concise way to share out what's "Going Well", "Not Going Well", and "Next Actions" on a specific initiative or goal.

• Going Well: What's going well, and what would we want to amplify or repeat?

• Not Going Well: What's moving slower than expected? What's in our way?

• Next Actions: Based on what's going well (things we want to amplify or repeat) and Not Going Well (problems we need to solve), what are the next actions we want to take in the next 1-2 weeks? Next actions should include who is responsible for them, a due date and what the expected outcomes and imapct of the next actions.

If a GNN has been shared previously, the Business owner should share the following in their next update:

• Outcomes of previous Next Actions: Share what happened after the last set of Next Actions were shared out, good and bad. If the Next Action wasn't completed, explain why, and then what we'll do next time to complete the action.

• Link to previous GNN Update: Add a link back to the previous GNN update as a reference.

Monthly Business Review ("MBR")

• Each month we review our progress against our company-level standard operating metrics.

• The GNN Updates are prepared by business owners with input from the data owners.

• In the MBR we align on the most important opportunities to accelerate the company, and supporting the DRI with Next Actions across the company to bring a goal back to success.

The following cadence is used to product our Monthly Business Review deck.

Week 1 - Monthly Strategic Review

Intent:

• Begin the month deciding on strategic ISPs, and ISPs from last month’s MBR

Tuesday Meeting - 60m "MLT Monthly Strategic Review"

• Strategic issues as ISPs discussed and decided

• MLT invites MLX as appropriate

• Time permitting, ISPs from prior MBR discussed and decided

• MLT invites MLX as appropriate

• Time permitting, have MLT feedback for 10 minutes at the end of this meeting

Week 2 - Monthly Forecast Update

Intent:

• MLT leaders prepare for MBR by reviewing results with their directs and appropriate MLX teams (e.g. MLX Growth). Forecasts for FY23 Goals are shared, with context.

Tuesday Meeting - 60m hold for "HOLD: MLT MBR Prep"

• Slot for ad hoc ISPs--Tell CEO in Monday 1-1 if meeting is MLT meeting is needed

• Otherwise, this is prep time for MLT and their directs/MLX

Due Date: Forecasts Updated for FY23 Goals by Thursday EOD

• In first two months of the quarter forecast to end of quarter

• In the third month of quarter forecast to end of next quarter

• All monthly forecasts should have a comment with at least the following:

Week 3 - Department/Function Leaders Review

Intent:

• Complete MBR deck to share context, next actions, and escalate any ISPs

Monday Meeting - MLT 1-1 w/ CEO, review draft content for MBR

Tuesday Meeting - 60m hold for "MLT MBR Prep" (replaces 90m MLT Weekly)

• Slot for ad hoc ISPs--Tell CEO in Monday 1-1 if meeting is MLT meeting is needed

• Otherwise, this is prep time for MLT and their directs/MLX

Due Date: Draft deck for Monthly Business Review complete by Tuesday EOD

• MLT leaders, directs & MLX (cross-department stakeholders) to complete their slides

• MLT works with functional leaders (e.g. CSM, Growth, Support, etc.) help dial in data and commentary. Issues requiring escalation should have an ISP prepared.

• Optional: MLT can prepare recordings linked to the deck

• Deck made “Comment Only”. Opened to MLT comments ahead of MBR meeting

• NOTE: Confidential issues (e.g. PIPs, HR, etc.) will be omitted

Week 4 - Monthly Business Review

Intent:

• Complete MBR discussion, get MLT to full context on the business. Escalate & clear ISPs

Tuesday Meeting - 2.5 hour "MLT Monthly Business Review" Meeting

• MLT arrives having read the deck and made comments async (unless comments are sensitive, e.g. HR-related)

• Maximum 20 minutes discussion per department

• Time permitting, MLT can review ISPs queued

Self-Serve Analytics Metric Definitions

The document linked below has been created in hopes of creating a more self-serve Analytics infrastructure for product, product managers, and other employees to perform their own analysis. It provides up-to-date metric definitions, as well as Looker links to pre-filtered jumping off points for modeling the data. This documentation was presented in series of Self-Serve Analytics workshops that were hosted in early June FY22. A recording from the workshop has also been provided below for additional context.

MLT Metrics

This section outlines metric definitions maintained by finance for reporting to investors.

1. These are metrics for MLT discussions

   1. Any metrics shared by a department with the MLT will be asked to work with business operations to define the metric to be listed on this page under standardized naming and MLT definition checklist

2. Definitions center around ARR, GMA Magic Number and NPS

MLT definitions checklist

1. Qualifiers precede metrics names

   1. i.e. use ""Gross Margin Adjusted Magic Number" instead of "Magic Number, Gross Margin Adjusted" to avoid ambiguity when label names are truncated

2. Metric names should only have one possible interpretation

3. All MLT Metrics should have a unique acronym shorter than 8 characters

   1. Metrics will inevitably be shortened, pre-emptive definition avoids collision

ARR

Revenue Metrics

50% complete

• New ARR: ARR from new logos signed, with license start dates in the respective period.

• Expansion ARR: ARR from existing customers with a cross-sell/upsell deal, with license start dates in the respective period (e.g. increased licensed seat count, upgrading from E10 to E20).

• Contraction ARR: Reduction in ARR from existing customers, but where they are still paying Mattermost based on date of license change.

• Churn ARR: Reduction in ARR from an existing customer where they are no longer paying Mattermost based on the license end date.

• Total ARR: Total ARR ending in a specific period.

• IARR: Incremental Annual Recurring Revenue: (New ARR + Expansion ARR) - (Contraction ARR + Churn ARR)

• Count of New Logos (1%): Count of new logos signed, with start dates in the respective period.

• Count of Churned Logos (1%): Count of logos lost where an existing customer is no longer paying Mattermost.

Active Servers

50% complete

• Monthly Server Downloads: Number of successfully completed unique TE + EE downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget / curl downloads.

  • Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.

• Monthly Enterprise Account Server Downloads: Number of Monthly Server Downloads among companies and organizations with over 5,000 employees.

• New Monthly Server Downloads from Named Enterprise Accounts (1%): The first contact or lead from a Named Enterprise Account who were attached to an opportunity either manually by an AE or by Marketo, and who provides a business email on mattermost.com/download after downloading the Mattermost server binary. Excludes Salesforce account types equal to Customer or Partner.

• TEDAS: Telemetry Enabled Daily Active Servers: _**_Number of unique servers that have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console, and send telemetry “activity data” (such as number of users).

Active Users

10% complete

• Total Active Users: The total number of user accounts created on a single Mattermost server. Excludes deactivated accounts, deleted accounts and bot accounts. This is also the “Total Active Users” measure shown in System Console > Site Statistics.

• Registered Authorized Users: Same as Total Active Users.

• Total Registered Users: The total number of user accounts created on a single Mattermost server, including deactivated and deleted accounts.

• DAU: Daily Active Users: The total number of users who viewed the Mattermost site in the last 24 hours. Excludes bot accounts. This is also the “Daily Active Users” measure shown in System Console > Site Statistics.

• TEDAU: Telemetry Enabled Daily Active Users: The total number of users averaged over the last 7 days, who viewed the Mattermost site in the last 24 hours from servers that have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console, and send telemetry “activity data” (such as number of users). Excludes bot accounts.

• MAU: Monthly Active Users: The total number of users who viewed the Mattermost site in the last 30 days. Excludes bot accounts. This is also the “Monthly Active Users” measure shown in System Console > Site Statistics.

• Active User Count: A measure of the number of active users last 24 hours. Legacy measure, do not use this for analysis or decision-making.

GMA Magic Number

Gross Margin Metrics

1% complete

• GMA Magic Number: Gross Margin Adjusted Magic Number (1%): Net New ARR in a period multiplied by Gross Margin in the period, divided by total Sales & Marketing expense in prior period.

• NGMA Magic Number: Non-Gross Margin Adjusted Magic Number (1%)

• Gross Margin: Net sales revenue minus cost of goods sold

  • Net Sales Revenue:

  • Cost of Goods Sold:

Website Traffic

50% complete

• Organic Traffic:

  • Organic Web Traffic: Monthly unique visitors to *.mattermost.org, *.mattermost.com who originate from non-paid sources.

  • Organic Search Traffic: Monthly unique visitors to *.mattermost.org, *.mattermost.com who originate from an organic Google search.

Qualified Leads

1% complete

• MQL: Marketing Qualified Lead:

• PQL: Product Qualified Lead: Installed free TE/E0 version from a Target Account interested in EE features.

NPS

Contributors

10% complete

• 90s Hiring vs Goal (P0, P1, P2): Difference between hiring plan and hires broken out by priority level (P0, P1, P2), function and time.

  • P0 - Roles which hiring managers have flagged as high need.

  • P1 (1%) - Roles which hiring managers have flagged as medium need.

  • P2 (1%) - Roles which hiring managers have flagged as nice-to-have.

• • Note: Excludes translators, integration/solution creators and QA/UX contributors, as we don’t currently have a good way of measuring these contributors.

• Monthly Code Contributors: _**_Number of unique contributors in a given month who have committed at least one line of code to any of the publicly available Mattermost repositories on GitHub, excluding members in the Mattermost GitHub organization.

Product

50% complete

• • End User Product NPS: The Product NPS calculated among end users only (ie. not among Team or System Admins).

  • System Admin Product NPS: The Product NPS calculated among System Admins only.

  • EE Product NPS: The Product NPS calculated among all users in licensed E10 or E20 servers only.

Customer Success

1% complete

• Customer NPS: Customer satisfaction of the product, calculated based on single question “How likely are you to recommend Mattermost to a friend or colleague?", sent two days after booking or renewal is closed. The score is based on a -100 to 100 scale.

• Support Metrics (E10 and E20): Metrics calculated based on Zendesk tickets opened by E10 and E20 customers. Tickets opened by non-subscribed organizations are not counted towards these metrics.

  • Tickets Created: Number of net new Zendesk tickets created.

  • First Response Time [Median, hours]: The median number of hours from when a ticket was opened in Zendesk to when the first response was sent to the customer.

  • Resolution Time [Median, hours]: The median number of hours from when a ticket was opened in Zendesk to when the ticket is resolved.

  • % Resolution Time >7 days: % of newly opened Zendesk tickets whose first resolution time is greater than 7 days.

  • % Resolution Time >14 days: % of newly opened Zendesk tickets whose first response time is greater than 14 days.

  • Number of CSAT Responses: # of new CSAT (Customer Satisfaction) survey responses from customers whose Zendesk ticket was resolved.

  • Customer Satisfaction Score: % of newly submitted CSAT survey responses who responded “Yes” to the question .

Best Practices

To be added.

DRI for this page is Jason Blais

This section provides information about company-wide processes, including

• Issue/Solution process

• Company agreements

• Publishing process and guidelines

This section provides information about company-wide policies.

Quality control process is a work-in-progress, but is based on the principles of iteration and empowering everyone to write an MVP.

Empowerment

Everyone in our community, including users, contributors and staff, should feel empowered to contribute minimal documentation that adds to or improves existing content.

Typical barriers to contributing includes:

• Uncertainty of where to add content

• Uncertainty of how to structure the content (paragraphs etc)

• Too many rules and guidelines

• English not first language

• Intimidating comments or feedback

• Limited or no experience in writing documentation

Our quality control process should ensure we reduce or in some cases remove these barriers to empower everyone to contribute to our public web properties.

Iteration

In addition to empowerement, a second key principle is iteration.

When we iterate, we do the smallest thing possible that adds value, and get it out as quickly as possible. By iterating in partnership with stakeholders, we're quickly listening, understanding, learning, and shipping.

Thus, the quality control process will be focused on post-publication, where updates can be made after the initial version of content has been published.

Contact us requests

All contact us

Enterprise contact usrequests

Contributors

GitHub contributors

• Members of the open source community with contributions to Mattermost GitHub repositories.

  • This does not include internal Mattermost staff

• Definitions:

  • First Time Contributors: The first month someone contributes, they are considered a First Time Contributor that whole month.

  • Old Contributors: Anyone that is not a First Time Contributor.

  • First Contribution: The first contribution ever made by someone. Any following contributions will not be considered a First Contribution.

  • Examples:

    • Person A

      • 2019-01-02 Contribution 1

      • 2019-01-04 Contribution 2

      • 2019-01-05 Contribution 3

    • Would count as

      • 1 First Time Contributor + 1 First Time contribution + 2 Non First Contributions.

CS Account Health Score

Customer Success Account Health Score represents the overall health of a Mattermost SFDC Account.

• Account Has Open Opportunity w/ Renewal Risk Status = 'At Risk'

  • Account Health Score = 20%

• Account Has Open Opportunity w/ Renewal Risk Status = 'Early Warning'

  • Account Health Score = 50%

• **Note: If account has open opportunity w/renewal risk status of At Risk or Early Warning, it will override all other Healthscore metrics.

• Account has a completed Customer Reference

  • Customer Reference Score = 10 additional bonus points

• Account Has No Open Opportunity w/ Renewal Risk Status = 'At Risk or 'Early Warning'

  • Account Health Score = Tenure Score + License End Score + Ticket Score + Task Score

    • Tenure Score = 25 * Tenure Health %

      • Tenure Health %:

        • Tenure <= 0.5 Years: 10%

        • Tenure Between 0.5-1 Years: 50%

        • Tenure Between 1-2 Years: 75%

        • Tenure > 2 Years: 100%

    • License End Score = 25 * License End Health %

      • License End Health %:

        • License End <= 15 Days From Now: 10%

        • License End Between 16-30 Days From Now: 25%

        • License End Between 31-60 Days From Now: 75%

        • License End Between 61-90 Days From Now: 90%

        • License End > 90 Days From Now: 100%

    • Ticket Score = 25 * Ticket Health %

      • Ticket Health %:

        • Count of Tickets Past 90 Days >= 5: 25%

        • Count of Tickets Past 90 Days = 0: 50%

        • Count of Tickets Past 90 Days Between 3-4: 75%

        • Count of Tickets Past 90 Days Between 1-2: 100%

    • Task Score = 25 * Task Health %

      • Task Health %:

        • Days Since Most Recent Task >= 90: 25%

        • Days Since Most Recent Task Between 60-90: 50%

        • Days Since Most Recent Task Between 30-60: 75%

        • Days Since Most Recent Task <= 30: 100%

Downloads

Monthly Server Downloads

All Server Downloads

• Number of successfully completed unique TE (Team Edition) + EE (Enterprise Edition) downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget/curl downloads.

  Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.

Monthly Enterprise Account Server Downloads

• Number of Monthly Server Downloads among companies and organizations with over 5,000 employees.

New Monthly Server Downloads from Named Enterprise Accounts

• The first contact or lead from a Named Enterprise Account who is attached to an Account either manually by an AE or by Marketo, and who provides a business email on mattermost.com/download after downloading the Mattermost server binary.

  • Excludes Salesforce account types equal to Customer or Partner.

Monthly App Downloads

All Desktop App Downloads

• Number of successfully completed desktop application downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget / curl downloads.

  Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.

Finance

Financial numbers cater to a wide range of teams. Below you will find information on ACV, TCV, and ARR. ACV, TCV, Bookings are relevant to Sales/CS and ARR relevant to Finance/CS.

TCV (Total Contract Value)

What the customer bought

• TCV measures revenue from across the entire contract a customer signs.

• Recognized only in the Closed Won Month.

• TCV = Total Contract Value

ACV (Annual Contract Value)

What the customer bought annualized for the first year of their contract

• Recognized only in the Closed Won Month.

• ACV = (Total Contract Value / (End Date - Start Date)) * 365

Bookings

Standard financial term used to define how much sales credit is recognized for a deal. This is also the basis for all commission plans starting in FY21.

• If term length >= 1 year, Bookings = ACV

• If term length < 1 year, Bookings = TCV

• Net New and Expansion only

• Why would we have deals < 1 year?

  • True-ups

    • Customer owes MM 30K for Q1FY21

    • Booking would be 30K on the first day of Q2 (May 1)

  • Co-Term Renewals

  • Ramped Deals

    • Customer signs a 3 year deal on Feb 28, 2020. Year 1 = 50K, Year 2 = 100K, Year 3 = 150K

    • Bookings

      • 2/28/20: 50K

      • 2/28/21: 100K - 50K = 50K

      • 2/28/22: 150K - 100K = 50K

ARR (Annual Recurring Revenue)

What the customer bought normalized for one year length and reoccurs for length of contract.

• ARR is the value of the contracted recurring revenue of your term subscriptions normalized to a one-year period.

• Recognized from start to end of contract.

• ARR = (Total Contract Value / (End Date - Start Date)) * 365

• ARR increases and decreases based on the following categories of change:

  • New: Increase in ARR from $0 to > $0 & New Logo never seen before

    • Caused by a brand new and never before seen Account signing a contract

  • Expansion: Increase in ARR by an Account

    • Caused by seat increase, price increase, or product upgrade

  • Resurrection: Increase in ARR from $0 to > $0 & by a known Account

    • Caused by an Account churning and returning to Mattermost

  • Contraction: Decrease in ARR by an Account

    • Caused by seat decrease, price decrease, or product downgrade

  • Churn: Decrease in ARR from > $0 to $0 by an Account

    • Caused by an Account moving completely off of Mattermost

TCV vs. ACV vs. ARR

Example:

• Close Date: 2019-05-07

• Amount = $250

• Start Date: 2019-06-15

• End Date: 2022-06-14

• Metrics Breakdown (see graph below):

  • ACV one-time $83 in May 2019

  • TCV one-time $250 in May 2019

  • ARR $83 from June 2019 until June 2022

Google Analytics

Organic Traffic

• Organic Web Traffic is the daily unique visitors to *.mattermost.org, *.mattermost.com who originate from non-paid sources.

• Organic Search Traffic is the daily unique visitors to *.mattermost.org, *.mattermost.com who originate from an organic Google search.

Unique Pageview (UPV)

Session

A session is a group of user interactions within a website that take place within a given time frame. A single session can contain multiple page views, events, social interactions, and ecommerce transactions. A single user can open multiple sessions. Those sessions can occur on the same day, or over several days, weeks, or months.

Session Expiration

As soon as one session ends, there is then an opportunity to start a new session. There are two methods by which a session ends:

• Time-based expiration:

  • After 30 minutes of inactivity.

  • At midnight.

• Campaign change:

  • If a user arrives via one campaign, leaves, and then comes back via a different campaign.

Google Analytics Accounts

1. mattermost.com

2. https://mattermost.com/ (old mattermost.com)

3. mattermost.org

4. developers.mattermost.com

5. integrations.mattermost.com

6. docs.mattermost.com

7. handbook.mattermost.com

8. licensing.mattermost.com

9. mattermost.gitbook.io/jira-plugin

10. pre-release.mattermost.com (which is old community.mattermost.com)

11. mattermost.zendesk.com

Google Analytics Limitations

• • Stitch is only able to pull data at a daily level.

  • Aggregating up daily level to a monthly level causes double counting of users that may have visited the site more than one time in a given month.

Hiring

• WIP

Net Promoter Score (NPS)

NPS Survey

Net Promoter Score is computed as (% Promoters - % Detractors) and ranges from -100 (every user is a Detractor) to +100 (every user is a Promoter).

• Promoters (score 9-10): Loyal enthusiasts who will keep buying and refer others.

• Passives (score 7-8): Satisfied but unenthusiastic users who are vulnerable.

• Detractors (score 0-6): Unhappy users who can damage your brand.

If users edit their response to the survey on any particular server version, only the latest rating on each server version is used for computing NPS. Test server data is also removed via the excludable servers list and by trimming any responses submitted on a server version that has not been publically available for 21 days (time delay before an NPS survey is triggered after a server upgrade).

Based on the above calculation method, we can apply a time window (Quarterly Trailing NPS) and a version filter (NPS by Server Version) to represent and track the state of Mattermost NPS.

Quarterly Trailing NPS

1. Encompasses responses across all server versions that are currently in use by customers (with surveys enabled), meaning it is representative of the state of user experience that customers are facing today.

3. Helps us capture week-to-week variations in NPS while being less volatile than NPS by server version given the larger sample size.

NPS by Server Version

NPS by Server Version is a lagging metric since we need to collect a statistically significant sample size before reporting NPS for a server version. Based on historical data, ~2000 unique user responses (~1.5-2 months post-ship) are required for the NPS of a particular server version to stabilize.

NPS by Server Version can be volatile since it can be affected by the upgrade cadence of heavy usage servers. We typically see a surge in responses when surveys are triggered (21 days after server upgrade) for servers with large DAU, which can impact the NPS trend for that server version. Quarterly trailing NPS is not as affected by this since the sample size is larger and responses are submitted on various server versions.

Written Response Feedback

Users can optionally submit written responses to the NPS survey. These responses are reviewed and categorized by the PM team to allow us to stack rank certain initiatives for roadmap planning based on their impact to NPS, reach and effort to design, implement and test.

To determine impact to NPS, we can:

2. Segment the responses based on the feedback category to analyze what requested product enhancements equate to the lowest NPS scores from users.

3. View overall number of responses by feedback category.

Renewal Metrics Reporting

Renewal Metrics in simple terms:

• Available Renewals (X): Total dollar amount of licenses ending is in the Renewal Qtr

• Renewal Rate (Y%): Total Won Amount ÷ Available Renewals where:

  • Won Opportunity License start date falls in the Renewal Qtr

  • Won Opportunity Product Line Type = 'Ren'

  • Won Amount <= Available Renewal Amount

• Forecasted Renewal Rate (Z%): Won Amount + (Total Open Amount * Probability) ÷ Available Renewals where:

  • Won & Open Opportunity License Start Date falls in the Renewal Qtr

  • Won & Open Opportunity Product Line Type = 'Ren'

  • Won & Open Amount <= Available Renewal Amount

• Target (A): Target Total Bookings set for the Renewal Qtr by Finance

• Actual (B): Total Bookings Won in the Renewal Qtr where Product Line Type = 'Ren'

• Target vs Actual aka TvA (C%): Actual ÷ Target

Renewal Target vs Actual (TvA)

• Calculation: Renewal Actual ÷ Renewal Target

• Renewal Target

  • Target set in a given period (Mo, Qtr, FY) by Finance

• Renewal Actual

  • Total Bookings Won in a given period (Mo, Qtr, FY) where Product Line Type = 'Ren'

Renewal Rate (Bookings)

• Calculation: ∑ Gross Renewals ÷ ∑ Available Renewals

• Available Renewals

  • Amount up for renewal at Account level by Qtr

• Gross Renewals

  • Renewal amount booked (up to Available Renewal Amount) where License Start is in a given Qtr

  • Calculation: MIN(Available Renewals,Renewal Bookings)

  • Example 1:

    • Account: Account 1

    • Available Renewals Q4: $100k

    • Renewal Bookings Q4: $130k

    • Gross Renewals Q4: $100k

  • Example 2:

    • Account: Account 2

    • Available Renewals Q4: $100k

    • Renewal Bookings Q4: $70k

    • Gross Renewals Q4: $70k

Forecasted Renewal Rate (Bookings)

• Calculation: (∑ Gross Renewals + ∑ Forecasted Renewals) ÷ ∑ Available Renewals

• Available Renewals (See Above)

• Gross Renewals (See Above)

• Open Renewal Amount

  • Renewal amount for open Opportunities where License Start is in a given Qtr

• Forecasted Renewals

  • Open Renewal Amount * Probability + Gross Renewal Amount (up to Available Renewal Amount)

  • Calculation: MIN(Available Renewals,(Open Renewal Amount * Probability + Renewal Bookings)

Support Tickets

Definitions

Ticket Status

• New: Ticket created that has not been assigned a support agent.

• Waiting on customer: The support agent asks the customer a question and is waiting for their response.

• Waiting on customer - Do not Close: Checkbox on the ticket. This is used for tickets that are expected to be open for a long period of time. This stops the clock.

  • Examples include: The customer requests that the ticket remain open after a solution is provided, the customer is on vacation, or the customer is out ill.

• On Hold: The support agent reaches out to an internal team and is waiting to hear back. Internal teams include Product, Development, or Customer Success. Any ticket that is tied to a Jira ticket is placed On Hold.

• Solved: Support agent provides a solution to the customer. A ticket remains in a Solved status for 48 hours before it is set to Closed. While the ticket is in a Solved status any response from the customer will reopen the ticket.

• Closed: If no response is recorded after 48 hours, a ticket in a Solved status will automatically be set to Closed. Any response to the ticket after that period of time will open a new ticket.

Ticket Level

• Level 1: Urgent Business Impact: Urgent issue on production system preventing business operations. A large number of users are prevented from working, and no procedural workaround is available.

• Level 2: High Business Impact: Major issue on the production system severely impacting business operations.

• Level 3: Normal Business Impact: Moderate issue causing a partial or non-critical loss of functionality on the production system. A small number of users are affected.

• Level 4: Low Business Impact: Minor issue on non-production system or question, comment, feature request, documentation issue or other non-impacting issues.

Ticket Measures

• First reply time: The duration between ticket creation and the first public agent reply on the ticket.

• Next reply time: The duration between ticket's first reply time and next reply time, unless otherwise communicated.

SLAs

First Reply Time - Premium and E20 only

Premium

• L1 (Urgent) - 1 hour

• L2 (High) - 2 hours

• L3 (Normal) - 8 hours

• L4 (Low) - 24 hours

E20

• L1 (Urgent) - 4 hours

• L2 (High) - 8 hours

• L3 (Normal) - 24 hours

• L4 (Low) - next business day

Next Reply Time - Premium and E20 only

Premium

• L1 (Urgent) - 2 hours

• L2 (High) - 4 hours

• L3 (Normal) - 24 hours

• L4 (Low) - 24 hours

E20

• L1 (Normal) - 4 hours

• L2 (High) - 8 hours

• L3 (Normal) - 24 hours

• L4 (Low) - 24 hours

CSAT

CSAT stands for Customer Satisfaction Rating. 24 hours after the ticket is set to closed, the end-user receives an email asking them to rate their experience. In the email the end-user is presented with the question "How would you rate the support you received?". Below the question is the option to select "Good, I'm satisfied" or "Bad, I'm unsatisfied" with the option to leave a comment about their experience.

CSAT Formula

Good, I'm Satisfied / Good I'm Satisfied + Bad I'm Unsatisfied

Active Servers (TES, TEDAS, and TEDAU)

TES

• Telemetry Enabled:

  • Servers have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console.

  • Response to Mattermost's call to collect telemetry data recorded on a given date.

    • For a server to respond, it must be online and telemetry enabled.

• Servers:

  • Servers host Mattermost instances for teams and organizations.

  • Each team/organization can have one-to-many servers installed to host their instance.

    • Small/Medium teams typically leverage a single server.

    • Large teams can leverage Enterprise Edition features to create server clusters that allow them to scale their instance.

TEDAS

A server is considered to have a daily active user, if at least one user recorded activity on the Mattermost server, such as viewed a channel or posted a message, in the last 24 hours.

TEMAS

A server has a monthly active user, if at least one user recorded activity on the Mattermost server in the last 30 days, such as viewed a channel or posted a message.

Note that an update to the metric is considered to only consider activity in the last 28 days to remove weekday variation. However, this change would require in-product changes and thus has not yet been prioritized.

TES: Additional Metric Considerations

There are several ways to view the TEDAS metric, and there are several more ways to create metrics that are derivatives of TEDAS. Below are some of the ways to view, pivot, and/or filter the TEDAS metric to gather additional insights regarding the overall health of the business:

• • Provides the count of Telemetry-Enabled Servers trended by their first telemetry active date.

  • Is an indicator of how many New, Telemetry-Enabled Production Servers are being stood up on any given date, week, month, year, etc. throughout the history of Mattermost.

• • The count of Telemetry-Enabled Servers that are >= 7 days old since their first telemetry active date w/ >= 1 active user logged on the server.

• • The rate (percentage) at which Telemetry-Enabled Servers leave the platform (churn) or disable telemetry within a given number of days since the server's first telemetry active date.

  • Typically (as of 4/15/20), 75-80% of new, Telemetry-Enabled Servers churn within the first 7 days of their first telemetry active date.

Server Considerations

TES only measures the count of active production servers. The Mattermost.server_daily_details table is used to calculate TES and only contains production servers. Mattermost.server_daily_details is derived from the Events.security table.

The Events.security table logs all server responses to Mattermost's call to collect telemetry data. The Server type responses include test, development, and production servers. Conditional logic is used to filter out non-production servers from the Events.security table and insert them into the Mattermost.server_daily_details table.

• Logic to identify production servers within the Events.security table is as follows:

  • Mattermost Version matching recognized format

    • version LIKE '_.%._._.%._'

    • Other version formats are not valid because they indicate a test, development, or custom built instance.

  • No "Dev Builds" and "Ran Tests" recorded

    • dev_build = 0

    • ran_tests = 0

  • Registered Users >= Active Users

    • user_count >= active_user_count

    • Data anomalies occur causing servers to show active users > provisioned users - these servers must be excluded.

Non-production servers

Non-production servers are not included in TES calculations. Test and development servers are non-production servers that can be spun up for testing and various other use cases.

Server Age

The age of a server is determined by the server's first active date. This is the minimum date a response to Mattermost's call to collect telemetry data is recorded. It can be thought of as the server's first recorded telemetry-enabled date -i.e. first active date. The age of the server is calculated as a function of this date. It is the days between the server's first active date, discussed above, and the current date (or other relative date being used as a comparison to calculate server age at any point throughout its lifetime).

• Server Age = Current Date - Server First Active Date

TES, TEDAS and TEMAS Caveats

There are additional data quality issues within the Events.security table that need to be addressed before inserting the verified production servers and calculating TES, TEDAS or TEMAS. The Events.security table is supposed to contain 1 record per server per day. This is not always the case: ~2% of server IDs have multiple rows per day. To select a single record per production server we must:

• Identify the row per production server containing the maximum number of active users on the given date.

  • If the maximum number of active users = 0 then we select the most recently logged row based on the "hour" field value.

TEDAU

TEDAU Events

Currently only a subset of possible events, dubbed "whitelist" events, count towards TEDAU. The reason only a subset of events are captured is a result of exceeding Segment's (third-party event logging service) row limit. In the future, event logging will transition to Rudder (another third-party event logging service), and the list of events that count towards TEDAU will become more expansive.

Deactivating a user in Mattermost will result in TEDAU decreasing, as deactivated users are filtered out of the statistic's query. However, reactivating a user in Mattermost will increase the TEDAU statistic.

TEDAU Caveats

Telemetry-Enabled Active Users vs. TEDAU Metric

The distinction between an individual server's Telemetry-Enabled Active Users and the TEDAU metric is important to note. Telemetry-Enabled Active Users are the collection of users hosted by a telemetry-enabled production server, that have visited the Mattermost site in the last 24 hours. The TEDAU metric is the rolling 7-day average sum of these users across all servers.

Server Activations

A Server Activation is defined as the first date a production server sends telemetry data to Mattermost. In order to send telemetry data to Mattermost, a production server must be set up and activated by the end user. When a production server is first activated its telemetry feature is automatically enabled, which sends security diagnostics information to Mattermost via Segment (soon transitioning to Rudder). The server will continue to send this information on a daily basis until this telemetry feature is disabled by a Mattermost System Admin. A server activation is only captured and counted on the first telemetry-enabled date associated with a specific server.

Monthly Active Users

Monthly Active Users (MAU) are users that have performed an event on or within 30 days of a given date. User events are triggered when a user interacts with the Mattermost platform from their desktop or mobile device. After a user performs an event, that user will remain in MAU for 30 days. After that time the user will fall out of MAU and be classified as "Disengaged".

MAU Engagement Lifecycle Segments

Monthly active users are categorized into Engagement Lifecycle Segments. There are five engagement lifecycle segments: "Persisted", "First-Time Active", "Reengaged", "Newly Disengaged", and "Disengaged". Each segment is derived from the timeline from when a user performs an event. Each Engagement Lifecycle Segment is defined as follows:

• First-Time Active: The first time a user performs an event on the Mattermost platform and is classified as a MAU.

• Reengaged: A user performs an event for the first time after >= 31 days of inactivity on the Mattermost platform.

• Persisted: A user that performed an event in the last 30 days that does not fall into "First-Time Active" or "Reengaged" MAU Engagement Lifecyle Segments.

• Newly Disgengaged: A user, that was previously in MAU, that has not performed an event within 30 days of their last event. A user is only "Newly Disengaged" on the 31st day of inactivity.

• Disengaged: A user, that was previously in MAU, that has not performed an event > 31 days of their last event. A "Newly Disengaged" user becomes "Disengaged" on their 32nd+ day of inactivity.

MAU Considerations

Server Retention

Server retention is calculated as Day N retention, which shows the percent of users who return to the app on a specified day after their first launch.

We do not use rolling retention, which shows the percentage of users who return to the app on a specified day or any day after that. The reason is that rolling retention continues to increase as days go by (someone who comes back to the app on day 31 will count towards day 1, day 2, up to day 31 retention).

For concrete examples, a server is included in:

• day 1 retention, if there is activity 24-48 hours after server creation

• day 7 retention, if there is activity 168-192 hours after server creation

• day 14 retention, if there is activity 336-360 hours after server creation

• day 28 retention, if there is activity 672-696 hours after server creation

Trials

Trial Requests

All Trial Requests

Enterprise Trial Requests

This page outlines the process for escalating sensitive topics within Mattermost.

Why do we need a policy?

There are several sensitive topics raised by the community that we want to address appropriately and consistently at all times.

However, currently the struggles we have as a team is the unclarity on where Mattermost stands on each of the sensitive topics listed below. This unclarity often results in inconsistent responses that lead to confusion for our users, or ingenuine responses that breaks the trust from our community. We want to stop both of these from happening.

This policy is put in place to compel us as a team to have a clear official point of view for each of the listed topics below, with standard responses that can be used by a broader team. Until a clear point of view is reached, a person or a group of people are assigned as the approved responders to avoid unnecessary confusion and broken trust with our users and our community.

Therefore, if you see a question on a sensitive topic, the ask is to follow the escalation process below, and escalate sensitive topics to the approved responders until an official point of view is clearly documented. Once documented, this process will be revisited.

Escalation process

When an issue relating to a sensitive topic is raised (for example, on GitHub issues, Twitter, or elsewhere), it should be posted in the Community Escalations channel with an @-mention to the list of approved responders related to that particular issue.

Raising an issue is the responsibility of whoever is managing community responses in a given forum. However, it is also open for anyone at the company to escalate an issue that they see. It is then the responsibility of the approved responders to review the issue and choose an owner for responding (if a response is appropriate). By default, ownership is delegated to the first person on the list of approved responders.

Sensitive topics

While anyone can escalate a sensitive topic, only approved responders listed below can engage. If you’d like to be an approved responder for one or more of the topics, we welcome the help! Reach out to @jason.blais on community.mattermost.com, and you will be added to the next training session.

1. Non-regulatory Privacy/Telemetry where opinions are at play more than legal or regulatory issues:

   • Approved Responders: Dr. Program Management, Lead PM, CTO, CEO

   • Loop in: CEO, CRO

   • Template Response: To be added

2. Product-related Regulations/GDPR, and other legal issues:

   • Approved Responders: Head of Security, VP Legal, VP Product, CRO, CEO

   • Loop in: VP Legal, Lead PM, CFO

   • Template Response: To be added

3. Licensing, including open source and commercial license inquiries:

   • Approved Responders: Dr. Program Management, CRO, CEO

   • Template Response: To be added

4. Packaging, including requests for making an Enterprise feature free:

   • Approved Responders: Lead PM, VP Product, CTO

   • Loop in: CEO, CRO

   • Template Response: To be added

5. Workplace policies, including hiring locations:

   • Approved Responders: VP HR, VP Legal

   • Template Response: To be added

6. Security vulnerabilities

   • Approved Responders: Head of Security, Security PM, CTO

   • Loop in: CEO, VP Product, CFO

   • Template Response: To be added

7. Illicit use

   • Approved Responders: VP Legal, CFO

   • Loop in: VP Legal, CEO

   • Template Response: To be added

8. Marketing-related Regulations/GDPR, and other legal issues:

   • Approved Responders: VP Legal, CFO, CEO

   • Loop in: VP Legal, CEO

   • Template Response: To be added

9. Governmental data request, e.g. US government requesting user/customer data under US jurisdiction:

   • Approved Responders: VP Legal, CEO

   • Loop in: VP Legal

   • Template Response: To be added

Non-sensitive topics

Non-sensitive topics include feature requests, troubleshooting questions, bug reports, and other user feedback.

Response writing tips

• Don't make false promises or assumptions

  • If you are unsure of the answer, ask someone for help. Do not reply with an assumption or incomplete understanding.

  • Don’t say "we’ll work on feature X" that sets expectations we cannot meet (e.g. after presenting to core team it turns out you can’t implement the feature).

• Choose positivity over negativity

  • Avoid excuses like “we’re busy”, or “our team is small” and turn a missing feature into an invitation to share a feature idea to be upvoted.

• Do your best to link documentation as answers

  • Allow answers to be easily updated dynamically, as documentation is updated.

  • Turn questions that are not answered in docs, but should be, into tickets to create that documentation (and include ticket link in your response).

• Keep community end user information secure

  • If you come across a post that includes the person's IP address, domain name, or other information you think should not be disclosed publicly, edit the post to remove this information. Then click the hide revision button so that your edits won't be visible to others on the forum.

• Be thankful

  • Communities really respond well to being praised and thanked for their work.

• Do not focus on opinions

  • Turn product discussions into conversations of specific audiences and use cases that each product edition serves.

Roles

Below is the list of members mapped to each role mentioned as an approved responder:

• CEO: Ian Tien

• CTO: Corey Hulen

• CFO: Kendra Neidziejko

• VP Product: Chen-i Lim

• VP HR: Natalie Jew

• VP Legal: Nirosha Ruwan

• Lead PM: Katie Wiersgalla

• Head of Security: Daniel Schalla

• Dr. Program Management: Jason Blais

• Security PM: Katie Wiersgalla

On this page

Who can update the Handbook?

Contributions from everyone are welcome, including staff members and community members. You don't have to work at Mattermost to submit an update or fix something that's caught your eye.

How do I know what to update?

"Update the Handbook" is a term we use regularly at Mattermost but it's not always obvious exactly what to update or how. Here are some examples of what a Handbook update could be:

• Updating your team page with new team members and AORs.

• Adding a new page to describe a new process.

• Updating existing content to accommodate a change in process, policy, or requirement.

• Archiving old content that should be preserved for reference.

Updating the Handbook can be as easy as fixing a typo, or as complex as reorganizing an entire section. The key is to update it regularly, so that updates are less daunting and time-consuming.

Hints and tips

The Handbook is a public-facing body of work and although it's a constantly-evolving work-in-progress, we still need to ensure our content is accurate, easy to read, and clear.

• Be concise: Say what's essential, not more.

• Don't aim for perfection: Our goal is regular iteration, so your content doesn't have to be perfect before it's published. It will be reviewed by an editor prior to publication so any major errors will be addressed then.

Your first Mattermost contribution

Now you're ready to get started.

Edit an existing page

Once a page is edited and you're happy with the changes, it's submitted as a pull request which is then reviewed. If there's any feedback or comments have been made, you'll be alerted. If suggestions have been made, you can choose to commit them (add them to your content) or you can ask the reviewer for more information before doing that.

When the PR is approved, it'll be merged and published. If you have more changes to make, you can simply repeat the process.

Edit a page directly

This is probably the quickest way to make changes, as it doesn't require you to find the file in the repo first.

1. Login to your Mattermost GitHub account

2. Open the Handbook and navigate to the page you want to edit.

3. Underneath the blue banner, locate three dots next to the page title at the top of the page. Click on the three dots and choose Edit on GitHub. This action will open the page in GitHub.

4. In GitHub select the pencil icon in the navigation bar (above the page header) called Edit this file to open the editable Markdown-format page. If you see Edit this file in your fork of this project the process is the same, it just means you're not part of the Mattermost organization and are working in a forked repo.
5. Make your edits. When you're ready to submit your changes, commit your changes to start a pull request.

6. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made.

7. The default setting is Create a new branch for this commit and start a pull request. In the field below that, you can customize the branch name - you can also leave it as default.

8. Select Propose changes.

9. On the next page, you can scroll down to compare changes with the original document to double-check your changes.

10. If you're happy with them confirm that the title and description are correct, then select Create pull request.

Once a pull request has been submitted, a core committer with write-access assigns relevant reviewers and labels to kick off the review process. The review process includes aligning the content with the Style Guide, validating the changes, and tagging any other relevant committers.

Edit a file in the repo

This option works best if you know where the file is located in the repo.

2. Navigate through the directories to the file you want to edit.

3. Once you've found the file, select Edit this file in the top corner. If you see Edit this file in your fork of this project the process is the same, it just means you're not part of the Mattermost organization and are working in a forked repo.
4. Make your edits. When you're ready to submit your changes, commit your changes to start a pull request.

5. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made.

6. The default setting is Create a new branch for this commit and start a pull request. In the field below that, you can customize the branch name - you can also leave it as default.

7. Select Propose changes.

8. On the next page, you can scroll down to compare changes with the original document to double-check your changes.

9. If you're happy with them confirm that the title and description are correct, then select Create pull request.

Create a new page

2. Navigate through the directories until you reach the section where you'd like to add your new content.

3. Select Add file > Create new file.

When you create a new page in the Handbook ensure that:

• The page name is all lowercase

• There are hyphens instead of spaces between the words.

• New page names end with .md.

1. Write your content as needed.

2. When you're ready to submit your changes, commit your changes to start a pull request.

3. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made.

4. The default setting is Create a new branch for this commit and start a pull request. In the field below that, you can customize the branch name - you can also leave it as default.

5. Select Propose changes.

6. On the next page, you can scroll down to compare changes with the original document to double-check your changes.

7. If you're happy with them confirm that the title and description are correct, then select Create pull request.

Create a new section

If you want to create nested content, you can create folders. You cannot create an empty folder and then add files to that folder, but rather creation of a folder must happen together with adding of at least a single file. On GitHub you can do it this way:

1. Navigate to the folder within which you're creating your new folder.

2. Select Add file > Create new file.

3. Enter the new folder's name in the text field and add / at the end.

4. In the next text box, enter the name of the new page, ending with .md.

5. When you're ready to submit your changes, commit your changes to start a pull request.

6. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made.

7. The default setting is Create a new branch for this commit and start a pull request. In the field below that, you can customize the branch name - you can also leave it as default.

8. Select Propose changes.

9. On the next page, you can scroll down to compare changes with the original document to double-check your changes.

10. If you're happy with them confirm that the title and description are correct, then select Create pull request.

Frequently asked questions

How do I format a page?

How do I update the left-hand navigation?

Important note:

GitBook dynamically changes the URL based on the location in the table of contents. This means that when a page changes its location, the previous link results in a 'page not found' error.

There is a redirect file that we use to prevent this in the gitbook.yaml file. Please mention @jason.blais or @carrie.warner in Mattermost (@jasonblais or @cwarnermm in GitHub) for assistance if needed.

How do I add an image to the documentation?

Follow these two steps:

• Next, go to the section you want to add an image to and include the following Markdown formatting:

  Copy

  ![](../../../.gitbook/assets/release-timeline-jan2020.png)

Can I convert a Google Doc to Markdown?

Once the add-on is installed, there are a number of conversion settings you can configure. Selecting all but the Use HTML headings/IDs option is recommended.

• To see the embedded errors and warnings, disable the Use reckless mode option.

• To see all conversion details, disable the Suppress info comment option.

The resulting Markdown code isn't perfect, but it's an excellent initial step towards preparing a PR for the Mattermost Handbook. Review the following areas of converted code:

• Embedded images must be saved out as files, added to appropriate image folders, and links need to be added to point to correct locations.

  • If the doc contains screenshots or other image assets, right-click on the embedded image in the Google Doc, then select Save to Keep.

  • In the right pane, right-click on the image in the Keep list, then select Save Image As. Rename the image file as needed to match the Markdown code.

• Images need to live in the .gitbook/assets folder and must use a relative link in the source file.

• Numbered lists and nested lists likely need corrections.

• Many lines end in a / which need to be removed.

• ALT tags are added as alt_text for all images. Update the ALT tag to be more descriptive, or remove it altogether.

Training video

Official Handbook reviewers

Below is a list of approved reviewers.

1. @cwarnermm: Reviews major changes to handbook.mattermost.com, such as updates to the Table of Contents (SUMMARY.md).

2. @cwarnermm: Editor reviews of all submitted PRs for correct grammar and consistent style.

Each PR should be reviewed by at least one approved reviewer. A build check requiring at least one approved review prior to a merge is planned, similar to other Mattermost repositories.

Below is a list of permissions handbook contributors have access to:

1. @jasonblais, @amyblais, @cwarnermm: Write permissions to the repository.

2. Staff contributors: Submit changes to handbook.mattermost.com using PRs. May have access to request reviews, add labels, submit PR reviews, and be requested as reviewers.

3. Non-staff contributors: Submit changes to handbook.mattermost.com using PRs. Do not have access to request reviews, add labels. Can submit PR reviews.

This page summarizes our processes and instructions.

Instructions for Monthly DRI updates

2. Share Forecast - Open each goal and update the "forecast" field with your forecast for the end of the period. E.g. For "Q1 Forecast", put in your forecast for Q1 ending number.

3. Set "Status - Status is a summary of how you feel progress is going.`

   • GREEN - If you believe you'll hit your target by the end of the period, set status to Green.

   • YELLOW/RED If you feel your target is off-track, but there's still a chance to hit your target, set status to Yellow, and if it's way off use Red.

   • UNREACHABLE If you feel it's impossible to reach your goal, set your status to UNREACHABLE. Your MLT member will work with you to bring this to the monthly review meeting to discuss how we can adapt as a company.

   • DATA NEEDED If you don't feel you're able to provide a forecast, or are unsure about anything in the process, set status to DATA NEEDED.

4. Share "Going well" and "Not going well" - Add a comment to share more context about your goal. Include at least the following:

   • Going Well: Share wins, successes, and good news in general. Share "Thank yous" to people who have helped, and @mention them if you feel appropriate.

   • Not going well: Share the key issues you're facing. If the status for the goal is not Green, share the key reasons why in this section.

   • Next actions: Share key actions to be taken in the following month, with owners and checkins. Be specific.

5. Update the "Last Forecasted" - Update the field "Last Forecasted" with the date of your forecast so MLX knows it's been completed.

Issue/Solution Proposal Process

Issue/Solution Proposal (ISP) is a tool for increasing clarity, speed, and output in teams.

Decision-making

Getting buy-in

One of the core challenges in leadership is getting teams to buy into a decision intellectually and emotionally.

You create buy-in when you make people feel they're part of the decision, and that their input contributes to the final outcome. The more influence they feel they have on the outcome, the more they’ll be invested in the final result.

Broadly, there are three ways to make a decision. Each has a different time requirement, and creates a different level of buy-in. The methods that create the most buy-in also take the most amount of time.

Method A: Unilateral decision

For a decision where there's a clear decision maker based on Areas of Responsibility (see Type 1 vs Type 2 below), the decision maker announces a decision to the team, and answers questions. This is typical when a decision is within someone’s Area of Responsibility.

Example: A digital marketer who's responsible for managing the executing of advertising campaigns using different vendors would make a Method A decision on which vendors to choose, and let others know.

Pros:

• Takes very little time.

Con:

• Creates very little buy-in and gets no benefit from the team’s knowledge and experience.

Method B: Issue and solution proposed

A decision maker creates (or assigns someone to create) a written straw man (a hypothetical answer designed to inspire discussion), shares it with the team, invites team to give feedback (written and verbal), facilitates group discussion, makes everyone feel heard by repeating back their comments, and then makes a final decision.

Pros:

• Creates more buy-in. Gets some minimal benefit from the collective wisdom of the team.

Con:

• Takes more time.

Method C: Wallow on strategic issue

A decision maker invites a team to a meeting where a dilemma is discussed from scratch with no straw man. The team shares ideas. The decision maker repeats back everyone’s ideas until they feel heard. The decision maker shares their own idea last (because theirs is the loudest voice in the room). Lastly, decision maker makes the decision.

Note that this is not a consensus decision. Buy-in is created by the decision maker confirming that they heard all ideas, not by accommodating all ideas.

Pros:

• Creates the most buy-in. Gets a lot of benefit from the collective wisdom of the team.

Con:

• Takes the most time.

Not surprisingly, the greatest benefits require the most work. If you want more buy-in and a better decision, you need to take more time in making the decision.

So, which method should you use? It depends on how significant the decision is, and how important buy-in is.

For everyday, low-impact issues (for example, entering a new reseller relationship), Method A is sufficient. For major, core issues (for example, Company 10-Year Vision), Method C is necessary. For everything in between (the vast majority of important decisions), Method B is optimal.

For Method B, we use the Issue/Proposed Solution method.

Issues/Solution Proposed (ISP)

Team members will often want to bring up an issue and discuss it verbally. This is both inefficient (listening takes longer than reading) and ineffective (in verbal discussions the most vocal people often have the most influence).

Instead, we require that anyone who presents an issue at a team meeting do so in writing. The write-up should include both a detailed description of the Issue as well as their Proposed Solution. A team member asked to do a write-up might say “I don’t know the answer.” It doesn’t matter. They should take a guess and create a strawman. Even if they only have 10% confidence that their answer is the right one. And they should phrase the Proposed Solution in very bold, directive terms (“Do this ….”). This may seem aggressive, but it plants a flag in the sand which generates a much more productive discussion and a quicker decision-time, which is more important than appearing to be humble.

All Issues and Proposed Solutions are presented at the weekly Team Meeting, including a pre-recording that can be replayed asynchronously at high speed to save time.

Allow up to 5 minutes of discussion for each tactical (short-term) Proposed Solution and up to 20 minutes for each strategic (long-term) Proposed Solution. If in that time, the decision maker feels that they have enough context to make a decision, they announce and write the decision. The Solution is turned into one or more Next Actions with a DRI (Directly Responsible Individual) and Due Date for each.

We use an Issue/Solution Proposed (ISP) template to structure these issues, and typically include a recording of the issue so it can be explained quickly and concisely.

If the decision maker feels they don’t have enough context to make a decision, DO NOT spend more time talking about the Issue. Instead turn to the RAPID decision-making framework described below.

Type 1 vs Type 2 decisions

A Type 1 decision is a “one-way door”. Once it’s made, it’s very difficult to reverse. Acquiring a company, or discontinuing a product line are examples of Type 1 decisions.

As organizations get larger, there’s a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We need to fight that tendency.

Each time there is a decision to be made, rate it as Type 1 or Type 2.

• Type 1 decisions should be made by the CEO.

• Type 2 decisions should be made by someone who is not CEO, unless it impacts CEO-specific AORs.

Most decisions are Type 2.

RAPID decision-making

When a decision is complex and can’t be reached efficiently even after a well-prepared ISP, we should use a RAPID framework. This is in specific cases when:

• A team has become too large to easily get all of the needed voices in one room.

• Consensus cannot be reached within 5-20 minutes of discussion.

Here is an Example of a RAPID. In an Issue/Proposed Solution using RAPID:

1. Someone identifies an issue or decision that needs to be made. They write up:

2. The Issue

3. The Proposed Solution

4. The list of people needed to make and implement the decision:

   • R (Recommend) = the one who first proposed the Issue and Solution.

   • A (Agree) = those people whose input must be incorporated in the decision. This is typically blank, unless is is the legal team to ensure no one is breaking the law. It should be very rare that anyone else's agreement is required for a decision.

   • P (Perform) = those people who will have to enact any decision and therefore should be heard.

   • I (Input) = those people whose input is worth considering.

   • D (Decide) = the one who will make the decision.

     • If Type 1, this should be the CEO.

     • If Type 2, this should be someone other than the CEO.

5. A section on the document for each person above to write their comments.

6. The R then reaches out to all the As, Ps, and Is to solicit their input. Once this input is received, the document is ready to be reviewed by the D. If the ISP involves an off-cycle budget change over $100K, R should work with finance team for their estimate of impact to financial plan.

7. The R schedules a Decision Meeting and invites the D, As, Is, and Ps.

   • If the issue is urgent, the R schedules this Decision Meeting as soon as it needs to be.

   • If the issue is non-urgent, the R can use the next Team Meeting as the Decision Meeting. This is much more efficient, and should be done whenever the issue is non-urgent.

8. At the Decision Meeting, the D reads through the document. If they have any questions, they asks them. If the questions can be fully answered in 5 minutes, they decide. If the questions can't be answered in 5 minutes, the D asks for another round of written responses on the document to answer the questions. At the next Team Meeting, the D reviews these responses, and decides.

9. Once the D decides, they write up the Decision (or asks the R to do so) along with all the Next Actions (each with a DRI and Due Date). The D then publishes this decision to the company via the appropriate ticketing system and/or other channels.

Note: Pull Requests for updates to this page need to be signed off by both CFO and CEO in the PR process.

Who can sign on behalf of the company?

Company agreements should only be signed by CEO, Ian Tien, or CFO, Kendra Niedziejko, with the following exceptions:

• If you are on-site and need to sign an NDA to enter a facility you may sign such an agreement.

• The following agreements may also be signed by the VP Legal, Nirosha Ruwan:

  • Non-Disclosure Agreements.

  • Data Privacy Agreements

• The following agreements may also be signed by the CFO, Kendra Niedziejko.

  • Unmodified Order Forms where the Customer is requesting a Mattermost signature.

  • Vendor contracts.

• Any contracts with terms that could have material impacts on financing or M&A transactions may only be signed by the CEO (e.g. non-standard liability, indemnification or inability to assign the agreement).

Who can send contracts for signature?

The following staff are approved to send contracts to be e-signed:

Approved Mattermost staff

• Lynn Conway - Primary for staff agreements

• Amy Nicol - Primary for vendor contracts, consulting agreements, and corporate agreements

• Nikki Johnson - Primary for sales agreements and customer supplier forms

• Jeff Dynda - Approved vendor contracts from legal and customer supplier forms

• Natalie Jew

What are e-sign completion expectations?

• E-sign request sent on weekdays before 4pm Palo Alto time should be signed by 9pm Palo Alto on the same day and if sent on a weekend signed by 9pm Palo Alto time on the following Monday provided one of the following is true:

  • For e-sign from Mattermost staff member: The e-sign is sent by a Mattermost staff member and must have Legal approval. E-signs sent from approved Mattermost staff are preferred since they are archived automatically in our e-sign system.

  • For e-sign from outside the company: The e-sign is prepared by a non-Mattermost staff member (potentially a vendor, partner or customer) and Legal approval is provided via email to Ian Tien and Amy Nicol ideally ahead of receiving the e-sign request.

    • Within 5 business days of the e-sign completion the contract owner or Mattermost staff submitting for signature should send Amy Nicol a link to the Box.com URL containing the fully executed signature to confirm the archiving of the contract is complete, since archiving is not automatic.

      • Note: E-sign requests from non-Mattermost staff are automatically filtered to a spam folder and the spam filter needs to be searched to find the request.

• If the timeline is urgent, or if the e-sign isn't completed by the expected timeline please send Ian Tien and Amy Nicol a Group Direct Message on the Mattermost server to expedite.

How to wet sign an agreement

• A "wet sign" agreement requires printing and physically signing paperwork with a pen, which is required by some regulatory bodies.

  • Culturally, it is important we have a smooth, clear process that makes physically signing paperwork in a remote company almost as easy and error free as signing in a physical office.

• Wet sign process

  • The wet sign process should follow the same workflow process as an e-sign process in terms of oversight and approvals, but instead of running the final e-sign a physical signing packet should be created with:

    • Two copies of printed paperwork to be signed.

      • Each should have sticker labels indicating what is needed to sign, so nothing is missed.

    • A pen.

    • Appropriate envelopes and/or UPS mailing labels to send the signed package on after it is received.

This page provides processes and guidelines for publishing in our public web properties.

The goal is to have clear public web properties where it is easy to find solutions to problems or questions you have for each of our audiences:

• Staff to do their work effectively.

• Users (including developers, administrators and end users) and Buyers to easily adopt and purchase Mattermost.

• Contributors to easily contribute to Mattermost.

Principles

Trust

• Consistent experience across public sites, including brand and voice.

• No inaccurate information.

• No "dead ends" where the user does not have a pathway to continue.

• No confidential information.

Growth

• Effective self-service where anyone can find solutions to problems or questions starting from a Google search.

• Scalable processes and guidelines that empower everyone to contribute.

Iteration

• Iteration over completeness, with constant openness to feedback.

Directly Responsible Individuals

Below are the tentative directly responsible individuals (DRIs) and success measures for each of our audiences:

Please read the following articles to learn more:

This page provides publishing guidelines, including

Below is a set of guidelines on what information is considered confidential and should not be published publicly:

• Financial information related to Mattermost, such as revenue and cash, as this may impact potential future funding and IPO.

• Usage metrics and analysis related to Mattermost deployments (such as telemetry, trial conversions, DAU) as this may impact potential future funding and IPO.

• Personal information related to staff, customers or community, including residence and full name unless otherwise publicly disclosed.

• Customer information received during support or sales discussions, including customer name unless usage of Mattermost is otherwise publicly disclosed.

• Open discussions about security vulnerabilities, as this may put our users at risk of security attacks.

The Mattermost logo

The logos below are available for use in your integrations and applications that connect to Mattermost. Use of the logo is permitted as long as it’s used in a non-commercial way and does not imply endorsement by Mattermost, Inc.

The Mattermost logomark is called "the instrument". It represents four tools that organizations need to achieve their highest priorities:

• A compass for direction

• A clock to set pace

• A meter to measure output

• A dial representing inputs — the contribution of everyone on the team

Logo variations

The Mattermost logo is available in vertical, horizontal, and logomark-only versions. The logo can be represented in black or white as displayed below.

Horizontal Logo: Min size 100x16px

Vertical Logo: Min size 70x39px

Logomark: Min size 16x16px

Usage guidelines

Clear space

To ensure an uncluttered presentation, always maintain a full "X" space around the logo. The "X" height is always the height of the lowercase letter "m" in "Mattermost". Use the safety area as an invisible border.

Misuse

Please use the Mattermost logo with care. Don’t alter the Mattermost logo in any way:

• Don’t redraw the logo.

• Don’t warp the shape.

• Don’t recolor the logo.

• Don’t apply effects.

• Don’t crop the logo.

Make sure you’re using the correct version: some old and distorted versions from the past exist and should be replaced.

Logo downloads

Brand guidelines