CREDIT

Roivant IT’s six core values are 🤝 Collaboration, 📈 Results , ⏱️ Efficiency, 🌐 Diversity, Inclusion & Belonging, 👣 Iteration, and 👁️ Transparency, and together they spell the CREDIT we give each other by assuming good intent.

About our values

We take inspiration from other companies, and we always go for the boring solutions or as our CIO, Drew Kramer says: “We should boldly go where thousands have gone before”. But just like the rest of our work, we continually adjust our values and strive to make them better. Roivant IT’s values are a living document. In many instances, they have been documented, refined, and revised based on experiences, success, failures, lessons learned (and scars earned) in the course of doing business. These values are directly adapted from the values as published in the open-source GitLab Handbook

Sub-values as substantiators

The “sub” in sub-value is not in reference to “subordinate,” but rather, “substantiate the core values.”

Sub-values clarify what a given core value means and looks like in Roivant IT. Understanding this distinction is critical to thriving in Roivant IT, particularly for newer team members who may be familiar with a prior organization’s interpretation of iteration or collaboration (as examples).

🤝 Collaboration

Helping, mentoring and working with others is a priority, even when it is not immediately related to the goals that you are trying to achieve. Similarly, you can rely on others for help and advice—in fact, you’re expected to do so. Anyone can chime in on any subject, including people who don’t work in Roivant IT. The person who’s responsible for the work decides how to do it, but they should always take each suggestion seriously and try to respond and explain why it may or may not have been implemented.

Kindness

We value caring for others. Demonstrating we care for people provides an effective framework for challenging directly and delivering feedback. We disagree with companies that say Evaluate People Accurately, Not “Kindly”. We’re all for accurate assessment, but we think it must be done in a kind way. Give as much positive feedback as you can, and do it in a public way.

Everyone can contribute

We believe that everyone, from IT or otherwise, can contribute.

• Contribute to this handbook
• Contribute to Roivant
• Contribute feedback, opinions and information that can help Roivant IT deliver better services to the Vant Federation

Share

There are aspects of Roivant IT culture, such as intentional transparency, that are unintuitive to outsiders and new team members. Be willing to invest in people and engage in open dialogue. For example, consider making private issues public wherever possible so that we can all learn from the experience. Don’t be afraid of judgment or scrutiny when sharing publicly, we all understand it’s impossible to know everything. Everyone can remind anyone in the organization about our values. If there is a disagreement about the interpretations, the discussion can be escalated to more people within the company without repercussions. Share problems you run into, ask for help, be forthcoming with information and speak up.

Negative feedback is 1-1

Give negative feedback in the smallest setting possible. One-on-one video calls are preferred. If you are unhappy with anything (your duties, your colleague, your boss, your salary, your location, your computer), please let your boss, or our CIO, know as soon as you realize it. We want to solve problems while they are small. Negative feedback is distinct from negativity and disagreement. If there is no direct feedback involved, strive to discuss disagreement in a public channel, respectfully and transparently.

Say thanks

Recognize the people that helped you publicly, for example in our #roivant-it-ref chat channel. When publicly thanking, it’s important to recognize the following:

• Showing thanks in as large a setting as possible (company-wide) at a company as large as ours is the exception instead of the norm, it takes some getting used to.

• Being thanked at the company level for what you view as a relatively small or minuscule contribution can feel awkward. Thanking a person in #thanks should be done sincerely and summarize why you are thankful so the person on the receiving end can easily understand why they are being thanked. Even while assuming positive intent, not all folks are comfortable with public praise. Help this person understand how they went above and beyond and why you felt it was important for the team member to be recognized.

• There are a number of good ways and places to say thanks. We shouldn’t limit saying thanks to just the #roivant-it-ref channel.

Give feedback effectively

Giving feedback is challenging, but it’s important to deliver it effectively. When providing feedback, always make it about the work itself; focus on the business impact and not the person. For feedback to be constructive, we strive to make feedback ASK:

• Actionable - About a behavior or event that the recipient can actually control or change.
• Specific - Be specific about what you are giving feedback on, give one or more examples.
• Kind - Be kind. Focus on the behavior or strategy, not on the person. If a person is going through a hard time in their personal life, then take that into account. An example of giving positive feedback is our thanks chat channel. For managers, it’s important to realize that team members react to a negative incident with their managers six times more strongly than they do to a positive one. Keeping that in mind, if an error is so inconsequential that the value gained from providing criticism is low, it might make sense to keep that feedback to yourself. In the situations where negative feedback must be given, focus on the purpose for that feedback: to improve the team member’s performance going forward. Give recognition generously, in the open, and often to generate more engagement from your team.

Get to know each other

We use a lot of text-based communication, and if you know the person behind the text, it will be easier to prevent conflicts. So we encourage people to get to know each other on a personal level through our Take A Break Call

Don’t pull rank

If you have to remind someone of the position you have in the company, you’re doing something wrong. People already know our decision-making process. Explain why you’re making the decision, and respect everyone irrespective of their function. This includes using the rank of another person - including the CEO - to sell an idea or decision.

Assume positive intent

We naturally have a double standard when it comes to the actions of others. We blame circumstances for our own mistakes, but individuals for theirs. This double standard is called the Fundamental Attribution Error. In order to mitigate this bias, you should always assume positive intent in your interactions with others, respecting their expertise and giving them grace in the face of what you might perceive as mistakes. When disagreeing, folks sometimes argue against the weakest points of argument, or sometimes argue against a “straw man”. Assume the points are presented in good faith, and instead try to argue the “steel man” (or the “strong man”):

That’s when you articulate the absolute strongest version of your opponent’s position—potentially even stronger than the one they presented. A good steel-man argument is one where the other person feels you’ve represented their argument well, even if they still disagree with your assumptions or conclusion.

Address behavior, but don’t label people

There is a lot of good in this article about not wanting jerks on our team, but we believe that jerk is a label for behavior rather than an inherent classification of a person. We avoid classifications.

Say sorry

If you made a mistake, apologize as soon as possible. Saying sorry is not a sign of weakness but one of strength. The people that do the most work will likely make the most mistakes. Additionally, when we share our mistakes and bring attention to them, others can learn from us, and the same mistake is less likely to be repeated by someone else. Mistakes can include when you have not been kind to someone. In order to reinforce our values, it is important, and takes more courage, to apologize publicly when you have been unkind publicly (e.g., when you have said something unkind or unprofessional to an individual or group in a Slack channel).

No ego

Don’t defend a point to win an argument or double-down on a mistake. You are not your work; you don’t have to defend your point. You do have to search for the right answer with help from others. Being no ego is a standard we hold ourselves as people to but is not one that applies to Roivant as a company. We want to celebrate and highlight Roivant’s accomplishments. This doesn’t mean we don’t recognize our mistakes.

Don’t let each other fail

Keep an eye out for others who may be struggling or stuck. If you see someone who needs help, reach out and assist, or connect them with someone else who can provide expertise or assistance. We succeed and shine together!

People are not their work

Always make suggestions about examples of work, not the person. Say “You didn’t respond to my feedback about the design” instead of “You never listen”. And, when receiving feedback, keep in mind that feedback is the best way to improve, and that others giving you feedback want to see you succeed.

Do it yourself

Our collaboration value is about helping each other when we have questions, need critique, or need help. Brainstorming and consensus-building can be useful when applied judiciously, but don’t block solutions pursuing either. This may sound paradoxical, given our emphasis on mentoring and pairing, but it comes down to using good judgement for each situation. Share knowledge, seek and offer assistance, but if you are able to deliver an outcome, then don’t wait for consensus or wait to do with many what you could do yourself

Blameless problem solving

Investigate mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process that led to the failure, rather than cast blame on a person or team. We hold blameless root cause analyses and regular team and organizational retrospectives, for stakeholders to speak up without fear of punishment or retribution.

Short toes

People joining a company frequently say, “I don’t want to step on anyone’s toes.” At Roivant, we should be more accepting of people taking initiative in trying to improve things. As companies grow, their speed of decision-making goes down since there are more people involved. We should counteract that by having short toes and feeling comfortable letting others contribute to our domain. FIXME: could use an example

It’s impossible to know everything

We know we must rely on others for the expertise they have that we don’t. It’s OK to admit you don’t know something and to ask for help, even if doing so makes you feel vulnerable. It is never too late to ask a question, and by doing so, you can get the information you need to produce results and to strengthen your own skills as well as Roivant as a whole. After your question is answered, FIXME: we badly need a statement on documentation, this hanbook and how to record things. Don’t display surprise when people say they don’t know something, as it is important that everyone feels comfortable saying “I don’t know” and “I don’t understand.” (As inspired by Recurse.)

Collaboration is not consensus

When collaborating, it is always important to stay above radar and work transparently, but collaboration is not consensus. You don’t need to ask people for their input, and they shouldn’t ask you “Why didn’t you ask me?” You don’t have to wait for people to provide input, if you did ask them. We believe in permissionless innovation—you don’t need to involve people, but everyone can contribute. This is core to how we iterate, since we want smaller teams moving quickly rather than large teams achieving consensus slowly.

Collaboration is not playing politics

We don’t want people to play politics at Roivant. One way to spot when this is happening is when people discussing a proposal focus overly on whose proposal it is. This is a manifestation of the Belief Bias, where we judge an argument’s strength not by how strongly it supports the conclusion but by how strongly we support the conclusion. Proposals should be weighed on their merits and not on who proposed them. The other thing to observe is whether people are being promoted based on others liking them or having a lot of alliances. We want people to be promoted based on their results. We do value collaboration, but that’s different than being promoted just because people like you.

Collaboration Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate collaboration when we take action to help others and include other’s (both internal and external) input (both help and feedback) to achieve the best possible outcome.

📈 Results

We do what we promised, to each other, colleagues, associates, and investors.

Measure outcomes not hours

We care about what you achieve: the code you shipped, the user you made happy, and the team member you helped. Someone who took the afternoon off shouldn’t feel like they did something wrong. You don’t have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules. Do not incite competition by proclaiming how many hours you worked yesterday. If you are working too many hours, talk to your manager to discuss solutions.

Dogfooding

1. Anywhere relevant, use our own product. 2. Roivant doesn’t always make relevant products for IT, in which case we should still wear our own clothes - whenever possible, use the same tools and systems that our colleagues use. 3. When something breaks, doesn’t work well, or needs improvement, we are more likely to notice it internally and address it before it impacts our larger community.

Give agency

We give people agency to focus on what they think is most beneficial. If a meeting doesn’t seem interesting and someone’s active participation is not critical to the outcome of the meeting, they can always opt to not attend, or during a video call they can work on other things if they want. Staying in the call may still make sense even if you are working on other tasks, so other peers can ping you and get fast answers when needed. This is particularly useful in multi-purpose meetings where you may be involved for just a few minutes.

Write promises down

FIXME: Agree in writing on measurable goals. [references public OKRs, which are enterprise level and Roivant does not do, find an alternate example]

Growth mindset

You don’t always get results and this will lead to criticism from yourself and/or others. We believe our talents can be developed through hard work, targeted training, learning from others, on-the-job experience, and receiving input from others. It is in our DNA as a company and individuals to look for opportunity, stay humble, and never settle. We try to hire people based on their trajectory, not their pedigree. We also strive to foster a culture of curiosity and continuous learning where team members are provided and proactively seek out opportunities to grow themselves and their careers.

Global optimization

This name comes from the quick guide to Stripe’s culture. Our definition of global optimization is that you do what is best for the organization as a whole. Don’t optimize for the goals of your team when it negatively impacts the goals of other teams, our users, and/or the company. Those goals are also your problem and your job. Keep your team as lean as possible, and help other teams achieve their goals. In the context of collaboration, this means that if anyone is blocked by you on a question, your approval, or a merge request review, your top priority is always to unblock them, either directly or through helping them find someone else who can, even if this takes time away from your own or your team’s priorities.

Tenacity

We refer to this as “persistence of purpose”. As talked about in The Influence Blog, tenacity is the ability to display commitment to what you believe in. You keep picking yourself up, dusting yourself off, and quickly get going again having learned a little more.

Ownership

We expect team members to complete tasks that they are assigned. Having a task means you are responsible for anticipating and solving problems. As an owner, you are responsible for overcoming challenges, not suppliers or other team members. Take initiative and proactively inform stakeholders when there is something you might not be able to solve.

Sense of urgency

At an scaling startup, time gained or lost has compounding effects. Try to get the results as fast as possible, but without compromising our other values and ways we communicate, so the compounding of results can begin and we can focus on the next improvement.

Ambitious

While we iterate with small changes, we strive for large, ambitious results.

Perseverance

Working at Roivant will expose you to situations of various levels of difficulty and complexity. This requires focus and the ability to defer gratification. We value the ability to maintain focus and motivation when work is tough and asking for help when needed.

Bias for action

It’s important that we keep our focus on action, and don’t fall into the trap of analysis paralysis or sticking to a slow, quiet path without risk. Decisions should be thoughtful, but delivering fast results requires the fearless acceptance of occasionally making mistakes; our bias for action also allows us to course correct quickly. Everyone will make mistakes, but it’s the relative number of mistakes against all decisions made (i.e. percentage of mistakes), and the swift correction or resolution of that mistake, which is important. A key to success with transparency is to always combine an observation with questions to ensure understanding and suggestions for solutions / improvement to the group that can take action. We don’t take the easy path of general complaints without including and supporting the groups that can affect change. Success with transparency almost always requires effective collaboration.

Disagree, commit, and disagree

Everything can be questioned, but as long as a decision is in place, we expect people to commit to executing it. Any past decisions and guidelines are open to questioning as long as you act in accordance with them until they are changed. This is a common principle. Every decision can be changed; our best decision was one that changed an earlier one. In a manager-report circumstance, usually the report is the DRI. The manager may disagree with the final decision, but they still commit to the decision of the DRI. In a group setting, participants may disagree with a proposal but not articulate their views for one reason or another. As a result, everyone loses out on their feedback. Dissent is expression of that disagreement. However, it can be difficult and even socially expensive. Expression of feedback is a way for everyone to grow and learn, and is based on facts rather than opinions. Share your perspective, rather than agreeing simply to avoid conflict or to go along with everyone else. When you want to reopen the conversation on something, show that your argument is informed by previous conversations and assume the decision was made with the best intent. You have to achieve results on every decision while it stands, even when you are trying to have it changed. You should communicate with the DRI who can change the decision instead of someone who can’t.

Accepting uncertainty

We should strive to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along. Wrong solutions can be fixed, but non-existent ones aren’t adjustable at all. The Clever PM Blog

Escalate to unblock

We should be diligent to define Directly Responsible Individuals (DRI). DRIs are empowered to escalate to unblock. Managers in Roivant IT will consistently work to ensure blockages are solved or removed. Early escalation, delivered with context of the challenge, enables managers to function as an unblocker.

Colleague results

Our focus is to improve the results that staff at Roivant, and all our related Vants, achieve, which requires being aware of the Concur effect, see the Hacker News discussion for a specific UX example. Results for our colleagues are more important than:

1. What we plan to make. If we focus only on our own plans, we might have a mountain of complex and interesting systems, but have failed to enable our colleagues. 1. Rank. Focus on solving problems, not people. Our priorities and focus should be on the issues that deliver the best results for Roivant, not merely on who asked for something. 1. What colleagues ask for. This means we don’t use the phrase “user focus”, because it tempts us to prioritize what a colleague says they want over what we discover they actually need through our product development process. Often, it’s easier for a customer to think in terms of a specific solution than to think about the core problem that needs to be solved. But a solution that works well for one employee isn’t always relevant to other employees, and it may not align with our overall strategy. When a colleague asks for something specific, we should strive to understand why, work to understand the broader impact, and then create a solution that scales.

1. Our assumptions. Many teams and orgs inside Roivant works differently, so we can’t assume that what works well for us will support our colleagues’ needs. When we have an idea, we must directly validate our assumptions with our “customers” to ensure we create scalable, highly relevant solutions.

Results Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate results when we do what we promised to each other, customers, users, and investors.

⏱️ Efficiency

We care about working on the right things, not doing more than needed, and not duplicating work. This enables us to achieve more progress, which makes our work more fulfilling.

Write things down

We document everything: in the handbook, in meeting notes, in issues. We do that because “the faintest pencil is better than the sharpest memory.” It is far more efficient to read a document at your convenience than to have to ask and explain. Having something in version control also lets everyone contribute suggestions to improve it.

Boring solutions

Use the simplest and most boring solution for a problem, and remember that “boring” should not be conflated with “bad” or “technical debt.” 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 just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors. Make a conscious effort to recognize the constraints of others within the team. For example, sales is hard because you are dependent on another organization, and development is hard because you have to preserve the ability to quickly improve the product in the future.

Self-service and self-learning

Team members should first search for their own answers and, if an answer is not readily found or the answer is not clear, ask in public as we all should have a low level of shame. Write down any new information discovered and pay it forward so that those coming after will have better efficiency built on top of practicing collaboration, inclusion, and documenting the results.

Efficiency for the right group

Optimize solutions globally for the broader Roivant and Vant consortium. Making a process efficient for one person or a small group may not be the efficient outcome for the whole Vant community. As an example, it may be best to discard a process that requires dozens of Vant staff to each spend two hours in favor of one that only takes sixty seconds, even when it may make a monthly report less efficient internally! In a decision, ask yourself “For whom does this need to be most efficient?” Quite often, the answer may be your colleagues, associates, or team members that are dependent upon your decision. It is easy to prioritize consistency over efficiency because consistency is often more efficient initially. We should slow down when optimizing for consistency. Taking a company-wide lens when evaluating changes will help ensure that new processes will improve efficiency for all Vants as a whole.

Be respectful of others’ time

Consider the time investment you are asking others to make with meetings and a permission process. Try to avoid meetings, and if one is necessary, try to make attendance optional for as many people as possible. Any meeting should have an agenda linked from the invite, and you should document the outcome. Instead of having people ask permission, trust their judgment and offer a consultation process if they have questions.

Spend company money like it’s your own

Every dollar we spend will have to be earned back; be as frugal with company money as you are with your own.

Frugality

Amazon states it best with: “Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.”

ConvDev

We work according to the principles of conversational development.

Short verbal answers

Give short answers to verbal questions so the other party has the opportunity to ask more or move on.

Keep broadcasts short

Keep one-to-many written communication short, as mentioned in this HBR study: “A majority say that what they read is frequently ineffective because it’s too long, poorly organized, unclear, filled with jargon, and imprecise.”

Managers of one

We want each team member to be a manager of one who doesn’t need daily check-ins to achieve their goals.

Freedom and responsibility over rigidity

When possible, we give people the responsibility to make a decision and hold them accountable for that, instead of imposing rules and approval processes. You should have clear objectives and the freedom to work on them as you see fit. Freedom and responsibility are more efficient than rigidly following a process, because they enable faster decision velocity and higher rates of iteration.

Accept mistakes

Not every problem should lead to a new process to prevent them. Additional processes make all actions more inefficient; a mistake only affects one.

Move fast by shipping the minimal viable change

We value constant improvement by iterating quickly, month after month. If a task is not the smallest thing possible, cut the scope.

Embrace change

Adoption of features, user requirements, and the competitive landscape change frequently and rapidly. The most successful companies adapt their roadmap and their organization quickly to keep pace. One of the things that makes this challenging is the impact on our team. People may need to change teams, subject matter, or even who manages them. This can rightly feel disruptive. If we coach ourselves to embrace the positive aspects of change, such as increased opportunity and new things to learn, we can move faster as a company and increase our odds of success. It is important to hold management accountable for being deliberate.

Efficiency Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate efficiency when we work on the right things, not doing more than needed, and not duplicating work.

🌐 Diversity, Inclusion & Belonging

Diversity, inclusion and belonging are fundamental to the success of Roivant. We aim to make a significant impact in our efforts to foster an environment where everyone can thrive[^1]. We are designing a multidimensional approach to ensure that Roivant IT is a place where people from every background and circumstance feel like they belong and can contribute. We actively chose to build and institutionalize a culture that is inclusive and supports all team members equally in the process of achieving their professional goals.

[^1] FIXME: needs links to our HR material

Support asynchronous communication

Take initiative to operate asynchronously whenever possible. This shows care and consideration for those who may not be in the same time zone, are traveling outside of their usual time zone, or are structuring their day around pressing commitments at home or in their community. This is demonstrated by communicating recordings of meetings, using shared docuents or Miro boards, healthily commented Jira stories and help system tickets, rather than texts, calls, or Slack messages, and being sensitive to local holidays and vacation statuses. Encourage others to default to documentationrather than pressuring others to be online outside of their working hours.

documentation

Embracing uncomfortable ideas and conversations

Part of embracing diversity is a willingness to embrace often uncomfortable conversations and situations. This concept is also at the core of inclusion and helping to eliminate the problems that are faced by certain Roivant team members who may not be in the majority. We believe that being willing to embrace discomfort is the path forward to a safe, balanced and inclusive work place for all. Challenge yourself, challenge your own pre-set notions and ideas about different cultures or things you don’t understand. When we are willing to embrace being uncomfortable, we can focus on actually fixing the issues at hand rather than simply “appearing to care”.

Understanding the impact of microaggressions

Microaggressions are much more than merely rude or insensitive comments. They can wear people down by slowly chipping away their sense of belonging/safety/inclusion over time. What is a microaggression?

“The everyday slights, indignities, put downs and insults that people of color, women, LGBT populations or those who are marginalized experiences in their day-to-day interactions with people.” - Derald W. Sue

At Roivant we believe that everyone is entitled to a safe working space where they can express who they are and participate in conversations without worry of being spoken to in a harmful way, given that we want to encourage everyone to be mindful of what is a microaggression and be mindful of their potential impact.

Reach across company departments

While it’s wise to seek advice from experts within your function, we encourage Roivant team members to seek and provide feedback across departments. This enables the team to iterate more quickly, taking a more diverse perspective into account.

Make family feel welcome

One of the unique elements to a distributed organization is the ability to visit a person’s home while collaborating. If the tenor of the meeting allows, feel welcome to invite your family members or pets to drop by and greet your colleagues. Be mindful of language and use of profanity to encourage a family-friendly environment.

Shift working hours for a cause

Caregiving, outreach programs, and community service do not conveniently wait for regular business hours to conclude. If there’s a cause or community effort taking place, feel welcome to work with your manager and shift your working hours to be available during a period where you’ll have the greatest impact for good. For colleagues supporting others during these causes, document everything and strive to post recordings so it’s easy for them to catch up.

Be a mentor

People feel more included when they’re supported. To encourage this, and to support diversified learning across departments, consider Roivant’s [Rotational Analyst](need rotational analyst page) program. FIXME: need RA info/links

Culture fit is a bad excuse

We don’t hire based on culture or select candidates because we’d like to have a drink with them. We hire and reward team members based on our shared values as detailed on this page. We want a values fit, not a culture fit. We want cultural diversity instead of cultural conformity, such as a brogrammer atmosphere. Said differently: “culture add” > “culture fit” or “hire for culture contribution” since diversity drives innovation.

Religion and politics at work

We generally avoid discussing politics or religion in public forums because it is easy to alienate people that have a minority opinion. This doesn’t mean we never discuss these topics. Because we value diversity, inclusion and belonging, and want all team members to feel welcome and contribute equally, we encourage free discussion of operational decisions that can move us toward being a more inclusive company. Roivant also publicly supports pro-diversity activities and events. There is sometimes a gray area where advocating for diversity and political activities may intersect. Team members should use discretion in gray area communications, because a culture of belonging requires us to be respectful of the broad spectrum of views within our work environment. What does this mean in practice? Please feel empowered to share information that highlights diversity, inclusion and belonging issues and how Roivant and Roivant IT team members can get involved.

While it is acceptable for individuals to bring up politics and religion in social contexts such as coffee chats and real-life meetups with other coworkers (with the goal to understand and not judge), always be aware of potential sensitivities and exercise your best judgment.

Quirkiness

Unexpected and unconventional things make life more interesting. Celebrate and encourage quirky gifts, habits, behavior, and points of view. Open source is a great way to interact with interesting people. We try to hire people who think work is a great way to express themselves.

Building a safe community

Do not make jokes or unfriendly remarks about characteristics of the people who make up Roivant and how they identify. Everyone has the right to feel safe when working for Roivant and/or as a part of Roivant IT. We do not tolerate abuse, harassment, exclusion, discrimination, or retaliation by/of any colleagues, including our team members. You can always refuse to deal with people who treat you badly and get out of situations that make you feel uncomfortable.

Unconscious bias

We recognize that unconscious bias is something that affects everyone and that the effect it has on us as humans and our company is large. We are responsible for understanding our own implicit biases and helping others understand theirs.

Inclusive language & pronouns

Use inclusive language. For example, prefer “Hi everybody” or “Hi people” to “Hi guys”, and “they” instead of “he/she”. While there are several good guides from folks like 18f, University of Calgary, and Buffer on using inclusive language, we don’t keep an exhaustive list. When new possibly non-inclusive words arise, we prefer to be proactive and look for an alternative. If your goal is to be inclusive, it is more effective to make a small adjustment in the vocabulary when some people have a problem with it, rather than making a decision to not change it because some people don’t think it is a problem. And if you make a mistake (e.g. accidentally using the wrong pronoun or an outdated phrase), acknowledge it, apologize gracefully and move on; there is no need to dwell on it, and you can work to avoid making that mistake in the future.

Inclusive meetings

Be consciously inclusive in meetings by giving everyone present an opportunity to talk and present their points of view. This can be especially important in a remote setting. With internal meetings, consider using an agenda document for questions. For example, with organizational standups and retros, every meeting has a numbered list that Roivant IT team members can add items to. During the meeting, items are addressed in turn and discussions noted in the same document. Sometimes, these documents can have so much traffic (during the meeting) such that only a limited number of people can edit the document. In these situations, those who have questions should post on zoom chat and those who can edit the document should help copy the question over to the document. In addition, those who can edit the document should also post in zoom chat to see if anyone has any questions that they could help add to the document so that meeting attendees are more empowered to contribute to the conversation.

See Something, Say Something

As Roivant moves towards being a globally-dispersed company, we have team members from many different backgrounds and cultures. That means it is important for each of us to use great judgment in being respectful and inclusive of our teammates. At the same time, we may sometimes not fully realize we have said or done something to offend someone. It is important that our teammates hold each other accountable and let them know if they have unintentionally or intentionally done something so they can learn and gain additional understanding of perspectives different from our own. It is also important that our teammates don’t feel excluded or minimized by the words we use or the things we do. Thus, we all need to speak up when we see something that isn’t respectful or inclusive.

Neurodiversity

Neurodiversity is a type of diversity that includes: autism, ADHD, dyslexia, dyscalculia, dyspraxia, cognitive impairment, and other styles of neurodivergent functioning. While neurodivergent individuals often bring unique skills and abilities which can be harnessed for competitive advantage in many fields including cybersecurity, neurodivergent individuals are often discriminated against, and sometimes have trouble making it through traditional hiring processes. These individuals should be able to contribute as Roivant team members. The handbook, values, strategy, and interviewing process should never discriminate against the neurodivergent.

Family, friends and health first, work second

Long-lasting relationships are the rocks of life. You family, friends and yours and their health come before work.

Diversity, Inclusion & Belonging Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate diversity, inclusion and belongings when we foster an environment where everyone can thrive and ensuring that Roivant is a place where people from every background and circumstance feel like they belong and can contribute.

👣 Iteration

We do the smallest thing possible and get it out as quickly as possible. If you make suggestions that can be excluded from the first iteration, turn them into a separate issue that you link. Don’t write a large plan; only write the first step. Trust that you’ll know better how to proceed after something is released. You’re doing it right if you’re slightly embarrassed by the minimal feature set shipped in the first iteration. This value is the one people most underestimate when they join Roivant IT. The impact both on your work process and on how much you achieve is greater than anticipated. In the beginning, it hurts to make decisions fast and to see that things are changed with less consultation. But frequently, the simplest version turns out to be the best one. People that join Roivant IT may say they already practice this iteration. But this is the value that they have the hardest time adopting. People are trained that if you don’t deliver a perfect or polished thing, you get dinged for it. If you do just one piece of something, you have to come back to it. Doing the whole thing seems more efficient, even though it isn’t. If the complete picture is not clear, your work might not be perceived as you want it to be perceived. It seems better to make a comprehensive product. They see other people in the Roivant IT organization being really effective with iteration but don’t know how to make the transition, and it’s hard to shake the fear that constant iteration can lead to shipping lower-quality work or a worse product. The way to resolve this is to write down only what you can do with the time you have for this project right now. That might be 5 minutes or 2 hours. Think of what you can complete in that time that would improve the current situation. Iteration can be uncomfortable, even painful. If you’re doing iteration correctly, it should be. Reverting work back to a previous state is positive, not negative. We’re quickly getting feedback and learning from it. Making a small change prevented a bigger revert and made it easier to revert. However, if we take smaller steps and ship smaller, simpler features, we get feedback sooner. Instead of spending time working on the wrong feature or going in the wrong direction, we can ship the smallest product, receive fast feedback, and course correct. People might ask why something was not perfect. In that case, mention that it was an iteration, you spent only “x” amount of time on it, and that the next iteration will contain “y” and be ready on “z”.

Don’t wait

Don’t wait. When you have something of value like a potential blog post or a small fix, implement it straight away. Right now, everything is fresh in your head and you have the motivation. Inspiration is perishable. Don’t wait until you have a better version. Don’t wait until you record a better video. Don’t wait for an event. Inventory that isn’t released is a liability since it has to be managed, becomes outdated, and you miss out on the feedback you would have received had you implemented it straight away.

Start off by impacting the fewest users possible

If you do a gradual rollout of your change prefer: few users over many users, internal IT users (dogfooding) over external ones, environments you get faster feedback about (SaaS) over low feedback ones (self-managed), etc.

Reduce cycle time

Short iterations reduce our cycle time.

Minimal Viable Change (MVC)

We encourage MVCs to be as small as possible. Always look to make the quickest change possible to improve the user’s outcome. If you validate that the change adds more value than what is there now, then do it. No need to wait for something more robust. More information is on the Minimum Viable, but this applies to everything we do in all functions. Specifically for product MVCs, there is additional responsibility to validate with customers that we’re adding useful functionality without obvious bugs or usability issues.

Make a proposal

If you need to decide something as a team, make a concrete proposal instead of calling a meeting to get everyone’s input. Having a proposal will be a much more effective use of everyone’s time. Every meeting should be a review of a proposal. We should be brainwriting on our own instead of brainstorming out loud. State the underlying problem so that people have enough context to propose reasonable alternatives. The people that receive the proposal should not feel left out and the person making it should not feel bad if a completely different proposal is implemented. Don’t let your desire to be involved early or to see your solution implemented stand in the way of getting to the best outcome. If you don’t have a proposal, don’t let that stop you from highlighting a problem, but please state that you couldn’t think of a good solution and list any solutions you considered.

Everything is in draft

In Roivant IT, we rarely mark any content or proposals as drafts. Everything is always in draft and subject to change.

Under construction

As we grow as a company, more colleagues will ask for stability, especially in day-to-day user experience. We should always optimize for the long term. This means that users may be inconvenienced in the short term, but current and future users will enjoy a better product in the end. Educating users on the longer-term plan helps create a shared understanding of how a small change will incrementally grow into something more. For example, we could share how an inconvenient change now will evolve into a much more nuanced solution in the future.

Low level of shame

FIXME: This relates to shipping MVP/MVC, which may be imperfect, and “don’t let perfect be the enemy of good”

In a GitLab Unfiltered interview, GitLab Head of Remote Darren M. adds context on this sub-value.

In many organizations, you take a risk when you put forth any work that’s not perfect — where you haven’t spent endless cycles planning for contingencies or counterpoints. Because of this, you’re incentivized to invest a lot of time and effort into preparing for ‘What if?’ scenarios before any work is presented.

The downside to that is clear. If you do eventually put forth the work, but it needed to be course corrected a long time ago, you’ve now squandered a lot of time that you could have spent improving it via iteration.

Having a low level of shame requires you to combat a natural inclination to conceal work until it’s perfect, and instead celebrate the small changes.

Cultural lens

Cultural differences can bring unique challenges and expectations to iteration. For some, expressions like “it doesn’t have to be perfect…” can challenge cultural norms. We encourage you to bring your authentic self and seek shared understanding when iterating. Giving feedback and ensuring psychological safety are necessary for every iterative attempt.

Focus on improvement

We believe great companies sound negative because they focus on what they can improve, not only on what is working well. In every conversation, inside and outside the company, we should ask a question: What do you think we can improve? This doesn’t mean we don’t recognize our successes; for example, see our Say Thanks value. We are positive about the future of the company. We are Short Term Pessimistic And Long Term Optimistic (STePALTO, for short).

Do things that don’t scale

First, optimize for speed and results; when it is a success, figure out how to scale it. Great examples are in this article by Paul Graham.

Make two-way door decisions

Most decisions are easy to reverse. In these cases, the directly responsible individual should go ahead and make them without approval. As Jeff Bezos describes only when you can’t reverse them should there be a more thorough discussion.

Changing proposals isn’t iteration

Changing something without shipping it is a revision, not iteration. Only when the change is rolled out to users can you learn from feedback. When you’re changing a proposal based on different opinions, you’re frequently wasting time; it would be better to roll out a small change quickly and get real world feedback. Never call a revision an iteration because it almost the opposite. A few challenges have arisen with how we approach iteration. The best example may be the proposal of a two-month release cycle. The argument was that a longer release cycle would buy us time for bug fixes and feature development, but we don’t believe that is the case. As detailed above, we aim to make the absolute smallest thing possible, and that doing otherwise will only slow us down. That said, we would love to work on a two-week release cycle, but that should be another conversation.

Embracing Iteration

In order to embrace iteration, the quality of your first iteration should not matter and it shouldn’t discourage you from starting. We should have the attitude that we are trying to achieve as much as possible in a small amount of time; it’s where we are at the end state of an iteration, that counts. The benefit of iteration is to get feedback from the end-user. Focus on sharing context on the end of the first iteration rather than a hypothetical future state requiring multiple iterations.

Make small merge requests

When you are submitting a merge request for a policy change, or a process change in the handbook, keep it as small as possible. If you are adding a new page to the handbook, create the new page with a small amount of initial content, get it merged quickly via Handbook Usage guidelines, and then add additional sections iteratively with subsequent merge requests.

Always iterate deliberately

Rapid iteration can get in the way of results if it’s not thought out; for example, when changing settings that affect user experience on a core system like email (where stability and consistency is key), or this values page (where we use the values to guide all Roivant IT team members). In those instances, we add additional review to the approval process; not to prohibit, but to be more deliberate in our iteration. The change process is documented in the GitLab Handbook Usage page and takes place via merge request approvals.

Iteration Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate iteration when we do the smallest thing possible, getting it out quickly for feedback and making changes based that feedback.

Job Grade	Demonstrates Iteration Competency by…
5	Develops own knowledge by trying and failing. When asking questions isn’t content with silence or unhelpful/incomplete responses, seeks out primary sources.
6	Actively looks for opportunities to iterate and contribute to boring solutions. Balances short term gains and long term benefit with team’s help. Ships things that aren’t 100% knowing that you’ll either be able to improve them in the next revision. Asks questions with abandon. Publicly shares failures if you’ll help colleagues learn.
7	Independently balances short term gains and long term benefit. Identifies opportunities to deliver projects in an iterative way.
8	Is able to take long term goals and turn them into small actionable steps that can be implemented in an iterative way. Identifies and prevents decisions that are not “two-way door decisions”. Ships. All the time. Sounds like a broken record in discussions with more junior members of the team; always asking if we can make something smaller.
9	In addition to upholding the requirements of a Staff/Manager level, a Sr. Manager practices and fosters the value of iteration to team members. They hold their team members accountable for iteration and boring solutions.
10	In addition to upholding the requirements of a Sr. Manager, a Director proactively finds ways to drive the value of iteration and boring solutions.
11	In addition to upholding the requirements of a Director , a Sr. Director embeds the value of Iteration across the department and division. They use their cognitive and analytical abilities to anticipate and adapt to unpredictabilities in regard to strategic risk in a way that benefits all involved.
12	In addition to upholding the requirements of a Sr. Director , a VP leads the way for the value of Iteration across the division and cross functional teams. They confidently lead their teams through change and proactively take risks based on values and the strategic vision.
EVP/CXO	In addition to upholding the requirements of a VP, the EVP champions the value of Iteration across Roivant. They are comfortable leading through discomfort and the unease associated with change and innovation.

👁️ Transparency

Be open about as many things as possible. By making information organization and company-public, we can reduce the threshold to contribution and make collaboration easier. Use company-public issue trackers, projects, and repositories when possible.

There are exceptions. Material that is not public by default is documented. We must strive to keep things confidential that need to be. On a personal level, you should tell it like it is instead of putting up a poker face. Don’t be afraid to admit you made a mistake or were wrong. When something goes wrong, it is a great opportunity to say “What’s the kaizen moment here?” and find a better way without hurt feelings. Even as we move towards becoming a public company and beyond, we know that our value of transparency will be key to our success. This value can be hard to follow at times. You might ask yourself: what should be shared, how much to share, whether or not to speak up but definitely take the time to always opt for maximum transparency by adhering to the sub-values below. Often, company values get diluted as they grow, most likely because they do not write anything down. But we will make sure our values scale with the company. If and when we go public, we can declare everyone in the company as an insider, which will allow us to remain transparent internally about our numbers, etc. Everything else that can be transparent will continue to be so.

What does “public” mean?

Starting with Handbook version 1.0.0, we now support fully internet-public and company-private pages.

While Roivant IT’s ultimate goal is to produce a handbook which can be fully public to the internet, for perusal by associates, prospective hires, and so on, there will always be certain content that is inappropriate to share with the world and it not public, such as: proprietary company data, some technical information or anything involving Legal.

Please be aware, anything under content/it is fully internet public.

Public by default

Everything done by Roivant IT should be public by default. If something is not public, there should be a reference in the handbook that states a confidential decision was taken with a link to our Not Public guidelines, unless legal feels it carries undue risk. The public process does two things: allows others to benefit from the conversation and acts as a filter. Since there is only a limited amount of time, we prioritize conversations that a wider audience can benefit from. If you believe something shouldn’t be public that currently is (or vice versa), then submit a service ticket, linking to the relevant page(s) suggesting the change so that you can collaborate with others and discuss with the DRI.

Not public

We make information public by default because transparency is one of our values. However it is most important to focus on results. Therefore, a category of information is public unless there is a reason for it not to be. When information is not public, it may also be treated as limited access, only shared with certain Roivant roles, teams, or team members due to privacy considerations, contractual obligation, or other reasons that the author or DRI can specify. Certain kinds of information default to limited access, including details about team members or customers who did not give permission to share the information. Most companies become non-transparent over time because they don’t accept any mistakes. Instead, we should always err on the side of transparency when there is a choice to be made between caution or inaction, and transparency. If we make a mistake, we now know what the limits of transparency are for the company and we should document this. The only exception to this rule would be in the case when there are legal concerns.

We document what is not public by default on our communication page.

Directness

Being direct is about being transparent with each other. We try to channel our inner Ben Horowitz by being both straightforward and kind. Feedback is always about your work and not your person. That doesn’t mean it will be easy to give or receive it.

Articulate when you change your mind

If you state one thing, and then change course and support a different direction, point, or outcome, articulate this. It is OK to have your position changed by new data. Articulating that an earlier stance is not your current stance provides clarity to others and encourages data-driven decision making.

Surface issues constructively

Be transparent to the right people (up) at the right time (when still actionable). If you make a mistake, don’t worry; correct it and proactively let the affected party, your team, and the CEO know what happened, how you corrected it, and how—if needed—you changed the process to prevent future mistakes.

Transparency is most valuable if you continue to do it when there are costs

We practice transparency even when hiding the facts would be easier. For example, many companies do not give you the real reason why they declined your application because it increases the chance of legal action. We want to only reject people for the right reasons and we want to give them the opportunity to grow by getting this feedback. Therefore, we’ll accept the increased risk of holding ourselves to a high standard of making decisions and do the right thing by telling them what we thought. Other examples are being transparent about security incidents and participating in and contributing to Live Broadcasts. Transparency has costs (distraction, mis-interpretation, etc.) but also great benefits, we should carefully weight the tradeoff evaluating transparency to prevent a knee-jerk reaction to reduce it when it has costs.

Single Source of Truth

By having most IT organization communications and work artifacts be public to the company, we have one single source of truth for all Roivant IT team members, colleagues and Vant associates. We minimize needing separate artifacts with different permissions for different people.

Findability

Our transparency value means more than just making information accessible to all. In order to improve performance it’s important that we not only ensure information is accessible, but also ensure it flows to the correct places and is findable by those who need it. Focusing on information flow will ensure you, for example, utilize multi-modal communication, or that you keep your stakeholders informed of changes by posting links to significant changes in Slack.

Say why, not just what

Transparent changes have the reasons for the change laid out clearly along with the change itself. This leads to fewer questions later on because people already have some understanding. A change with no public explanation can lead to a lot of extra rounds of questioning, which is less efficient. This also helps with institutional memory: a year from now when you want to know why a decision was made, or not, the issue or MR that has the decision also shares why the decision was made. This is related to Chesterton’s fence - it’s much easier to suggest removing or changing something if you know why it exists in the first place. Avoid using terms such as “industry standard” or “best practices” as they are vague, opaque, and don’t provide enough context as a reason for a change. Similarly, merely stating a single value isn’t a great explanation for why we are making a particular decision. Many things could be considered “iteration” or “efficiency” that don’t match our definition of those values. Try to link to a sub-value of the value or provide more context, instead of just saying a single value’s name. Saying why and not just what enables discussion around topics that may impact more than one value; for instance, when weighing the efficiency of boring solutions with the focus on results. When decisions align with all of our values, they are easy to discuss and decide. When there are multiple values involved, using our values hierarchy and directly discussing the tradeoffs is easier with more context. Articulating why also helps people understand how something changed when you articulate that you changed your mind. Saying why does not mean justifying a decision against all other suggestions. The DRI is responsible for their decision. The DRI is not responsible for convincing other people, but they should be able to articulate their reasoning for the change.

When a Roivant IT Team Member comes across an ask or material (Jira stories, handbook, etc.) that does not provide a “why” with sufficient context, the Team Member is responsible for getting the why and, if needed, working with the DRI to ensure that it is adequately documented and communicated to give context to other team members. In the absence of a why, team members may speculate the why. This is something that can lead to disruption and inefficiency.

Reproducibility

Enable everybody involved to come to the same conclusion as you. This not only involves reasoning, but also providing, for example: raw data and not just plots; scripts to automate tasks and not just the work they have done; and documenting steps while analyzing a problem. Do your best to make the line of thinking transparent to others, even if they may disagree.

Accountability

Transparency increases accountability when making decisions and difficult choices.

Transparency Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate transparency when we are open with as many things as possible reducing the threshold to contribution and make collaboration easier.

Five dysfunctions

Our values help us to prevent the five dysfunctions:

1. Absence of trust Unwilling to be vulnerable within the group => prevented by collaboration, specifically kindness. 2. Fear of conflict Seeking artificial harmony over constructive passionate debate => prevented by transparency, specifically directness and collaboration, specifically short toes

2. Lack of commitment Feigning buy-in for group decisions creates ambiguity throughout the organization => prevented by transparency, specifically directness

3. Avoidance of accountability Ducking the responsibility to call peers on counterproductive behavior which sets low standards => prevented by results, iteration, and transparency

4. Inattention to results Focusing on personal success, status, and ego before team success => prevented by results

Some dysfunctions are not addressed directly by our values; for example, trust is not one of our values. Similar to happiness, trust is something that is an outcome, not something you can strive for directly. We hope that the way we work and our values will instill trust, instead of mandating it from people; trust is earned, not given.

Why have values

Our values should give guidelines on how to behave and must be actionable. They help us describe the type of behavior that we expect from people we hire. They help us to know how to behave in the enterprise and what to champion when interacting with others. Values are a framework for distributed decision making; they allow you to determine what to do without asking your manager.

How to scale the business while preserving our values?

Everyone can contribute in Roivant IT. We encourage team members to share feedback and leave comments on issues. Leaving feedback and comments shows that team members care about a topic, about Roivant IT and about Roivant as a company. These perspectives may also uncover potential risks and problems in the project. There shouldn’t be a “Don’t they have their job to do?” type of response. Furthermore, we shouldn’t judge team members who are perceived as being the “squeaky wheel.” In Roivant IT, we measure results, not hours. As long as a team member is producing required results, they are empowered to decide how to spend their time. On the other hand, as Roivant grows in size, we need to make decisions and the decisions may not be agreed to by everyone. If a decision or project is sensitive or controversial, and receives large amounts of feedback, it can be challenging for the project DRI to handle. In these cases, it’s best to have time-boxed feedback built into timelines. In a hypothetical example where a DRI needs to decide between red and gold potatoes for a stew, they would create a Jira story with the following sentiment:

We’re deciding between red potatoes and gold potatoes to go into the soup. We have to decide by Tuesday 2020-07-14 so that we can get our order to the grocery store on Wednesday 2020-07-15. We’ll be collecting input and feedback until that point. Jane is the DRI and will make the decision on 2020-07-14 with all the information we have at that point. Here is the framework we’re using for the decision:

• are there allergies to consider?
• cost per pound
• team member preferences

Once the decision is made, it will be what is going into the stew.

Hierarchy

Occasionally, values can contradict each other. For instance, transparency would dictate we publish all security vulnerabilities the moment they are found, but this would jeopardize our users. It’s useful to keep in mind this hierarchy to resolve confusion about what to do in a specific circumstance, while remaining consistent with our core values. Think of the hierarchy as a weighting system. Values higher in the hierarchy do not automatically override values lower in the hierarchy. Here are some examples:

• If a change impacts Transparency positively but impacts Efficiency negatively in roughly the same amount, we would move ahead since Transparency is higher in the hierarchy than Efficiency.

• If a change has a massive positive impact on Diversity but negatively impacts Iteration, we would move ahead even though Diversity is lower in the hierarchy than Iteration because the overall impact is more positive than negative.