About our Values

We take inspiration from other companies and we continually adjust our values to create a better workplace for everyone.

Collaboration

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, including people who don't work at Agile Lab. 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're all for accurate assessment, but we think it must be done kindly. Give as much positive feedback as you can, and do it in a public way, for example in our #thanks channel.

Share

There are aspects of Agile Lab culture, such as extreme 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.

Negative is 1-1

Give negative feedback in the smallest setting possible. One-on-one video calls or live meeting are preferred. Avoid negative talking about people that are not involved in the discussion. In negative feedback, we should be specific about what the problem is. For example, saying someone is "not living the values" isn't helpful.

Say thanks

Recognize the people that helped you publicly.

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 situations where negative feedback must be given, focus on the purpose of 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 through our company meetings or 1-1 video calls.

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.

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

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

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.

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.

Short toes

People joining the company frequently say, "I don't want to step on anyone's toes." At Agile Lab 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 feel comfortable letting others contribute to our domain.

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 skills as well as Agile Lab as a whole. After your question is answered, please document the answer so that it can be shared.

Trust

We don't just trust people to obey th erules, wee also trust that they know when to break rules. The rules are there for normal operations, they are designed to avoid danger and to help ensure that things go smoothly. And though there are guidelines for how to deal with emergencies, at the end of the day, we trust the expertise of our people to know when to break the rules. We can't trust rules or this handbook, we can rely on them but trust is a human experience and can be real only among people. We break rules only when it is the right thing to do for others or for the company, never for personal gain.

Results

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 customer 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, unless this is your initiative. When you work on site side by side with the customer, consider that may be the customer doesn't share this value and we need to adapt to its policy.

Growth mindset

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.

Global optimization

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 pro-actively inform stakeholders when there is something you might not be able to solve.

Sense of urgency

At an exponentially scaling startup time gained or lost has compounding effects. Try to get the results as fast as possible 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 Agile Lab 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.

Accepting Uncertainty

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.

Customer results

Our focus is to improve the results that we deliver to customers.

Efficiency

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.

Efficiency for the right group

Optimize solutions globally for the broader Agile Lab. Making a process efficient for one person or a small group may not be an efficient outcome for the whole Agile Lab. As an example, it may be best to choose a solution for making things slightly less handy for you to develop while making things massively more efficient for the customers.

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

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.

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

Inclusion and Work Life Balance

Building a safe community

Everyone has the right to feel safe when working for Agile Lab. We do not tolerate abuse, harassment, exclusion, discrimination or retaliation by/of any employees.

Family and friends first, work second

Long lasting relationships are the rocks of life and come before work.

Working in Agile Lab is not a marriage

We encourage a high level of friendship in the company that will survive when you will leave the company

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. We are continuously working on getting better at this topic

See Something, Say Something As a globally dispersed company, we have employees 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

Iteration

Something is better than nothing

Don't wait

Don’t wait. When you have something of value for Agile Lab goals, do/say it. 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.

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.

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.

Rework is not evil

Don't be afraid or bored to rework something already done, because nothing is 100% done.

When we iterate slowly

In some cases, rapid iteration can get in the way of results. For example when defining and proposing solutions to the customer ( where consistency is key), fixing due dates and deliverables and this values page. In those instances we add additional review to the approval process, not to prohibit, but to be more deliberate in our iteration.

Trasparency

Directness

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.

Surface issues constructively

Be transparent to the right people (up) at the right time (when still actionable)

Anyone and anything can be questioned

Any past decisions and guidelines are open to questioning as long as you act following 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. 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 person who can change the decision instead of someone who can't.

Accountability

Increases accountability when making decisions and difficult choices. Be respectful of other people accountabilities.

Five dysfunctions

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.

Permission to play

From our values we excluded some obvious behaviors, we call them our permission to play behavior:

  • Be truthful and honest.
  • Be dependable, reliable, fair, and respectful.
  • Be committed, creative, inspiring, and passionate.
  • Be deserving of the trust of our users and customers.
  • Act in the best interest of the company, our team members, our customers, users, and investors.
  • Act in accordance with the law.
  • Don't show favoritism as it breeds resentment, destroys employee morale, and creates disincentives for good performance. Seek out ways to be fair to everyone.
@AgileLab https://www.agilelab.it/

Found an error in the handbook? The source code can be found here. Please feel free to edit and contribute a merge request, powered by Gitbook
Modified at: 2021-04-08 10:00:09

results matching ""

    No results matching ""