Feedback is a gift.

We value intellectual humility and acknowledge the limits of our own perspectives, welcoming both positive and constructive feedback with open arms. We believe in frequent and specific that results in fewer surprises, a more collaborative environment, and a space where we can make mistakes and learn.

There are many examples of our feedback-rich culture, some of which include:

1. Feedback surveys after meetings. After all-hands meetings, engineering meetings, and weekly updates we send surveys to help us pulse-check and continuously improve our meetings as we grow.
2. Nova Credits. After all-hands every week, we go around and give thanks to someone for demonstrating one of our company values. We also regularly use our #thanks Slack channel to give credit throughout the week.
3. Feedback training. We host feedback trainings regularly to provide each employee with the tools to have productive conversations. Because one of our core values is 'Challenge Without Ego', it's important for us to give feedback to one another in a way that is professional and respectful, keeping team interests top of mind instead of our own.

Our core company values are CHEF: collaboration, humility, empathy, feedback.

Continuously giving and receiving feedback is an effect of our collaborative spirit. We’re huge on Dropbox Paper and everything that we have on paper is shared openly with all members of the team so that anyone can comment or edit them. Obviously, aside from confidential HR material, anything that is physical through our paper files is shared. We have two separate engineering teams working on our two separate products. At the end of each sprint, we do thorough engineering retros where we crowd source feedback about what went well and what didn’t using an open, shared document. Our feedback extends beyond engineering and is embedded in how we operate as a company. At the end of our training sessions with our customers, we provide each transit agency with a thorough feedback survey. We truly integrate collecting feedback into everything we do, both internally but externally.

Feedback is an integral part of how we get better.

When we don’t hire a candidate, we do our best to give genuine feedback. That’s just the beginning. For candidates we do hire, we automatically set up 30-, 60-, and 90-day reviews once you join the company. These ensure we’re on track with expectations and make it easy for us to course correct if something is misaligned. The reviews always go both ways, too: we want to hear how Dark could be better for you.

Our desire to improve our engineering team is expressed in all of our day-to-day practices. We do regular code reviews. On some projects we opt to pair program, so people can ramp up on new pieces of the codebase. During onboarding, we pair regularly. We also ask our newer employees to review complicated pull requests, so they can see and ask about architectural decisions. We give each other feedback on how we performed during meetings (in private, right after the meeting).

We also think feedback is what helps our product get better. Every day, we get user feedback through our dedicated Slack channel. If we can, we fix issues as they come up. If not, we link to the message in a ticket and will tell the user when we’ve fixed it.

For more personal feedback, we believe in giving constructive feedback privately, and complimentary feedback based on each person’s preference. Not everyone likes to be praised in a public manner. We also strive to give feedback immediately after something occurs, and to format it in a truthful, nonviolent way: “when you X, the story I tell myself is Y, and the impact is Z.”

Once things are running smoothly, every engineer has a 1-1 with the CEO and CTO weekly. These meetings are a chance to provide and solicit additional feedback, and the agenda is driven by the employee.

Being feedback-driven is what enables us to think not as one, but as many.

Giving each other feedback is not just a competitive advantage, we believe it’s also a moral obligation. We aspire to give feedback not just to our managers and direct reports, but also to everyone around us (including ourselves). That’s why we have an open feedback calendar and encourage employees to take the initiative to seek and give honest feedback regularly. Simply drop your colleagues a calendar invite for a feedback session.

We also have bi-weekly 1:1s dedicated to feedback and view prepping for them well in advance as an important commitment. Good feedback should be both caring and direct, which is why we have a specific feedback template (see below) that employees fill out prior to the 1:1.

Our emphasis on always giving feedback influenced Aaliya Manji, chief of staff, to create a ‘Thanks of the Week’ section in our all-hands meeting doc. It was a great way for team members to recognize one another and further foster Aula’s culture of warm and caring relationships in a remote setting. Ultimately, taking the time to thoughtfully engage in feedback sessions garners respect from other team members and helps us all grow.

We aspire to the lean methodology of continuous feedback.

Every member of our team has a unique perspective and can contribute in valuable ways to both our product and our processes. We have formal weekly retrospectives as well as at the end of big projects. We don’t take these for granted since they are the best times to reflect on what we did well and where we can make improvements. The feedback we give one another is always specific, direct, and honest, and most importantly, it always comes from the desire to make the product better for our customers. We also do weekly demos to solicit in-the-moment feedback for work that is in progress and design reviews to critique upcoming feature work.

Informally, we give shoutouts to each other whenever someone is doing a great job or embodying one of our company’s core values. This includes transparency, supporting teammates and our users, or finding innovative, simple ways to make our user experience more delightful or approachable.

One of our values is Candour, which we consider to be like a muscle.

The more you use it the stronger it gets. We train this muscle through our regular 360 feedback sessions, and finishing every meeting 5 minutes early to end with a feedback session on how the meeting went. Our founders and the senior team set the precedent early on, by constantly giving feedback. We genuinely want to help each other at Thread, so the expectation (and norm!) is that all feedback is delivered compassionately and with care. With frequent use, our Candour muscle is strong.

Managers have regular 1:1’s with their team members, typically weekly or bi-weekly.

These 1:1’s are primarily led by you, rather than your manager. It’s a space for you to celebrate your successes, ask tough questions, and bring ideas forward. It can also be used as a place to get technical feedback, but also a great way to get to know your manager better. During the course of day-to-day development, your peers will be reviewing your code during our pull request feedback cycle: create the PR, pass our CI, two or more peers will review, and then merge and deploy. There are quarterly reviews that focus on the engineering rubric, and the developer’s career goals. This is an opportunity for you to work with your manager to decide how you want to learn and grow.

We believe in feedback - in all forms.

We take feedback from our users through Intercom, Satismeter, and by meeting with them every week. People from our team regularly go and introduce new teachers to Peergrade at seminars, conferences and schedule meeting with instructors trying to implement Peergrade. We have monthly 1-on-1’s with everyone on the team and quarterly performance reviews. We try to have a very open feedback culture where everyone can bring up any request to anyone. The only way to avoid group-thinking is to really push each other’s ideas all the time. After each round of 1-on-1’s we change 2-3 things about the way we work on average, from better scheduling of holidays, new sprint structures to finding career mentors for employees.

We believe that feedback loops are vital to the success of our company and employees.

Webflow employees constantly look for ways to improve our product, company, and each other. Even though useful feedback takes thought and care, we know that it has extraordinary value.

• All product teams share their roadmaps transparently, and have open Slack channels for anyone to ask questions or provide suggestions, regardless of what team you work on or your job title.
• Leadership is very accessible, and listens to employee feedback. There is an open Q&A at the weekly company all-hands, where people ask questions about anything from company finances to product direction. All leaders, including our CEO, welcome private feedback via direct messages and want to make sure everyone feels heard.
• Our employees practice kindness toward each other. That kindness means we make sure to give valuable feedback about where a coworker can improve, and listen patiently when receiving feedback.

Giving and listening to feedback is a skillset we help build. In addition to building a psychologically safe work environment, Webflow provides a variety of programs to help facilitate continuous feedback:

• We have hosted the creator of the Radical Candor framework, Kim Scott, multiple times with open Q&A sessions, and have built Radical Candor into our career development for all roles.
• We run semi-annual 360 feedback cycles where employees give non-anonymous peer and manager feedback. This feedback is structured in a mad-libs style that helps reduce bias and focuses the feedback around our core behaviors.
• We run semi-annual company surveys to quantify how employees are feeling. Specific departments also run their own surveys, such as Engineering’s team well-being check-ins, which can help us incrementally improve our working style and workload.

We are always a work in progress – we know that we can do even better, and we actively iterate thanks to feedback.

We have a strong culture of documenting feedback.

We encourage all plans to come in narrative format (usually either Confluence or Google doc) and that all feedback be documented, too. Engineers provide feedback in the form of comments in a doc and then doc reviews are scheduled so we can assess all feedback in a broader team setting. We capture code feedback during peer code reviews and also conduct a monthly employee engagement survey, which contains several open-ended questions. Every 1:1 meeting at ActZero focuses on the free exchange of feedback.

We hold weekly product review meetings to discuss important changes in the product. We consider these to be a great opportunity for engineers to question, challenge, and/or comment on the direction of the product and make their feedback known. Everyone is welcome to Slack their PM or any member of the team individually, too. Regardless of when or how feedback is given, we rely on each member of our team speaking up.

Lastly, there’s a strong foodie culture at ActZero. Our favorite team activity is enjoying great good together and we have a healthy budget for very nice lunch/dinner events. So many of our celebrations, decisions, and debates happen around an amazing meal, and these create organic opportunities for feedback to take place, too.

Continuous and open feedback are baked into the cultural pie that makes up CMB.

We all sit together which makes it easy to provide and solicit feedback. Open communication and collaboration comes so naturally to us that, at one point, we had to swing the pendulum back the other way and block time off for people to work independently. We have since found our sweet spot, and foster a culture of communication that is both open and respectful of everyone’s personal workload. We also have an all-hands (that segues into happy hour) every Friday. Each team shares updates, we ask our CEO questions about everything from fundraising to recruiting, and then collectively close our laptops, turn on music, and open some beers. Finally, at the basic and clinical level, we implement feedback with quarterly evaluations. With midpoint check-ins, you’ll receive feedback about your progress in reaching your OKRs and identify areas of improvement.

We’re obsessed with the process and love learning from our customers and our team members.

Our design and development process is centered around two-week sprints where we deploy rapidly, learn from our users, and continually iterate. As a small team, time is everything to us – and we like to work efficiently and optimally. That means team members need to feel comfortable stating their opinions and openly debating any decision we make that they might disagree with. Everyone has a voice in this company. (It’s just a matter of surfacing what you believe to be true in a constructive and positive manner!)

We gather feedback from our clients, end users, and analytics tools, and we’re focused on having researched business cases behind every decision we make. We want to hire people who have expertise in areas where our current team members do not. As our engineering team has grown, we’ve organically started to pair more. We’re not dogmatic about pairing in any way, and wouldn’t even say that we’ve cultivated a pairing culture, but our engineers naturally come together to review each other’s pull requests and work through problems together. As we continue to grow, we hope to move further and further away from silos.

Feedback is the pathway to improvement.

We work to continually embed feedback and communication into everything we do. Several of the defined processes we use for this are 1:1s, retros, and code reviews.

Every manager holds regular 1:1s to provide an environment for facilitating open communication as well as coaching and two-way feedback. Each manager leverages a variety of questions to create a space where individuals can celebrate their wins and recognize others, but also share their lows, challenges, and concerns. Within this environment, both individuals are expected to share feedback on areas for improvement.

At the end of the day, we strive to build an environment where people feel comfortable providing constructive feedback, openly share their thoughts and questions, and provide differing solutions to improve together. As a member of our engineering team, Jake Johnson, recently put it: “When everyone respects each other, people tend to feel like they can be themselves and speak their minds.”

We praise those who give feedback early and often.

Whether it’s informally in meetings, via our Slack #thanks channel or during our weekly All-Hands, we care deeply about feedback. We put effort into being good at giving feedback: When we give feedback, we make each other feel big, not small.

Feedback is essential for effective communication and psychological safety. However, giving feedback can be difficult to do. Giving or receiving feedback can be uncomfortable and there's always a risk of triggering defensiveness if not done thoughtfully. As a result, feedback loops close and collaboration suffers on most teams as they grow. We care deeply about giving and receiving feedback in a way that makes others feel big not small.

We put a lot of energy into developing good practices at Aptible, and building a culture of feedback. We hold workshops on giving and receiving feedback. We then apply our feedback skills during weekly 1:1’s, during our All-Hands meetings (where teams present on how their work is tracking against that quarter’s OKRs), and in our everyday interactions.

We view feedback as the underpinning of our culture at Stitch Fix.

At Stitch Fix we receive feedback from our clients to help us transform the way people find what they love and feedback permeates into our work culture as well. From our monthly TINYPulse, to our self-driven, twice-yearly practice of collecting 360 degree feedback, we offer many ways to both give and receive feedback company-wide. As engineers, feedback is part of our daily practice. We create and review pull requests for every code change we make. We conduct regular retrospectives with our teams to identify what's working, call out what isn't, and suggest changes. We also hold weekly one on one meetings with our managers. We have many opportunities for feedback at Stitch Fix and we're always considering how we can work better together. We have also taken the time to outline our engineering principals, the who we are that makes us:

Practical,

• We prefer simple solutions to clever ones
• We seek to balance long-term stability with short-term necessities
• We understand and accommodate changing business priorities; we aren’t rigid
• We create great solutions to specific problems, only making them general or reusable once a pattern emerges
• We follow the shape of the existing code when possible, not refactor just to match a style we personally prefer
• We generally prefer existing solutions to creating new ones

Inclusive,

• We strive for diversity and equality; we aren’t limited to one kind of engineer
• We challenge bias in ourselves and in others; we don’t accept the status quo
• We bring others into the conversation; we don’t operate on a limited set of views
• We interpret others' remarks generously and consider how ours might be received
• We provide a high degree of flexibility in how and where we work

Resourceful,

• We are self-motivated and often self-guided; we don’t wait for direction to contribute
• We leverage what we already know to solve problems quickly
• We welcome new challenges as opportunities to learn, not obstacles to overcome
• We know when to ask others for help; we learn on our own, but we don’t spin our wheels unnecessarily

Client-Focused,

• We work directly with our users to understand their needs; we don’t operate without input
• We optimize for great customer experiences rather than ease of technical implementation
• We deliver quality work for our users, we don’t undermine their trust
• We verify our work in production; we don’t assume a system that’s similar to the real world will be the same as the real world

Iterative,

• We begin with the simplest thing that could possibly work and continuously refactor; we don't solve problems we don't yet have
• We drive our current priority to completion before starting other work; we strive to avoid multiple things things in flight
• We don't write code from a complete spec; we begin work on the pieces we understand and seek feedback
• We ship in small increments rather than only once at the end of the project
• We learn and incorporate feedback to move forward; we’re not stuck on our original assumptions

We expect feedback early and often.

There are a variety of ways in which we ensure everyone at Enigma is receiving the feedback that will help them learn and grow. A regular cadence of one-on-ones with people leads to discuss personal development and weekly standups with teammates ensures local alignment. Our performance review cycle—which centers around candid feedback from peers—is every six months, giving our engineers a holistic view of their performance throughout the year.

Feedback to leadership is also of the utmost importance—anyone at Enigma is able to questions or offer feedback to leadership anonymously, via Slack, or at all-hands meetings. We win and lose together, so we rely on one another to always be open, honest, and willing to make adjustments.

A culture of continuous feedback requires so much more than an annual review.

Of course, we still have a formal annual evaluation, but we don’t stop there. You will always be getting and giving feedback from your peers and supervisors. Every pull request is reviewed by senior team members and serves as both an excellent way to ensure quality and an opportunity to share knowledge. Code reviews help to surface the various approaches one can use and make it easy to exchange feedback on a daily basis with peers. Engineers also have ongoing one-on-one meetings with supervisors. We use Wrike, project management software, to make it incredibly easy to collaborate openly and review output.

Be candid and transparent.

Engineers give feedback on all pull requests and an approval review is required before code can go to production. We also have ad-hoc design gatherings / documents where engineers can bring up bigger initiatives they are working on (eg. moving from Heroku to AWS, integrating a new ACH provider) to get buy-in and feedback from other engineers. We pair program where appropriate, especially with junior engineers to keep everyone in sync and productive.

For meta feedback about the work, we encourage open and direct communication. We hold sessions on how to give and receive feedback constructively, and encourage it throughout all levels within the company. Our leadership team leads by example by practicing open communication with one another and the rest of the team live.

Don’t expect a manager to give you feedback at mindmatters. Instead, you’ll get and give feedback equally from everyone.

Giving feedback is core to who we are and is a big part of how we operate as a company. Our Agile coaches help facilitate open and effective feedback, and coach us to be better at giving feedback. We will also have external coaches coming in to train the entire company on how to better solicit and receive feedback. Whether it comes in the form of code reviews, retrospectives, or our monthly company-wide information exchange, feedback is at the center of how we communicate and work together.

It is a big part of our company culture. So, direct feedback is given e.g. after workshops. We work on our feedback skills in terms of coaching by our agile coach. Also, we will be having trainings with an external coach within the next months with the whole company to become even better in giving feedback.

Inherent in our collaborative nature is both giving and receiving feedback continuously.

You’ll never be in the dark about how you’re doing. All engineers have weekly 1:1 meetings with their manager, and everyone has the opportunity to give regular feedback to managers and senior staff.

Even as we've grown, we’ve all taken time to pause and help each other out with constructive criticism and guidance. We pride ourselves on having an engineering team that is both focused and fully engaged, and we emphasize giving and accepting feedback with grace and maturity. That combination empowers the rest of the team to go forth and do their best work.

Timely feedback is a cornerstone of building a cohesive team.

We believe feedback must be delivered directly, and aim to do so across all of the communication channels we use: in person, and via Slack, Github, Height, and Zoom. We provide review on every pull request, have design reviews each week, and have a weekly check-in where everyone at Compound is encouraged to bring up any issues to the group, whether about the product, the company, or anything else. We also make it clear to everyone on the team that feedback should be delivered individually at any time.

When giving feedback, we encourage everyone to:

• Be specific about not only the “what” but also the “why” - what’s the underlying reason for this piece of feedback?
• Allow the conversation to be two-way - give the recipient a chance to respond to your feedback, whether it’s positive or constructive.
• Assume good intent - and that we are all here because of our shared goals.
• Be timely - feedback is best when delivered right away.