Everyone at Sparrow is a strong communicator.

Not only is communicating critical to succeed at Sparrow, but it is required for our business to succeed as a whole. As a remote-first team, we focus a lot of attention on giving and receiving feedback. In fact, our onboarding process includes dedicated training on feedback. Nearly 75% of our ~30-person team has joined remotely since the start of COVID-19, which makes open and transparent communication fundamental to our culture.

Engineers are constantly collaborating with our Customer Operations team to create the best solutions for our end users. For this reason, we look for folks who are good at seeing other people’s points of view and are extremely self-aware. It’s important for anyone who joins our team to be able to confidently share what they know, what they don’t know, and what they need help with. This is in part why our onboarding process includes training on giving and receiving feedback. We know this one training won’t make you a pro, but we’ve found this gives everyone on our team a solid foundation and shared vocabulary. It helps us see where common problems might arise and acts as a starting point for effective communication. Continuous feedback requires constant effort, so we look for naturally strong communicators to join us at Sparrow. It makes us stronger as a team, but it also just makes life at Sparrow better!

Feedback is a gift.

At Indent, our focus is on human-centric problem solving. Whether it’s an engineer who needs access to a cloud storage bucket for 30 minutes – or the admin on the other end who needs to make sure the right people have access for the correct amount of time – our goal is to package different data privacy solutions to meet our clients’ specific needs. We want to be able to scale to the largest Fortune 500 companies and eventually also meet the needs of smaller companies like your local dental office. That’s why regular and open feedback about our product and business is so crucial to our growth. We view all forms of feedback from teammates, customers and the market, as a gift that both leads and motivates us to improve.

We’re looking for team-members who focus on the evolution of an idea to the final product, and can easily share their thoughts in real-time. In return, we promise to give consistent, candid feedback as well.

Trade-offs: We’d rather get raw feedback at the earliest stage of a project than wait to present an entirely polished end result. When receiving difficult feedback, we try to look for the productive takeaways and lessons learned for next time.

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

One of our core values is ‘obligation to speak up.’

Effective larger organizations often focus on the value of ‘obligation to dissent,’ where any member of the team, regardless of rank, is obligated to oppose a prevailing decision if s/he disagrees with it. However, in smaller growing organizations like ours, where there are many unknowns, it’s critical not only to find flaws, but also to build. Therefore, rather than ‘obligation to dissent,’ we find effective team members encourage others to ‘speak up.’

At HumanFirst, listening to all voices and perspectives – particularly when conflicting – is more important to us than achieving a harmonious decision where everyone believes the same thing. For instance, there is often healthy tension between how secure a product is and how convenient (or not) it is to use. Our team encourages opposing viewpoints and often runs test scenarios so we learn where to ‘draw the line’ when decisions are grey. We are committed to leaning into difficult conversations.

Our team at HumanFirst is both mission-driven and metrics-driven. We expect our teammates to speak up internally as well as in external settings with our customers. No one is “too junior” to share their point of view.

Our customers are some of the biggest names in the automotive industry and we regularly interface with them.

We build software that makes robots run to the best of their capabilities, solving real-world automotive manufacturing problems. We’ve programmed robots to seat torque converters in transmissions, a task which originally took multiple people, a crane, and lots of wiggling. We’ve also automated underbody waxing of cars and bolt-fastening.

Successfully solving automotive assembly line challenges requires interfacing directly with our clients, who include Nissan, Ford, and Toyota. Engineers often visit our customers’ manufacturing plants in places like Detroit and Kentucky to see firsthand the pain points they’re facing. Instead of searching for problems that fit our state-of-the-art technology, we look to our customers to get their feedback on how we can make their lives easier, increase the productivity of the factory, and enable them to build their product faster and more efficiently. Our customers’ needs drive our timelines and roadmap. This unique communication loop allows us to have a strong product-market fit and deliver solutions that wow our customers.

We foster continuous feedback internally with bi-annual performance reviews, specifically soliciting feedback from our team members. Our executive team then shares this feedback with the broader team, along with actions they’re taking to address it.

As an engineer, you can expect to be on multiple projects and have regular meetings with project leads to discuss what’s working and what needs to be improved. Regardless of your role, you’re encouraged to ping whoever you need to ask questions, get help, and move things forward.

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.

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.

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're continually gathering feedback from both our end users and our team.

Unlike many companies who have to guess at what customers are looking for, we have the unique opportunity to interface with the folks who use our software daily. We’re regularly communicating with the providers that use our platform so we can make the best product possible. Whether it’s a practice based in Seattle or Arizona, we tend to know our providers’ names and faces very well. Engineers work closely with providers to get feedback during our two-week sprint cadence, and even more so when we’re doing an alignment sprint and brainstorming what to build. In non-pandemic times, engineers visit practices around the country at least once a year to shadow our users, look over their shoulders (literally), and see first-hand how they’re using the product. During the pandemic, we’ve shifted to virtual office hours, but hope to get back on the ground as soon as it’s safe to do so.

When it comes to gathering feedback within the Chirp team, we have quarterly surveys, so engineers can provide input on our team’s leadership priorities. We’re very open about sharing the results so we can learn from them and take action. This also allows us to have several snapshots to track against instead of just one per year. That way, when it comes time for annual reviews, managers can use these multiple (more informal) check-ins to help them build a much better picture and advocate for the best results for their direct reports.

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.

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.

Asking questions and regularly gathering feedback is core to what we do.

Rune was founded with the mission of addressing questions in neuroscience and brain disease that haven't been answered. If the answers came easy, we wouldn't exist. While our engineering team is collectively familiar with much of the technology we use, there's no real blueprint past that.

Even when Rune was barely a year old and less than ten people, we instituted regularly scheduled one-on-ones and quarterly performance reviews. We wanted each person to always be clear on how they're doing, eliminate any surprises, and understand what the next step up in their career at Rune looks like. For things that affect the team, anyone can raise discussions at our engineering all-hands every two weeks. Every couple months, our company-wide retrospectives are also an opportunity for anyone to bring up what works and what doesn't at the edges of the engineering team, so our cross-department collaboration is never a source of friction.

Our development cycle is also very fast and continuous (see Continuous Delivery below). We don't have a name for it, but we've taken the concepts of fast iteration and tight feedback loops from Agile, while doing away with the ceremonies around Sprints. Outside of the engineering team, our peers in the product and neuroscience teams put everything into use right away, and let us know immediately how our work is solving problems, and what direction is next. We deploy to production daily, and use feature flags, so we can run experiments and ask early adopters for feedback before we get too far ahead of ourselves. These tight feedback loops ensure we’re building the strongest product possible.

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

We encourage team members to ask tough questions.

We place a large emphasis on feedback. We use Officevibe (mentioned previously) which sends a short survey to everyone once a week and also allows folks to leave open-ended feedback. It lets us keep a pulse on how things are going, engage team members in an easy way, and identify patterns and trends to help us improve.

Every Monday, we have a company-wide meeting, and the meeting doesn’t end until someone asks the CEO a hard question. The hard question is our exit ticket, and it always generates a lot of interesting conversations. These topics can range from challenging a business or product decision to asking about how current events are impacting the company, or being curious about company strategies.

We do performance reviews twice a year which include upward feedback – direct reports provide feedback to their managers. Our founders also take advantage of this opportunity and send out a survey to collect anonymous feedback from all employees about how they’re doing and what leadership can be doing better. We also have a Slack “Feedbackbot” that encourages us to request brief start-stop-continue feedback from anyone at the company, which drives thoughtful conversations and allows us to learn from each other.

Finally, we end every Friday with “Woah What a Week.” We celebrate team wins, give shoutouts, acknowledge birthdays and anniversaries (with shoutouts about what that person has accomplished during their time at Seesaw!). It’s a great way to kick off our weekly happy hour, which we invite significant others, family members, and friends to as well!

Feedback is an integral part of how we improve.

At Remix, there are several ways we practice continuous feedback. It starts internally with wanting to help ourselves continue to get better everyday. We ship code as often as we can and it’s a team effort. We get input from other engineers before a change gets pushed to production. We value learning and collaborating with each other and believe giving feedback shouldn’t be tough. There’s a deep level of trust and respect for one another, which enables us to provide feedback that’s direct, honest, quick, and genuine. We do our best to take into consideration how team members prefer to receive feedback (something you can share in your user guide), whether that’s via direct message in Slack, in the moment, or a shared channel.

Creating tighter feedback loops also extends to how we interact with our customers. Before starting new projects we have a user discovery call to understand where we can help our customers improve their workflows. Whether customers share feedback in emails, calls, or in-person, we make sure to document it in a Slack channel so the entire company has visibility. This helps us define our roadmap, quickly squash bugs, and iterate on features. We also give a subset of our customers early access so they can beta test our new tools and help us develop the final product before it is released to General Access.

Our customers’ wins are our wins. Placing a large emphasis on open lines of communication with each other and with our customers ensures what we’re building has the intended effect and is the strongest product possible.

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

To be better, you must have a growth mindset and the humility and openness to learn from others.

We view feedback as a gift. It allows us to both collectively and individually become better, and it is the foundation for how we continually grow. At a company level, we run quarterly pulse surveys to measure the overall engagement and health of our business and teams. From there, leadership takes measurable actions to improve the employee experience whether it’s around work-life balance, diversity & inclusion, or needing additional resources to be more productive.

At the team level, we do regular feedback check-ins which include 360 feedback. This feedback is used to help employees understand their strengths and identify opportunities, both of which are then incorporated into their growth plans. These plans are a collaborative effort between you and your manager.

Less formally, feedback is frequently requested at various team meetings and 1-on-1’s led by each level of the management chain. We can better understand how employees are feeling about their work and gauge the overall happiness of our teams by frequently soliciting feedback. Healthy teams are important to the success of the company and the insights our employees provide is invaluable!

Every week, we also have an incident review session where teams share postmortems from issues affecting the company (e.g. product downtime). Engineers from across the company are invited to join and share in the learnings. It serves as a great way to understand the intricacies of our technology stack and where our systems are being pushed to their limits. In these sessions, an emphasis is placed on being blameless and we focus on the process changes needed to improve in the future.

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 (and more recently made the shift to being fully remote), 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.

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.

Strive for constant input from our community, our teammates, and ourselves.

Something that separates great teams from others is an ability to honestly confront reality, rather than see the world as we – with our own biases and hopes – want it to look. One of our core principles is “Be honest, especially when it’s hard, especially with ourselves.” This is especially important in emerging tech, as we have to ensure a careful balance between serving our customers today and building for the technology of tomorrow.

Continuous feedback is apparent on so many dimensions on our team. Engineers get constant peer feedback through spec and code reviews, and bi-weekly sessions to dive into deeper long-term topics in a collaborative, workshopping setting. Feedback Fridays give us each a chance to get feedback from our teammates to keep improving ourselves. Bi-weekly community calls are focused on feedback from the community, and one of the most common questions we ask even our very happiest developers is “what could have been better?” We are constantly seeking their feedback and input.