Onboarding

This document is intended for new hires to summarize norms for working at Mattermost, Inc. including:

Getting Started Checklist

Important things to know

  • Never sign any agreement on behalf of the company. The CEO is the only person authorized to sign an agreement on behalf of Mattermost, Inc. The only exception is that you are authorized to sign a non-disclosure agreement to enter a physical space. If you have questions, please check with your manager.

Hiring

  • (People Ops and New Hire) Offer letter accepted via click-sign
  • (Logistics) Mail track jacket and socks

T-minus 1-3 weeks

  • (People Ops and New Hire) People Ops should find out new hire’s preference for laptop, either to be purchased or taken from stock and shipped by People Ops or purchased locally by new hire and expensed. Windows laptops generally cost less than Macs so budget is based on Macs. For non-developers, budget is cost of a Macbook in your local area, for developers budget is cost of a Macbook Pro. Since these items are company property, you do not need to buy insurance or extended warranties for them, but you do need to report any loss or damage to People@mattermost.com as soon as it occurs.
  • (New Hire) Read the entirety of Onboarding page for info on meetings, mindsets, terminology and training materials.
  • (People Ops) Send email invite to New Hire to set up an @mattermost.com email address. New Hire should use this email address on community.mattermost.com (replace personal email with company email if already registered there). FIRST_NAME.LAST_NAME@mattermost.com is the standard naming convention.

T-minus 1 week

  • (People Ops and New Hire) Set up payroll.
  • US FTE, receive email to complete TriNet sign-up, payroll, benefits enrollment, I-9 form, banking information, personal information, tax forms.
  • Non-US Employee/Non-Canada Employee, complete bank info form for monthly wire transfer.
  • Non-US Resident Contractor, complete W8-BEN form.
  • US Contractor, complete W-9 form.

First Day

  • (Manager) Posts welcome message in stand-up channel.
  • (Manager) Meets New Hire for first 1-1 meeting.
  • (People Ops) Meets New Hire for check-in meeting.
  • (Buddy) Meets New Hire for first 1-1 meeting.
  • (New Hire) Confirm with Manager all HR paperwork is completed by end of first day (should have been sent in advance).

First Week

  • (CEO) Meets New Hire for welcome meeting.

3 months

  • (People Ops) US FTE - Email regarding 401K account set up.

Channels

Whenever possible, we share key updates and have discussions in Mattermost. Some of the channels used are:

Meetings

This section summarizes norms for public and private meetings for the Mattermost community and for Mattermost staff (people paid by Mattermost, Inc.).

Timezones

When proposing meetings use famous cities as references for time (e.g. 9am Toronto time), since it’s clear and easy to web search. Avoid using “UTC”, as it has been shown to cause confusion.

When selecting a timezone city, use the most well-known city in a country where at least one team member is located. Exception: When possible, use a city where we have an official mailing address, e.g. In Western Americas use Palo Alto, instead of San Francisco. In Eastern Americas use Toronto, instead of New York.

Scheduling Recurring Group Meetings

Recurring meetings with more than two people should have one or more regular slots on the calendar reserved so that meetings can be coordinated in a straight-forward way.

  1. Meetings with internal colleagues should be coordinated by checking everyone’s availability in G Suite Calendar.
  2. Meetings with external colleagues should be coordinated manually with one internal person coordinating everyone’s G Suite Calendars

For efficiency, when Mattermost works with advisors and consultants who engage with 2 or more internal team members, we aim to schedule meetings in regular slots (or a collection of regular slots) 2-4 weeks apart.

Meeting Etiquette

Inspired by Corey Hulen’s blog article of 6 Annoying Things People Do During Video Conferencing.

  1. Avoid responding to messages in chat while on a meeting:
  • It can be distracting when someone tries to covertly respond to a message. First, other people on call may hear your keyboard and notice you’re looking somewhere else. Second, if they are in the same channel as you, they can see the message [User] is typing... in Mattermost.
  • Tip: If you feel the need to respond immediately and are easily distracted, set yourself to “Do Not Disturb” mode while in meetings.
  1. Avoid answering calls or checking text messages on your cell phone:
  • Tip: Put your phone on silent and place it out of arm’s reach, face down, so you don’t feel compelled to act.
  1. Display your video on a monitor with your camera:
  • If you have your video display on a second monitor, it may cause you to look away from the camera, not looking at the camera when talking. It almost feels like you’re talking to someone else in the room behind your computer monitor.
  • Tip: Either move your camera, or move your video window so they are somewhat inline. Also remember to look towards the camera.
  1. Mute audio in large video conferences when not speaking:
  • When not muted, others can hear random noises, like a fan running or a loud click-clack keyboard, which can be distracting.
  • Tip: Set your Zoom meetings to be on mute by default via Zoom settings.
  1. Avoid fidgeting uncontrollably or spinning in your office chair:
  • Tip If you’re in a group meeting and not doing much talking, feel free to stop your video.
  1. Avoid connecting with your computer but also dialing in via cell phone:
  • If you connect with your computer and dial in, there are two of you in the meeting and the voice/video are not synced when you talk. In large groups, there will be a random cell phone number that no one will know who they are.
  • Tip: If you’re having a bad internet connection and have to dial in, exit the Zoom meeting on your computer.
  1. When presenting, increase window zoom size or set Powerpoint slides to presenter mode:
  • Otherwise, the text on screen may be too hard for others to see.

Open Meetings

Developer Meeting

Open to the public - (Developers - 1-2 hours/week) Wednesdays 8:30 AM (San Francisco Time)

  • Goal: Discuss developer issues across Mattermost staff, key contributors and the contributor community.
  • Attendees: (required) Mattermost staff developers, (optional) key contributors, contributors and anyone who would like to join.

Procedure:

  1. (Team and Public): Post meeting agenda in Developers Meeting channel (open to the public). Please see instructions on how to queue an item.

  2. (Team and Public): At the time of the meeting:

Mattermost Staff Meetings

For confidentiality of customers, internal process meetings are limited to Mattermost staff only.

Customer Obsession All-Hands Meeting

This is our “All Hands” meeting focused on how we’re aligning the company to serve our customers. “Customer Obsession” is a key leadership principle and we emphasize its priority when we bring the company together.

Attendees:

  • All Mattermost Staff
  • Chair: Jason Blais
  • Co-Chairs: Co-founders
  • Vice Chair: Camille Harris

Objectives:

  • Reaffirm our obsession with making customers safer and more productive
  • Share how we’re aligning resources to make customers successful

Time:

  • Weekly meeting on Wednesdays from 8:00am to 8:25am Palo Alto time.

Procedure:

Before meeting:

  1. (Chair) Schedules items for the weekly agenda, and works 1-1 with presenters to prepare for them.

  2. (Vice Chair) Works with new hires and their managers to schedule week 2 welcomes. If new hire or manager is away, introduction is postponed to the following meeting.

    • 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).
    • New hire can opt-in to introduce themselves if they choose (default is not to require public speaking).
  3. (Team) Shares potential 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.

  4. (Vice Chair) Posts a reminder message in the meeting channel about the meeting 24 hours prior to meeting start.

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

During meeting:

  1. (Vice Chair) At 7:58am Palo Alto time on the day meeting is held, post a reminder in Customer Obsession Meeting channel.
@channel Customer Obsession meeting starting now https://zoom.us/j/2244480297

Meeting notes: https://docs.google.com/document/d/16F86k0I_ipjhHofm5pP6yA_dWTNvmA4ZBr_z53_087Q/edit
  1. (Team) Join the Zoom link in the header of the Customer Obsession Meeting channel, and open the Meeting Notes link in the header to see the agenda.
  2. (Vice Chair) Start Zoom recording at 8:00am Palo Alto time.
  1. (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.
  • Week 2 welcomes of new team members: New team members introduced on their second week by their manager, or optionally by the new team member themselves.
  • Main topics: Examples include: Series A marketing announce; FOSDEM event; key use cases and stories from customers to understand how they use Mattermost. Links to publicly shared documents or slides may be included in meeting notes.
  • Feedback: At end of meeting, concludes meeting with a reminder to share feedback via survey.

After meeting:

  1. (Vice Chair) Share meeting recording and link to feedback survey.
### All Hands Meeting: February 20, 2019

Meeting recording (and transcript) [here](https://zoom.us/recording/play/j7MHmiva3D7G4KqIcL6qV2Z46NMJZDpsdYo4B0GPDtmrRC0owvEJnC8Xpa9tAyxy?continueMode=true).

Share your thoughts on this week's meeting [here](https://goo.gl/forms/AgCNmu3JxTDmSQvp2) @here.
  1. (Vice Chair) Post recording to Cust Obs Prep channel, with timecode of co-founder’s introduction.
  2. (Chair & Vice Chair) Review recording and decide if the introduction is converted to a YouTube video and included in onboarding documentation. Sample recordings include discussions of leadership principles, mission and core values.
Frequently Asked Questions

Why don’t new people introduce themselves?

Not everyone is comfortable with speaking in front of 60+ people. Not everyone speaks clear English. We don’t want the first company-wide meeting to be anxious for new team members, hence by default managers intro them. New hires can opt-in to introducing themselves.

Product Training and Q&A Session

These are our product training sessions for the Sales and Customer Success teams, along with QA, focused on frequently asked product areas. They include a functional and technical training session targeted for specific audiences.

Attendees:

  • All Sales (including AEs and SAs), Customer Success (including CSMs and Support), and QA staff
  • Chair: Jason Blais
  • Co-Chairs: Product training session leads

Time:

  • Every 3 weeks on Wednesdays from 9:00am to 10:30am Palo Alto time.

Procedure:

Before meeting:

  1. (Chair) Schedules a kick-off call with co-chairs two weeks prior to the training session. Purpose is to review expectations and plans for the session, as well as answer any questions.
  2. (Co-Chairs) Prepares a pre-screening survey to assess team members’ knowledge of the product area. This is optional but recommended as it can help guide focus areas of the training session.
  3. (Co-Chairs) Prepares slides and other reference material for the session. Must be shared with Chair at least 48 hours ahead of the session.

Tip

  • When sharing code snippets, highlight the area of focus within the code snippet.
  • Focus on visuals, diagrams and live demonstrations instead of slides where possible.
  • Share at least one memorable customer story.
  • Ensure enough time is given for Q&A.
  • See the Google Drive on previous materials and training recordings for reference.
  1. (Co-Chairs) Two days prior to the training session, practices a dry run for length and structure of the session. This is optional but recommended.
  2. (Chair) Queues an item for that week’s Customer Obsession meeting to remind everyone of the product training session taking place. Include a mention of the topic, along with who is leading the session.
  3. (Chair & Co-Chairs) Signs into their Zoom account via OneLogin to access recording and screenshare capabilities during the meeting.

During meeting:

  1. (Chair) At 8:58am Palo Alto time on the day the meeting is held, posts a reminder of the session along with a Zoom link to join the call. See example.
  2. (Team) Joins the Zoom link in the header of the Product Training and Q&A channel.
  3. (Chair) Starts Zoom recording at 9:00am Palo Alto time.
  4. (Chair and Co-Chairs) Runs through the agenda, which typically comprises of one or more of the following items:
  • Introductions
  • (15 minutes) Business Use Case
    • Audience: Everyone, but primarily AEs, CSMs
    • What does it do, why do people use it, who uses it
    • Customer use case examples and success stories
    • Roadmap (status and committed timelines, if any)
    • Q&A
  • (30 minutes) Live Product Demo
    • Audience: Everyone
    • End user demo
    • Admin configuration demo
    • Known customer issues and workarounds
    • Q&A
  • (15 minutes) Technical Overview
    • Audience: Primarily CSMs, SAs, Support, QA
    • Technical flow for the feature, data structure, etc.
    • What to ask for when troubleshooting
    • Q&A
  • (30 minutes) Technical Deep Dive
    • Audience: Primarily SAs, Support, QA
    • Deeper technical review of how the feature works and how it was built
    • Working session on specific customer issues, retros on support tickets, etc.
    • Q&A
  • Feedback: At end of meeting, remind to share feedback via survey.
  1. (Chair) Encourages questions in Mattermost or Zoom chat throughout the session, but refrains audience from asking during presentation time. Asks back the questions during alloted Q&A time. By reserving questions during Q&A, the sessions stays on time and sets expectations for attendees on when to join the conversation with questions.

After meeting:

  1. (Chair) Shares link to feedback survey, tailored for each training session to measure its effectiveness. See example.
  2. (Chair) Uploads meeting recording and slides to Google Drive folder, then share in channel. See example.
  3. (Chair & Co-Chairs) Holds a retrospective meeting two days after the training session to review feedback and discuss what could have been improved.
  4. (Chair) Makes adjustments to meeting process based on feedback and discussion with co-chairs. Schedules kick-off call for the next training session.
  5. (Co-Chairs) Updates product documentation or other resources based on the training session.
  6. (Chair & Co-Chairs) Shares slides and meeting recording with Marketing team for potential GTM collateral.

Sprint Planning

Mattermost staff only - Each team is responsible for its own sprint planning process. Sprints are currently one week long, and start on Tuesdays. Note that teams also share demos and short updates with the whole product team in the “R&D Meeting” (see below).

  • Goal: Share demos, reflect on previous sprint, and lock on tickets for next sprint.
  • Attendees: Development team members (typically developers and product manager).

Triage Meeting

Mattermost staff-only - (Triage team - 1-3 hours/week) Tuesdays and Thursdays at 09:30 (San Francisco Time), or daily when a release is upcoming.

  • Goal: To provide consistent review, prioritization and ownership assignment of all tickets.
  • Attendees: One dev representative from each team (ABC, XYZ, ICU), one PM, QA team, Release Manager during release, and optionally leads and other Mattermost staff.

Note:

  • ONLY TRIAGE TEAM should set or change the Fix Version of a ticket.
  • When tickets are first created, they go to triage to be reviewed for clarity and priority and assigned a Fix Version, Mattermost Team and Sprint. Unclear tickets may be assigned to their creator for more information.
    • The Fix Version determines the sequence in which tickets are addressed and triage team is accountable for that sequence. It is the responsibility of the triage team to make sure tickets are clear before they’re assigned a Fix Version.
    • When assigning a ticket to a Mattermost Team, it gets assigned to a dev and put into current sprint if the ticket is time-sensitive for release. Otherwise the ticket is assigned to a team (e.g. ABC) and is later prioritized and assigned to the appropriate people within that team.
    • The Sprint determines the time frame in which a dev is responsible for fixing the ticket.
  • If you’re ever unsure about a ticket (if it’s not clear, or doesn’t seem appropriate) add a comment and add triage to the Fix Version field, which will trigger a review by the triage team in 1-2 working days.
    • Note: if the ticket is already assigned to a team and/or sprint, it will not appear in the triage query - easiest is to let the triage team know about the ticket so that it won’t be missed.
  • ONLY TRIAGE TEAM can close a ticket resolved as Won’t Fix or Won’t do.
    • These tickets resolved in such a way are reviewed by triage team.
    • Only resolve a ticket as Won’t Fix or Won’t Do if you’re highly confident it’s the correct decision, otherwise, add “triage” to Fix Version for review. In either case, include a comment with your reason.

Procedure:

  1. (Attendees): Join Zoom meeting link in calendar invitation at scheduled time.
  2. (Attendees): Review query for tickets needing triage and assign a development team, sprint and fix version.

Leads Meeting

Mattermost staff-only - (Leads - 1 hour/week) Wednesday (13:00 San Francisco Time)

  • Goal: Address leadership and process topics.
  • Attendees: (Required) Leads from R&D, Marketing, Sales, and Operations.

Note:

  • Decisions should go to Leads meetings when there is lack of clarity or ownership, or to discuss special case topics where process is not well defined.

    • When possible, decision-making should belong to the people closes to details.
    • Individual developers or PMs should make most decisions, and raise to developer or PM team if things are unclear, and go to Leads if lack of clarify persists.
  • To queue an item for Leads ask the dev or PM lead.

  • Leads is also used for cross-discipline Q&A.

    • Rather than randomize individual contributors, cross-discipline discussion (e.g. marketing to PM, community to dev, etc.) can happen in leads.

Procedure:

  1. (Leads): Queue items in Leads channel for discussion.
  2. (Leads): During meeting discuss agenda items in sequence.

R&D Meeting

Mattermost Inc-only - (Product Staff - 45 min/week) Thursdays at 09:00 (San Francisco Time).

Regular team meeting for product staff team at Mattermost Inc.

  • Goal: Increase team output by effectively reviewing priorities and finding blindspots.
  • Scope: Mattermost Inc-only meeting given confidential customer issues discussed.
  • Attendees: Mattermost Inc colleagues working on mattermost-server and mattermost-webapp.

The meeting includes presentations and demos, controlled agenda items (e.g. queued items) with an “open session” where staff can bring up anything they want. Staff should arrive at decisions during the meeting or schedule further discussion for the next meeting.

Procedure:

  1. (Vice Chair) the day before the meeting, post a reminder in R&D Meeting private channel (Mattermost Inc only)
#### @channel A reminder to prepare your items for R&D meeting [DATE]:
1. @[name], @[name] and @[name] - you're up for ice-breaker
2. Reminder for team member responsible for this week's team update to include it [in the notes](LINK)
3. If you'll be giving a demo, please queue it [in the meeting notes](link)
##### Everyone is encouraged to bring up items for discussion. If the discussion is `time-copped` during the meeting, please be sure to add a `next step` to the notes and post a link to where the conversation can be continued. ~platform channel is usually a good place to continue discussions.
  1. (Team) At time of meeting:
  2. (Vice-Chair) Post meeting notes template into R&D meeting notes.

Meeting Agenda:

  • Ice-breaker - see Meeting Elements > Ice-breaker below for examples
  • Roadmap check-in - Review of roadmap status in current and next release
  • Team updates - Each development team gives a short update on their current top priorities
  • Demos (optional) - Team members show highlights of what’s been completed this week. Relevant follow-ups noted
  • Blind spots, Inspiration, Knowledge Share - Colleagues share areas of concern and ask questions

Post Meeting:

  • If there are follow-up items, these are posted to the R&D Meeting private channel (Mattermost Inc only).
  • Vice Chair posts a link to the meeting recording for those who could not attend.

Meeting Elements

Here we summarize meeting elements that can be re-used for meetings across teams.

Ice-breaker

  • 2-3 minute exercises designed to learn more about colleagues at the start of a recurring meeting

  • Typically rotates in random order with names pulled from the R&D Meeting Ice-breaker List, three colleagues per meeting (2 R&D staff, 1 ‘other’ (e.g. Sales, Ops, etc)

  • Examples:

    • “Hobby talk” - sharing about an interesting hobby, past or present
    • “My home town” - sharing something interesting about where you grew up
    • “Two truths and a lie” - share two true facts about yourself and one lie, team guesses which is the lie
    • “Questions” - e.g. “What would constitute a “perfect” day for you?”

Blind spots, Inspiration, Knowledge Share

  • Exercise to find blindspots in team thinking at the end of a meeting

  • Colleagues share areas of concern and ask questions which invariably disclose blind-spots or are an opportunity to improve communication.

  • Examples of questions:

    • “What’s the status on X?” // often an important item that got forgotten
    • “Who owns X?” // reveals need for more clarity or communication
    • “Why do we do X?” // let’s us verify if a process is needed, and if we’re handling it the right way

Mindsets

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.

If you’re a strong teacher, their mastery should surpass yours. 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

When you rush to get something done quickly, it can actually increase the time and cost for the project.

Rushing means a higher chance of missing things that need to be done, and the cost of doing them later is significantly higher because you have to re-create your original setup to add on the work.

Emotion, Assumption, and Priority

Consider when two rational people disagree, the cause often comes from one of three areas:

  1. Emotion - There could be an emotion biasing the discussion. Just asking if this might be the case can clear the issue. It’s okay to have emotions. We are 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.

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.

This process is similar to Mini-boss, End-boss, except that the mini-boss is also the new owner of a process, and not only a reviewer. Shoulder checks should be requested by new owners to avoid “crashing”:

  • Making changes to systems that break existing processes and may lose data and hurt the productivity of others downstream without notice and without a replacement system in place (behavior known as “Dead Tarzan”).
  • Repeatedly investing in mis-prioritized projects due to a misunderstanding of requirements from project stakeholders and insufficient confirmation of intended outcomes.

Even when not crashing, as part of our Self Awareness value, top team members will constantly be seeking feedback and review from people around the company.

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

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:

  1. Significant mistakes in process, consistency or documentation suggesting lack of review or lack of understanding of the pre-existing system
  2. Ambiguous definitions that would make completion of a procedure difficult or unpredictable

The name brown M&M comes from a safety technique used by the American music band Van Halen, who had to set up large, complex concert stages in third tier cities, where few local workers had experience with the safety standards vital to construction. In the contract rider with each venue, Van Halen required a bowl of M&M candies with all brown M&Ms removed. Failure to provide the bowl was grounds for Van Halen’s stage crew to inspect all of the local vendor’s work for safety issues, because it meant the vendor had not paid attention to detail, and safety could be at risk.

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

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 - do not worry about “leaving a scar” in 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 re-design. 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 is fine to leave scars and it is 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.

Terminology

Designing world-class software means bringing people together across disciplines and cultures. We want to create a limited amount of shared terminology to help us work better together, while being careful not to make it difficult for newcomers to follow our conversation.

Perhaps in future we’ll have a bot that helps teach newcomers about the terminology in-context. Until then we have this guide.

Purpose

We use Mattermost terminology to achieve specific benefits:

1) Increase precision through unambiguous definitions of useful terms

For example, “0/5” and “5/5” help convey the level of conviction behind an opinion. Also, a precise classification of tickets as “Bug” or “Improvement” is critical since it affects scheduling and decision making, and so forth.

2) Increase the speed of communication via a small number of frequently used acronyms

LHS and RHS are examples of a very limited number of acronyms to use to speed discussions, specifications, and ticket writing.

3) Reduce repeated mistakes by naming very specific undesirable behaviors

Naming specific repeated mistake helps us find patterns, avoid repeated mistakes in future, and helps newcomers avoid making similar mistakes as they learn our organization’s terminology.

List of 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.

Bug

An obvious error in Mattermost software. Changes required to accommodate unsupported 3rd party software (such as browsers or operating systems) are not considered bugs, they are considered improvements.

Dead Tarzan

Discarding an imperfect solution without a clearly thought out and working alternative. Based on idea of Tarzan of the Jungle letting go of a vine without having a new vine to swing to.

Decking

A term for shipping something that is 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

A specific type of mana for developers similar to “points” or “jelly beans” in an Agile/Scrum methodology. On average, full time Mattermost developers each complete tickets adding up to approximately 28 mana per week. A “small” item is 2 mana, a “medium” is 4, a “large” is 8 and any project bigger needs to be broken down into smaller tickets.

ESR

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

Expert Mode (and Crimson Force Field)

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.

HW - Help Wanted

Help Wanted tickets, which are vetted changes to the source code open for community contributions.

Improvement

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

LHS

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

Mana

An estimate of total energy, attention and effort required for a task.

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 feature added has an initial and on-going mana cost, which is taken into account in feature decisions.

RHS

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

Spinmint

Old test servers that could be spun up on pull requests to test changes. Name is a throwback to test servers from SpinPunch.

SpinWick

New test servers that use the cloud infrastructure and can be spun up on pull requests to test changes. Name is a throwback to “Spinmint” mixed with “John Wick”.

Windows Vista approach

An attempt to add functionality through a massive, complex one-time re-write hoping to improve the architecture, but which likely ends in repeated delays, wasted effort, buggy code and limited architectural improvement (compared to re-writing the architecture in phases). This tempting, high risk approach is named after Microsoft’s “Windows Vista” operating system, one of its most famous examples.

Training

At Mattermost, “Learn, Master, Teach” cycles are core to our culture. You should be constantly growing and cross-training into new skills and responsibilities, developing expertise, and then training your replacement as you prepare to take on new challenges.

Cross-training creates a culture of constant growth, protects against single-points of failure, and challenges each of us to rise to our fullest potential.

Roles

The “Learn, Master, Teach” cycle happens in the context of roles. Roles are sets of responsibility needed to achieve objectives. Roles aren’t necessarily job titles, for small projects, a developer might take on a product manager role, or vice versa. Each team member has a “primary role” and training should move people to mastery and teaching in that role, before moving to the next role.

Developer

Developers are responsible for architecting and delivering software improvements, and for technical leadership among the Mattermost community.

  • Architecture
    • Developers are responsible for researching, analyzing, designing and reviewing technical solutions to achieve functional requirements. Solutions should thoroughly consider trade-offs and be evaluated based on the effectiveness of the end implementation.
  • Delivery
    • Based on technical designs, developers estimate, implement, test, maintain, review, debug and release software improvements in collaboration with teammates. This includes working closely with product managers to validate requirements and the output of designs and making appropriate adjustments. The success of implementation is judged on the end results achieved by the changes.
  • Technical Community Leadership
    • As leading experts on Mattermost technology, developers support and engage constantly with the broader Mattermost community to accelerate adoption and to discover new ways to improve Mattermost software and processes. This includes investigating and supporting issues from users and customers, reviewing and providing feedback on projects from contributors, and understanding priorities, trends and patterns across the community.

Product Managers

Product managers are responsible for aligning teams to strategic priorities, leading and managing the product development process, and working effectively with marketing to bring the full benefits of Mattermost solutions to users and customers.

  • Strategy
    • Every project and every team needs to align to strategic priorities and focus on intended outcomes developed through a deep understanding of the market, user, customers and competing products and services. Amid a flood of compelling suggestions, opinions, and data, product managers must find what’s vital, and rally teams around a shared vision.
  • Product development
    • Product managers lead both the functional design process (user, customer and competitor research, analysis, ideation, prioritization, functional and user experience design, functional specification, user and customer validation), and the software development process (ticketing, prioritization, roadmap design, scheduling, sprint planning, triage, functional verification, implementation validation with users and customers, documentation, and release logistics).
    • It’s the product manager’s responsibility to see features shipped predictably and at high quality through planning, attention to detail and thoughtful persuasion.
  • Marketing connection
    • Delivering benefits to users and customers based on product features is a core responsibility of product managers, working in conjunction with marketing to shape messaging and positioning and delivering collateral, events, and user and customer discussions to support sales.

Resources

The following is a list of recommended resources for developing skills “the Mattermost way” in different areas. For the ones that require purchase, message your manager to request an order, whether as physical books, digital books, audiobooks or other formats.

Books

  1. Code Complete, Steve McConnell - Best practices and guidelines for writing high quality code.
  2. Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (aka “Group of Four”) - Fundamental reading on design patterns. Other design pattern books work too, this is one of the most popular.

System Security

Papers and Course Materials

  1. Framework for Improving Critical Infrastructure Cybersecurity. National Institute of Standards and Technology - Standards for internal Mattermost security processes and safeguards.
  2. Computer Security in the Real World. Butler Lampson - Fundamental challenges with system security.
  3. Course notes from CS513: System Security (Cornell University). Fred B. Schneider - Well written introduction to system security from one of the leaders in the field.

Additional Training Resources

Recommended training materials are recommended by role at three different levels of priority:

  1. P1 - Required - Complete within 30 days of starting in role.
  2. P2 - Priority - Complete within 30-90 days of starting.
  3. P3 - Supplementry - Complete within 180 days.

The following chart outlines training materials by category, with notes on which materials are relevant to which disciplines by P1, P2, P3 priority:

 

The following table summarizes abbreviations used in the above table:

 

Consulting Advisers

To provide guidance, coaching and development for senior and functional leaders, we bring in experts to advise in key areas.

  • As an example, Jono Bacon–a leading author, speaker and consultant on open source community advocacy–meets with our CEO and community team regularly to refine our processes and understanding. There’s a range of similiarly adept company advisers that help advance our thinking and capabilities in critical ways.

Meetings typically take place over phone or video calls. We bring on advisers with standard consulting agreements on either a time and materials basis or a recurring fee.

We use a range of advisers from senior board-level contributors to operational and subject-matter experts.

Mattermost Avatar

When becoming a core committer to the Mattermost project we create a “Mattermost Avatar” for you as a fun way to recognize your new level of contribution.

Mattermost avatars are caricatures of core committers in the costume of a popular culture character (e.g. Spiderman, Wonder Woman, Luke Skywalker, etc.) created for personal use, and which may be potentially used in team rosters, demonstration sites, “group photos” where avatar images from the team are collected in one image of all the characters together, and other public uses.

To have a Mattermost avatar created, you’ll be invited to create a Mattermost avatar via email:

  1. Please use the email subject “[YOUR_FULL_NAME] as [CHARACTER_NAME]”, for example “Corey Hulen as Han Solo”.
  2. Attach a clear image at least 600 pixels high and 600 pixels wide showing your character’s full body in a standing pose.
  3. Send a clear photo of your face at least 600 pixels high and 600 pixels wide facing the same direction as your character image.

Notes:

  1. Character should be human-sized (no giant characters).
  2. Character’s appearance should be family-friendly. For example, no gory or provocative costumes.

You should receive your digital Mattermost avatars by email in 6-8 weeks.

In special cases, a Mattermost avatar may be created for someone from the Mattermost community who has made an extraordinary contribution to the open source project.

Example of finished Mattermost Avatar:

https://cloud.githubusercontent.com/assets/177788/25364270/0425b738-2916-11e7-9a23-5ced2d9dfc8f.png

Mattermost Teams and Naming Conventions

Staff must use their full name for their username, as in first.last, on the community server. Staff are also encouraged to link to their Github account using the command /github connect so that your Github handle will appear on your profile popover card. All Mattermost staff should be issued a OneLogin account with a username of first.last. If issued a OneLogin account, you should switch your sign-in method from email/password to OneLogin via the Account Settings > Security > Sign-in Method page. Once this is done, your username will be set from SAML.

Contributors team

This is a team open for any and all to join. It is the main place where staff, contributors, users, customers and partners interact. Our goal is to do as much work as possible in the open. If you find yourself creating a private channel on this team you should pause and ask yourself if it really needs to be private. Mattermost staff will be sync’ed to the appropriate channels based on their LDAP group sync settings.

Staff team

This is restricted to people with an @mattermost.com email address. It is meant for Mattermost employees and staff and it is where we discuss internal company matters. Since this team only includes people with mattermost.com email address, you should prefer creating public channels. Also, if you find yourself creating a channel here, you should ask yourself if it would be better served to have it in the Contributors team. Mattermost staff will be sync’ed to the appropriate channels based on their LDAP group sync settings.

Partners team

This is an invite only team meant for Mattermost staff and partners. This is a team for staff to interact with partners and for partners to interact with other partners. You should prefer public channels when you want partner-to-partner interactions and private channels when you want staff-to-partner interactions. Remember that any partner added to the team will be able to join any public channel.