About our values
A few important things to note about our values before you dig in.
- We are unabashed fans of Gitlab
- We're a small (for now) startup, moving quickly.
What you see below is mostly a copy/paste of Gitlab's values. We've read their values many times and have made changes that reflect who we are. Like everything we make, this will continually be updated as we learn and grow.
Juniper's six values are Collaboration, Results, Efficiency, Diversity & Inclusion, Iteration, and Transparency, and together they spell the CREDIT we give each other by assuming good intent. They are made actionable below.
Helping 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. 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.
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
Negative 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 the CEO, know as soon as you realize it. We want to solve problems while they are small.
Say thanks. Express gratitude.
Frequently recognize people that have helped you in our slack #thanks channel. You can also express gratitude "I'm thankful for...". Gratitude has been proven to improve relationships, physical and mention health and even how well you sleep. We actively practice gratitude.
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. Make sure to provide at least one clear and recent example. 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 employees 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 employee’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.
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 - "Believe the best"
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.
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 publically 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).
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.
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 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. No need to brainstorm, wait for consensus, or do with two what you can 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 retrospectives for stakeholders to speak up without fear of punishment or retribution.
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 Juniper as a whole. After your question is answered, please document the answer so that it can be shared.
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.)
We do what we promised to each other, customers, users, and investors.
Measure results 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.
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. 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.
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
Agree in writing on measurable goals. Within the company we use OKRs for that.
You don't always get results and this will result in criticism from yourself and/or others. We believe our talents can be developed through hard work, good strategies, and input from others. We try to hire people based on their trajectory, not their pedigree.
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.
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 pro-actively inform stakeholders when there is something you might not be able to solve.
While we iterate with small changes, we strive for large, ambitious results.
Working at Juniper 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.
The ability 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
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.
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.
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.
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."
We work according to the principles of conversational development.
You should have clear objectives and the freedom to work on them as you see fit.
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
And 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.
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.
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 minimum viable change
We value constant improvement by iterating quickly, month after month. If a task is too big to deliver in one month, cut the scope.
Diversity & Inclusion
Diversity and inclusion are fundamental to the success of Juniper Labs. We aim to make a significant impact in our efforts to foster an environment where everyone can thrive. We are designing a multidimensional approach to ensure that Juniper 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 employees equally in the process of achieving their professional goals. We work to make everyone feel welcome and to increase the participation of underrepresented minorities in our company.
Bias towards 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 restructuring their day around pressing commitments at home or in their community.
This is demonstrated by communicating recordings of meetings, using GitLab Issues and Merge Requests rather than texts, calls, or Slack messages, and being sensitive to local holidays and vacation statuses. Encourage others to default to documentation rather than pressuring others to be online outside of their working hours.
Make family feel welcome
One of the unique elements of an all-remote culture 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.
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.
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 employees 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, for example, a brogrammer atmosphere. Said differently: "culture add" > "culture fit" or "hire for culture contribution".
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 and inclusion, 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.
It's also 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), but always be aware of sensitivities, exercise your best judgment, and make sure you stay within the boundaries of our Code of Conduct.
Building a safe community
Do not make jokes or unfriendly remarks about race, ethnic origin, skin color, gender, or sexual orientation. Everyone has the right to feel safe when working for Juniper and/or as a part of the Juniper community. We do not tolerate abuse, harassment, exclusion, discrimination or retaliation by/of any community members, including our employees. You can always refuse to deal with people who treat you badly and get out of situations that make you feel uncomfortable.
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. We are continuously working on getting better at this topic.
Inclusive language & pronouns
Use inclusive language. For example, prefer "Hi everybody" or "Hi people" to "Hi guys". 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, no need to dwell on it at the moment. After, you can work hard to avoid making that mistake in the future.
Neurodiversity is a type of diversity that includes Autism, ADHD, and other styles of neurodivergent functioning. While they 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 Juniper team-members. The handbook, values, strategy, and interviewing process should never discriminate against the neurodivergent.
Family and friends first, work second
Long lasting relationships are the rocks of life and come before work. Rarely do people regret not working more. Often people regret working too much to the exclusion of time with their family and friends.
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.
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 Juniper Labs 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.
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. 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 (like Contribute). Inventory that isn’t released is a liability since it has to be managed, gets outdated, and you miss out on the feedback you get when you would have implemented it straight away.
Reduce cycle time
Short iterations reduce our cycle time.
Work as part of the community
Small iterations make it easier to work with the wider community. Their work looks more like our work, and our work is also quicker to receive feedback.
Minimum 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 in the product handbook, 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, please state that you couldn't think of a good solution and list any solutions you considered.
Everything is in draft
At Juniper we rarely put draft on any content or proposals. Everything is always in draft and subject to change.
As we get more users they will ask for stability, especially in our UX. We should always optimize for the long term. This means that users will be inconvenienced in the short term, but current and future users will enjoy a better product in the end.
Focus on Improvement
We believe great companies sound negative because they focus on what they can improve, not on what is working. Our first question in every conversation with someone outside the company should be: 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 present day pessimists and long term optimists.
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, have the directly responsible individual make them without approval. As Jeff Bezos describes only when you can't reverse them should there be a more thorough discussion.
Make small merge requests
When you are submitting a merge request for a code 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, and then add additional sections iteratively with subsequent merge requests. Similarly, if you are adding a large feature to the software, create small, iterative merge requests for the different aspects. These merge requests might not provide immediate value, as long as they do not break anything, and have appropriate tests for new functionality. If you aren't sure how to split something into small, iterative merge requests, consider kindly asking your team and/or maintainers for suggestions. If you are asked to review a merge request that is too big, consider kindly asking the author to split it into smaller merge requests before reviewing.
Be open about as many things as possible. By making information public we can reduce the threshold to contribution and make collaboration easier. Use public issue trackers, projects, and repositories when possible.
Being direct is about being transparent with each other. We try to channel our inner Ben Horowitz by being both straightforward and kind, an uncommon cocktail of no-bullshit and no-asshole. Feedback is always about your work and not your person. That doesn't mean it will be easy to give nor receive it.
Anyone and anything can be questioned
Any past decisions and guidelines are open to questioning as long as you act in accordance with them until they are changed.
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, which is a common principle. Every decision can be changed, our best decision was one that changed an earlier one. 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 directly responsible individuals who can change the decision instead of someone who can't.
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. 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.
Enable everybody involved to come to the same conclusion as you. This not only involves reasoning, but also, for example providing 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.
Increases accountability when making decisions and difficult choices.
Our values help us to prevent the five dysfunctions.
- Absence of trust Unwilling to be vulnerable within the group => prevented by collaboration, specifically kindness
- Fear of conflict Seeking artificial harmony over constructive passionate debate => prevented by transparency, specifically directness and collaboration, specifically short toes
- Lack of commitment Feigning buy-in for group decisions creates ambiguity throughout the organization => prevented by transparency, specifically directness
- Avoidance of accountability Ducking the responsibility to call peers on counterproductive behavior which sets low standards => prevented by results, iteration, and transparency
- 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 organization and what to expect from others. Values are a framework for distributed decision making; they allow you to determine what to do without asking your manager.