Roivant is a globally distributed company that supports employees in many time zones around the world. We strive to hire great people not based on where they live, but based on what they bring to Roivant, so it’s important for us to practice clear communication in ways that help us stay connected and work more efficiently. To accomplish this, we support and encourage asynchronous work as a starting point and stay as open and transparent as we can by communicating openly with the entire company. We also place an emphasis on ensuring that conclusions of offline conversations are written down. When we go back and forth three times, we jump on a synchronous video call. We communicate respectfully and professionally at all times.

Effective & Responsible Communication Guidelines

1. Assume Positive Intent. Always begin with a position of positivity and grace.

2. Kindness Matters. You are looking at a screen, but you are really talking to a person. If you wouldn’t say it to a person’s face, don’t send it to them in a text message.

3. Express Your Thoughts. We live in different locations and often have very different perspectives. We want to know your thoughts, opinions, and feelings on things.

4. Own It. If you say it or type it, own it. If it hurts the company or an individual, even unintentionally, we encourage you to look at things from other points of view and apologize easily.

5. Be a Role Model of our Values.

6. Feedback is Essential. It is difficult to know what is appropriate in every one of our team member’s countries. We encourage team members to give feedback and receive feedback in a considerate way.

7. Don’t Underestimate a 1:1. Asynchronous communication (e.g., via text) is helpful and necessary. In some cases (e.g., to clarify misunderstandings) it can be much more effective to jump on a Zoom video call.

8. Always Adhere to our Anti-Harassment Policy and Code of Conduct as described in the Employee Handookb. Everyone should be comfortable in their work environment. Embracing asynchronous communication and learning to use it effectively requires a mental shift. This can feel unusual or even uncomfortable for those who come from a colocated environment, where in-person meetings and communiques are the norm. Learn more about Asynchronous Work.

Everyone is a Moderator

If you see something that concerns you in Slack, Jira stories, helpdesk tickets, videos, emails or any other forum, we encourage you to respectfully say something directly to the individual in a 1:1 format. If you are not comfortable reaching out to the individual directly, please reach out to your direct manager or HR Business Partner to discuss.

Internal Communication

Internal communication is any work-related communication at a company. Internal Communication includes conversations between team members, wider team discussions, or internal announcements. In Roivant IT, internal communication is further defined as any communication that is by and between Roivant IT staff, for the use of the IT org. Everyone can contribute to the effectiveness of Internal Communications to support aspects of our developing culture, such as intentional transparency and engaging people in open dialogue. Since we believe that all team members must be Managers of One, most communication is handled by the relevant group, but we know that some communications are more sensitive and contentious than others, especially when communicating with Roivant as a whole, such as announcements on subjects that affect the whole enterprise. In those cases, the DRIs may want to engage the IT Communications function.

Asynchronous communication

In a globally distributed organization, where team members may live in varying locales and time zones, mastering asynchronous workflows is vital to avoiding dysfunction and enjoying outsized efficiencies and lifestyle flexibility. Asynchronous communication is the art of communicating and moving projects forward without the need for additional stakeholders to be available at the same time your communique is sent. To learn more on when to use asynchronous and synchronous communication, examples of async workflows in practice at Roivant, core async behaviors, visit #our guide to embracing asynchronous communication.

Top Tips and Best Practices

1. All written communication happens in English, even when sent one on one, because sometimes you need to forward an email or chat.

2. Use asynchronous communication when possible: merge requests, Miro boards, Jira stories or service tickets. Announcements happen on the appropriate Slack channels.

3. If you choose to email instead of chat it is OK to send an internal email that contains only a short message, similar as you would use in chat.

4. You are not expected to be available all the time. There is no expectation to respond to messages outside of your planned working hours.

5. Sometimes synchronous communication is the better option, but do not default to it. For example, a video call can clear things up quickly when you are blocked. See the guidelines on video chats for more detail.

6. It is very OK to ask as many questions as you have. Please ask them so many people can answer them and many people see the answer. Use issues or public chat channels instead of direct messages or one-on-one emails. If you have researched in the handbook and could not find the answer or need clarity, include the handbook link you were reviewing and state “while looking in the handbook I could not find x,y,z”.

7. If someone sends you a handbook or wiki link, presume they are proud that we have the answer documented, they don’t mean that you should have found that yourself or that this is the complete answer, feel free to ask for clarification.

8. If the answer to an internal question isn’t documented, please immediately make a merge request to add it to the handbook in a place you have looked for it. It is great for the person who answered the question to see you leading by example to ensure that question only needs to be answered once. A merge request is the best way to say thanks for the help.

9. If the answer to an external (company-facing) question isn’t documented, immediately add a KB item, also in the place where you would have looked for the answer.

10. If you mention something (a merge request, issue, story, webpage, comment, etc.) please include a link to it.

11. All company data should be shareable by default. Don’t use a local text file, but rather user a shareable tool such as Miro, O365 docs, Jira stories and so on.

12. When someone asks something, give back a estimation of when you can have it done, or that you did it. Answers like: ‘will do’, ‘OK’, ‘it is on my to-do list’ are not helpful. If it’s small it’s better to spend 2 minutes and do the tasks so the other person can mentally forget about it. If it’s large you need to figure out when you’ll do it, by returning that information the other person might decide to solve it in another way if it takes too long.

13. Many of our systems support @-ing someone. It is OK to bring an issue to someone’s attention with a CC (cc @user), but CCs alone are not enough if a specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.

14. Avoid creating private DM groups for internal discussions:

    • It’s disturbing (all users in the group get notified for each message).
    • It’s not searchable.
    • It’s not shareable: there is no way to add people in the group (and this often leads to multiple groups creation).
    • They don’t have a subject, so everyone has to remember the topic of each private group based on the participants, or open the group again to read the content.

15. Use low-context communications by being explicit in your communications. We are a distributed organization, with staff in several time zones. Provide as much context as possible to avoid confusion. Relatedly, we use ubiquitous language for communication efficiency.

16. When discussing concepts, be careful not to lean too much into hypotheticals. There is a tipping point in which it decreases value and no longer becomes constructive at helping everyone come into a unified decision.

Company-wide Announcements

All Company-wide announcements should be done in collaboration with the IT Comms team.

1. Consider the subject and the audience. Questions you might want to ask yourself: Is this relevant to all team members globally? Is this something important, urgent, and high priority? Is there a better place for this communication, such as a more informal Slack channel?

2. Keep it simple, brief, and summarize what is important. Cover the 5 W’s. What, Why, Who, When, Where (you can also add How if required as a call to action). The majority of the information should still be in the Handbook which you include links to.

3. Common company-wide announcements include (but are not limited to): organization changes, policy iterations, requests to participate in a company survey, significant UX changes, process improvement, and security/safety announcements.

Posting in #general

Our companywide announcements channel is #general. It is an announcement only channel, meaning that communications need to be approved before they can be posted. To minimize noise, announcements made in #general should not be duplicated in #replace-with-a-roivant-channel. Be mindful of the attention economy. In order to post or have a message posted in #general, please reach out to the IT communications team or your function’s executive who can approve the message and post it.

Multimodal communication

Employ multimodal communication to broadcast important decisions. To reach our distributed organization, announce important decisions in the company announcements Slack channel, email the appropriate team email lists, Slack the appropriate channels, and target 1:1s or other important meetings on the same day, with the same information. When doing this, create and link to a single source of truth: ideally the handbook, otherwise a Jira epic, story, or O365 Doc. The email or Slack message should not be the source of truth.

Not Public

We make things public by default because transparency is one of our values. However, it is common for IT to come into possession of sensitive information and some and can’t be made public and is either internal to IT or has limited access even within the company. If something isn’t listed in the sections below we should make it available throughout Roivant.

Internal

Some things are internal, available internally to IT but not outside of IT. The following items are internal to IT:

1. Security vulnerabilities are not public since they could allow attackers to compromise Roivant systems. Issues that discuss how to improve upon the security posture of a system that is working as intended can be made public, and are often labeled as feature proposals. Security and abuse implementations that detect malicious activities cannot be made public because doing so would undermine our operations.
2. Content that would violate confidentiality for a Roivant team member, associate, or user.
3. Legal discussions are not public due to the purpose of Attorney-Client Privilege.
4. Discussions that involve decisions related to country of residence are not public as countries are a core part of people’s identity and any communication should have complete context.
5. Any information that could compromise the physical safety of one or more colleagues, because creating a safe, inclusive environment for team members is important to how we work. Information that might compromise the physical safety of a team member includes doxxing or threats made against a team member.
6. Information related to a press embargo, or related to an upcoming publication where the response will be managed by our external communications team.
7. Any other information deemed sensitive or private by Roivant Legal or Management.

Limited Access

The items below are not shared with all team members. Limited access is a more severe restriction than internal.

1. Content that would violate confidentiality for a Roivant team-member, associate, or user.

2. Plans for reorganizations or terminations. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team members informed whenever possible.

3. Legal discussions are restricted to the purpose of Attorney-Client Privilege.

4. Performance improvement plans, disciplinary actions, as well as individual feedback, are confidential as they contain private negative feedback and negative feedback is 1-1 between team members and managers

5. Roivant’s Risk Register, maintained by Information Security and the Corporate Risk team. 1. Acquisition offers for us are not public since informing people of an acquisition that might not happen can be very disruptive

6. Acquisition offers we give are not public since the organization being acquired frequently prefers to have them stay private.

7. Any other information regarding mergers, acquisitions or divestments that is not explicitly declared “company-public”.

Effective Communication Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. In a distributed organization, effective communication is key to exchanging knowledge, ideas, and information. Effective communication in Roivant IT is:

• Using asynchronous communication as the starting point and staying as open and transparent as we can by communicating via text through Miro boards, Jira stories, O365 Docs, merge requests, and Slack channels (over DMs).

If you would like to improve your skills or expand your knowledge on topics relating to Communication in Roivant IT, check out our resources:

1. Communicating effectively and responsibly through text

2. Embracing asynchronous communication

Skills and behavior of applying effective communication as a Team Member:

1. Effectively practices communication via text.

2. Uses asynchronous communication when possible: stories, documents, tickets.

3. Directs all communication to the appropriate channels (Slack, knowledgebase, email).

4. Recognizes when synchronous communication is the more appropriate option.

5. Directs all decisions to the Handbook as a single source of truth.

6. Employs multimodal communication to broadcast important decisions.

7. Practices low context communication and provides as much background as possible when communicating via text to avoid confusion.

Skills and behavior of applying effective communication as a People Manager:

1. Implements working asynchronously across teams, departments or across the company. Drives communication where possible to asynchronous channels.

2. Holds team members accountable for effectively communicating via text.

3. Fosters an environment across teams, departments or divisions where asynchronous communication is the starting point.

4. Drives and funnels conversations to the right channels across teams, divisions and the company.

Numbering is for Reference, not as a Signal

When taking notes in an agenda, in the handbook, or in O365 docs, keep items numbered so we can refer to Item 3 or 4a. The number is not a signal of the importance or rank of the subject unless explicitly stated to be such. It is just for ease of reference.

Cross-Link

Linking should not be in one direction. We should go beyond deep-linking to create a richer web of links that can surface content and ensure people consider all pages when making updates. When linking one page to another, try to link back as well. Instead of only linking from Page A to Page B, both link Page A to Page B and link Page B back to Page A.

Presentations

1. All presentations are made in Powerpoint using our templates.

2. Please allow anyone at Roivant to edit the presentation (preferred) or at least comment on the presentation.

3. The title of every slide should be the message you want the audience to take away, not the subject matter. So use “Our revenue more than doubled” instead of “Revenue growth”.

4. If there are introductions being performed please make sure that nobody is presenting. We remember people better and have more empathy when we clearly see peoples faces and expressions.

5. At the end of the presentation when you go to Q&A stop presenting in Zoom. This way the other people can see the person who is speaking much better.

6. When your presentation includes graphs or other data, make sure your graphs have clear titles and dimensions. Make sure your data has significant figures and labels. For example, use ‘January: 1.95M projects’ instead of ‘January: 1.95M’. Keep in mind that your audience may not have the full context, especially if they are reading the presentation asynchronously.

Say Thanks

As we continue to build on inclusion, recognition is a key and transformative tactic. Thanking team members provides an opportunity for them to be recognized for their contributions, influences engagement behavior, and acknowledges to team members their work is seen. By saying thanks, you are contributing to and supporting the value of DIB.

1. Consider channels where recognition can be acknowledged: team meetings, issues, company calls, 1-1 meetings, etc.

2. If someone is a team member just @-mention them, if multiple people were working on something try @-mentioning each person.

3. When announcing a completed project, list the key contributors.

4. Please be as timely as possible with your recognition.

5. If possible please include a link with your thanks that points to the subject matter that you are giving thanks for, for example a link to a merge request.

6. Please do not mention working outside of normal working hours, we want to minimize the pressure to do so.

7. Please do not celebrate graphs or analytics that include working for uninterrupted weeklong cycles, as this does not foster healthy work/life harmony for all team members. While it’s not impossible that Roivant IT team members may have to work long or odd hours occasionally, e.g. during incident response, we discourage celebrating the absence of time away from work.

8. Don’t thank the CEO or other executives for something that the company paid for, thank Roivant instead.

9. Understand that everyone doesn’t need or want recognition. Once this is advised, please respect when they don’t.

Communicate Directly

When working on a problem or issue, communicate directly with the people you need support from rather than working through reporting lines. Direct communication with the people you need to collaborate with is more efficient than working through your manager, their manager, or another intermediary. Escalate to management if you are not getting the support you need. Remember that everyone is a manager of one and they might have to complete their own assignments and inform the reporting lines.

Effective Listening

It is estimated that listeners will filter out or change the intended meaning of what is heard in 70% of all communications. Source.

Myths about Listening

1. Everybody knows how to listen.

2. Sending messages is more important than receiving them.

3. Listening is easy and passive.

4. Hearing and listening are the same thing.

5. An effective speaker commands audience attention.

6. Communication is the sender’s responsibility.

7. Listening is done with our ears.

8. Listening skills are practiced and not learned.

9. Listening ability comes from maturity.

Tips for Effective Listening

1. Concentrate.

2. Give unequivocal attention to the speaker.

3. Don’t anticipate what the speaker means.

4. Test the message not the messenger.

5. Respect cultural difference and boundaries.

6. Develop the fine art of empathy.

7. Try not to interrupt.

8. Focus on feelings and not grammar or vocabulary.

9. Silence is the golden rule.

Being Assertive

There is a delicate balance between being confident enough to be assertive of personal rights and boundaries while respectful of others.

1. Know the distinction between being assertive and being aggressive or arrogant.

2. Establish clear boundaries when dealing with others.

3. Politely but directly let people know your position.

4. Know what you want.

5. Avoid being timid.

6. Be willing to clearly say either yes or no and stand by your answer.

7. Avoid arrogance.

8. When opinions are in question give yourself permission to disclose yours.

Not sure where to go?

If there is something that you want to discuss, but you do not feel that it is a reasonable option to discuss with either your manager, you can always reach out to the CIO.

Random

The #random Slack channel is your go-to place to share random ideas, pictures, articles, and more. It’s a great channel to check out when you need a mental break.

Indicating Availability

Indicate your availability by updating your own calendar using Outlook’s “out of office” (web) (desktop) feature and include the dates you plan to be away in your automated response.

1. Put your planned away time including holidays, vacation, travel time, and other leave in the IT+REF-ALL calendar.

2. Set your working hours in your Outlook Calendar settings.

User Communication Guidelines

1. Keep conversations positive, friendly, real, and productive while adding value.

2. If you make a mistake, admit it. Be upfront and be quick with your correction. If you’re posting to a blog, you may choose to modify an earlier post. Just make it clear that you have done so.

3. There can be a fine line between healthy debate and incendiary reaction. Try to frame what you write to invite differing points of view without inflaming others. You don’t need to respond to every criticism or barb. Be careful and considerate.

4. Assume positive intent and explicitly state the strongest plausible interpretation of what someone says before you respond, not a weaker one that’s easier to criticize. Rapoport’s Rules also implores you to list points of agreement and mention anything you learned.

5. Answer questions, thank people even if it’s just a few words. Make it a two way conversation.

6. Appreciate suggestions and feedback.

7. Don’t make promises that you can’t keep.

8. Guide users who ask for help or give a suggestion and share links.

9. When facing negative comments, respond patiently and treat every user as an individual, people with the strongest opinions can turn into the strongest supporters.

10. Adhere to the [Code of Conduct](https://roivant.box.com/s/4tfooixifveuef6zf6hfbxplw1189vub) in all communication. Similarly, expect users to adhere to the same code when communicating with the Roivant team and the rest of the Roivant community. No one should accept being mistreated.

Writing Style Guidelines

1. In Roivant IT, we use American English as the standard written language.

2. Avoid rich text, it makes it hard to copy/paste. Use Markdown to format text that is stored in a Git repository. In O365 Docs use “Normal text” using the style/heading/formatting dropdown and paste without formatting.

3. Don’t use ALL CAPS because it feels like shouting. However, there is the #yelling Slack channel for your good-natured shouting needs.

4. We use Unix style (lf) line endings, not Windows style (crlf), please ensure *.md text eol=lf is set in the repository’s .gitattributes and run git config --global core.autocrlf input on your client.

5. Always write a paragraph on a single line. Use soft breaks (“word wrap”) for readability. Don’t put in a hard return at a certain character limit (e.g., 80 characters) and don’t set your IDE to automatically insert hard breaks. Merge requests for the blog and handbook are very difficult to edit when hard breaks are inserted.

6. Do not create links like “here” or “click here”. All links should have relevant anchor text that describes what they link to, such as: “Vendor onboarding instructions”. Using meaningful links is important to both search engine crawlers (SEO) and accessibility for people with learning differences and/or physical disabilities. This guidance should be followed in all places links are provided, whether in the handbook, website, O365 Docs, or any other content. Avoid writing O365 docs content which states - Zoom Link [Link]. Rather, paste the full link directly following the word Zoom. This makes the link more prominent and makes it easier to follow while viewing the document.

7. Always use ISO dates in all writing and legal documents since other formats lead to online confusion. Use yyyy-mm-dd, for example 2015-04-13, and never 04-13-2015, 13-04-2015, 2015/04/13, 20150413, 2015.04.13, nor April 13, 2015. Even if you use an unambiguous alternative format it is still harder to search for a date, sort on a date, and for other team members to know we use the ISO standard. For months use yyyy-mm, so 2018-01 for January. Refer to a year with CY18 (never with 2018) and a quarter with CY18-Q1 to prevent confusion with fiscal years and quarters. If the year is obvious from the context it is OK to use Dec 4, but not 12/4, since the ordering isn’t obvious when using two numbers but when naming the month it is clear that the number of the day of the month. 8. Roivant operates on a fiscal year aligned with the calendar year. When referring to a fiscal year or quarter, please use the following abbreviations:

   1. “FY20” is the preferred format and means: Fiscal Year 2020, the period running from April 1, 2020 through March 31, 2021

   2. “Q1” = the first quarter of the current Fiscal Year, so on April 1, 2021, “Q1” is the period from April 1, 2021 through June 30, 2021. Note that Epics in Jira follow Calendar Years and Quarters. 3. When referring to a quarter in a future or past year, combine the two above: “FY21-Q1”

   3. When financial data is presented include a note to indicate fiscal year (e.g. “Fiscal Year ending January, 31 ‘yy”)

8. Remember that not everyone is working in the same timezone; what may be morning for you is evening for someone else. Try to say 3 hours ago or 4 hours from now, or use a timestamp, including a timezone reference. 10. We use UTC as the timezone for engineering (for example production postmortems) and all cross-functional activities related to the monthly release. We use Eastern Time (ET) for all other uses since we are a New York-based company. Please refer to time as “9:00 Pacific” or 9:00 PT. It isn’t often necessary to specify whether a timezone is currently observing Daylight Saving Time, and such references are often incorrect, so prefer “PT” to “PDT” or “PST” unless you have a specific need to differentiate between PDT and PST.

9. When specifying measurements, please include both Metric and Imperial equivalents.

10. Although we’re a US based company we’re also growing to be an internationally diverse one. Please do not refer to team members outside the US as international, instead use non-US. Please also avoid the use of offshore/overseas to refer to non-American continents.

11. If you have multiple points in a comment or email, please number them. Numbered lists are easier to reference during a discussion over bulleted lists.

12. When you reference an issue, merge request, comment, commit, page, doc, etc. and you have the URL available please paste that in.

13. In making URLs, always prefer hyphens to underscores, and always use lowercase. 16. Please always refer to Roivant Sciences Inc. people as Roivant colleagues, not employees. 17. Use inclusive and gender-neutral language in all writing.

14. Do not use a hyphen when writing the term “open source” except where doing so eliminates ambiguity or clumsiness.

15. Monetary amounts shouldn’t have one digit, so prefer $19.90 to $19.9. 20. If an email needs a response, write the answer at the top of it.

16. Use the future version of words - like how we don’t write internet with a capital letter anymore. We write frontend and webhook without a hyphen or space.

17. Try to use the active voice whenever possible.

18. If you use headers, properly format them (## in Markdown, “Heading 2” in O365 Docs); start at the second header level because header level 1 is for titles. Do not end headers with a colon. Avoid emojis in headers as these cause links to have strange characters.

19. Always use a serial comma (a.k.a. an “Oxford comma”) before the coordinating conjunction in a list of three, four, or more items.

20. Always use a single space between sentences rather than two. 26. Do not use acronyms when you can avoid them. Acronyms have the effect of excluding people from the conversation if they are not familiar with a particular term. Example: instead of MR, write merge request (MR).

• If acronyms are used, expand them at least once in the conversation or document and define them in the document using Kramdown abbreviation syntax. Alternatively, link to the definition.

Visuals

Many times an explanation can be aided by a visual. Whenever presenting a diagram, we should still allow everyone to contribute. Where possible, take advantage of the handbook’s support for Mermaid. If you are new to using Mermaid or need help troubleshooting errors in your Mermaid code, the Mermaid Live Editor can be a helpful tool. Where taking advantage of Mermaid isn’t possible, embed or link to an editable Miro board or Lucidchart diagram.

Situation-Complication-Implication-Position-Action-Benefit (SCI-PAB®)

Mandel Communications refers to SCI-PAB® as the “surefire, six-step method for starting any conversation or presentation.” When you only have a few minutes to present your case or grab your listener’s attention, this six-step process can help you communicate better and faster.

1. Situation - Expresses the current state for discussion.

2. Complication - Summarizes the critical issues, challenges, or opportunities.

3. Implication - Provides insight into the consequences that will be a result of if the Complications are not addressed.

4. Position - Notes the presenter’s opinion on the necessary changes which should be made.

5. Action - Defines the expectations of the target audience/listeners.

6. Benefit - Clearly concludes how the Position and Action sections will address the Complications. This method can be used in presentations, emails, and everyday conversations. Example - The Management team asking for time to resolve a problem

For example:

1. S - The failure rate last year for product X1 was an acceptable 1.5%.

2. C - Because of supply shortages in the current fiscal year we are forced to change the material of a key component.

3. I - Unfortunately, that resulted in the failure rate doubling this year.

4. P - It is critical we address this problem immediately.

5. A - Please approve the team 5 days to investigate the specific causes of the increase and establish the necessary next steps.

6. B - By doing this we will reduce the failure rate to an acceptable level and develop guidelines for preventing such problems in the future. Some examples can be found at SCI-PAB - Six Steps To Reach Your Audience.

Company phone number

If you need to provide the details of Roivant’s contact information you can take the address or our HQ from the main page for reference. If a phone number is required, leave this field empty by default. If that is not possible, then use the general number , but be aware that this number simply guides to a voice message that refers the caller back to contacting us via email.

Ubiquitous language

In Roivant IT, we use ubiquitous language to increase communication efficiency. This is defined in Domain-driven design as: “A language structured around the domain model and used by all team members to connect all the activities of the team with the software.”

What this means in simple terms is: when we name things, the names should be clear and unambiguous and we should use the same name for a concept consistently and everywhere. FIXME: needs a better explanation

MECEFU terms

MECEFU is an acronym for Mutually Exclusive Collectively Exhaustive Few words Ubiquitous-language. You pronounce it: MessiFu. Think of the great soccer player Lionel Messi and his kung fu or soccer fu skills. We want to use MECEFU terms to describe a domain to ensure efficient communication. MECEFU terms have 4 characteristics that help with efficiency:

1. Mutually Exclusive: nothing is referenced by more than one term

2. Collectively Exhaustive: everything is covered by one of the terms

3. Few words: the longer terms are the more likely it is people will not use all of them and cause confusion, therfore consider two words as the upper limit for a single term. Avoid acronyms because they are hard to remember (we’re open to a few words to replace MECEFU as an acronym :)

4. Ubiquitous language: defined above

Simple Language

Simple Language is meant to encourage everyone in Roivant IT to simplify the language we use. We should always use the most clear, straightforward, and meaningful words possible in every conversation. Avoid using “fluff” words, jargon, or “corporate-speak” phrases that don’t add value. When you don’t use Simple Language, you:

1. Confuse people and create a barrier for participants of your conversation.

2. Cause others to not speak up in a meeting because they don’t understand what you’re saying.

3. Are not inclusive of those whose first language is not English.

4. Do not add value with your words. When you do use Simple Language, you:

5. Get work done more efficiently.

6. Build credibility with your audience (your team, coworker, customer, etc.).

7. Keep people’s attention while you’re speaking.

8. Come across more confident and knowledgeable.

Here’s an example:

Original sentence

We’re now launching an optimization of our approach leveraging key learnings from the project’s postmortem.

A Simple Language sentence

We’re creating a new plan based on what we learned from this project. Simple Language is important both when we’re speaking to other team members and when we’re representing Roivant to people outside the company. Be sure to use Simple Language in written communications as well. Our handbook, knowledgebase, docs, and company-wise emails should be clear, concise, and effective.

Inefficient things shouldn’t sound positive

For example, do not suggest that you’re “working in real-time” when a matter is in disarray. Convey that a lack of organization is hampering a result, and provide feedback and clear steps on resolving.

SharePoint/OneDrive Docs

Avoid using an Office 365 doc (primarily Word, but in some cases, Excel or Powerpoint) for something that is intended to end up in the handbook. Work on these edits via commits to a merge request, then link to the merge request or diff to present the change to people. This prevents a duplication of effort and/or an out-of-date handbook.

DO use O365 docs for (among other uses):

• Meeting agendas
• Meeting notes
• Documents that are frequently updated
• Realtime multi-author editing
• Interfacing with teams outside IT

Good Practices & Helpful Tips

1. If you have content in an O365 Doc that is later moved to the website or handbook, deprecate the O365 Doc.

2. If you are having trouble finding a shared O365 document, make sure you search “Whole Organization” in OneDrive/SP.

3. In our handbook, if you find yourself wondering whether it is better to provide a link to an O365 Doc vs. writing out the content in the handbook, use the following guideline: Is this document frequently adapted / customized? If yes, then provide a link, making sure that the document can be commented on by anyone with the link. If the document is rarely customized, then provide the content directly on the site and deprecate the O365 doc.

How to deprecate an O365 Doc

1. Add ‘Deprecated: ’ to the start of the title. 2. Remove the content you moved. 3. Add a link to the new location at the beginning of the doc/first slide/first tab. 4. Add a link to the merge request or commit that moved it (if applicable).

Zoom

Roivant uses Zoom as the primary video collaboration platform for internal and external communications. Some of our vendors and partners have different preferred tools and to facilitate the communication with those parties. Roivant provides access to WebEx and MS Teams. This service is only provided to team members that have a business need to host meetings and where Zoom is not accepted. It is not efficient for Roivant to use multiple video conferencing tools, however we encourage the use of the most popular ones among our vendors and partners when needed. E.g.; Zoom, WebEx, MS Teams, Skype, etc.

Zoom webinars

Please visit the documentation covering everything you need to know about hosting or participating in a Zoom webinar.

Outlook Calendar

We recommend you set your Outlook Calendar access permissions to ‘People in my organization -> Can view all details’. Consider marking the following appointments as ‘Private’:

1. Personal appointments.

2. Confidential & sensitive meetings with third-parties outside of GitLab. 1

3. 1-1 performance or evaluation meetings.

4. Meetings on organizational changes.

There are several benefits and reasons to sharing your calendar with everyone at Roivant:

1. Transparency is one of our values and sharing what you work on is in line with our message of “be open about as many things as possible”.

2. Due to our timezone differences, there are sometimes small windows of time when our availabilities overlap. If other members need to schedule a new meeting, seeing the details of recurring meetings (such as 1:1s) will allow for more flexibility in scheduling without needing to wait for a confirmation from the team member. This speaks to our value to be more efficient.

If you add blocks of time spent on recurring tasks to your Outlook Calendar to remind yourself to do things, consider marking yourself “Free” for those events so that coworkers know they may schedule a meeting during that time if they can’t find another convenient time.