Ask HN: How do you do feedback within your team?

I'm at a startup with a small handful of engineers. We periodically give feedback, but I feel there is more left on the table that could help us to grow faster individually and as a company simply because we don't think about it often enough.

We are talking about it together as a company, but I'm interested in learning from everyone here.

How do you do feedback? What works well? What doesn't?

24 points | by camhart 2246 days ago

9 comments

  • fab1an 2246 days ago
    No framework, but I'd very much recommend reading up on "Difficult Conversations"[1], which has been very helpful for me ever since becoming CEO.

    Giving feedback, more often than not, will constitute a difficult conversation, and the concept helps a lot with navigating those in a way where both parties can learn and grow from both emotional and 'semantic' conflicts.

    [1] https://www.amazon.de/Difficult-Conversations-Discuss-What-M... Brief summary here: http://www.fscanada.org/wp-content/uploads/2013/12/Difficult...

  • ndh2 2246 days ago
    What is your role within the company?

    Beware of the Halo effect [1]. For example, people are biased towards their first and last impression. That's why you/everyone should write stuff down regularly, so you can at least try to offer more objective and balanced feedback, and not just on the first thing that comes to mind.

    I would recommend the book "Managing Humans", which originated from a blog [2]. It has good content on how to talk to people, and which mistakes to look out for. I found it quite entertaining. I believe you can read all content online.

    [1] https://en.wikipedia.org/wiki/Halo_effect [2] http://randsinrepose.com/archives/youre-not-listening/

    • camhart 2246 days ago
      I'm an engineer. Fairly flat organization for now.

      Love the thoughts on Halo effect. I also feel like other peoples perception, if communicated publicly, biases everyone to that same perception of someone.

      I'll take a look at the blog post/book.

    • camhart 2246 days ago
      The blog post is good. I like the focus on listening well and using silence to extract the bits you don't know how to extract.

      "If they don’t trust you, they aren’t going to say shit." is great too.

      I feel like the blog post is geared towards 1 on 1's. I like 1 on 1's but I feel they're only one part of how feedback can be given.

      My original thoughts, which I didn't describe clearly, are more geared towards creating a culture/environment where feedback is given and received in a respectful, mature, productive, and continuous way.

  • ochronus 2246 days ago
    What ndh2 said, plus: Building a good feedback culture is not easy but starting out with a handful of ppl is the best time for it :) Make it part of the everyday culture. Random example: when an engineer praises someone on your 1on1 with her tell her to give this praise to that person as well. The same goes for complaining.

    There are usually two hard parts: 1. People love to complain but usually never directly to the person they're complaining about. As a manager you need to kindly direct their feedback and teach them to talk to each other. 2. People suck at giving useful feedback. They generalize, they talk about personality traits instead of specific examples and their feedback is usually not actionable.

    What worked well for me so far is the situation-behavior-impact framework. This helps the feedback giver be more objective and actionable. Also, when you want someone to change their behavior it's important that they should come up with a plan. You just give the framework to it.

    If you're worried about the frequency use some triggers. Random ideas: end of sprints, end of projects.

  • mrlyc 2246 days ago
    Peer review of code and documentation works well. It can be formal or informal. After I was unexpectedly put in charge of a three-person programming team 32 years ago, I started giving my code to another programmer to look at before it shipped. I hadn't heard of peer review so I called it the "Will you have a look at this?" system. That became the norm in the team.

    Later on, at another company, we had formal meetings to do the peer reviews with software to document the results. The meetings could be brutal. I remember submitting about 1,000 lines for review, which was a bit long, and the only thing the reviewers found wrong was that one line had "while(something)" instead of "while (something)". They kept going on and on about it. I did get an exemption from having the rest of my code reviewed, though.

  • 0x54MUR41 2246 days ago
    In my current team, we use 360 feedback to review each other. This review happens two times a month. The feedback contains what principles and improvements. This system works well for our team because we have 1-on-1 with our coach. The coach will review from the feedback. Beside that, this system feedback doesn't work well at first pilot because my team doesn't like write a feedback manually. After first pilot, the feedback system moves from written manually to online document.
  • Sjamilla 2246 days ago
    I suggest reading this book: https://www.radicalcandor.com/

    Personally, I give and ask for feedback on a regular base to a person I worked with in a period of time. I'll send them a mail asking: looking at the past two weeks, what did I do well? And where could I improve?

  • theodorewiles 2246 days ago
    https://www.manager-tools.com

    They just did a series on performance review systems.

  • davismwfl 2246 days ago
    If your team is < 10 people, stop worrying about it and just talk to everyone regularly and openly. The two most important parts of talking though is listening and objective openness (don't be closed off). And when I say listening, don't just hear what someone says, act upon it or tell them why you aren't (even if you take a few days to research and get back to them). This solves 99% of issues when the company is small. And this should be encouraged across the team to happen, e.g. person to person, not just founder to team. BTW -- this works well with advisors and investors too, if they tell you something, research, act and respond so they know even if you went a different direction you did so informed.

    > 10 < 25 people and really anything over 15ish people gets harder to manage so you need some formality to it, e.g. schedule and documentation. But don't try to make some great review/feedback system initially. Just set aside more time, talk to people, listen, keep good notes and formalize the process with documentation and scheduled follow up. This is also the time that if you haven't already you should expand the loop where there isn't just one person doing most of the feedback cycle.

    > 25 < 50, you absolutely need some formalization and you need to delegate feedback cycles to team leads, or trusted individuals and the founders need to work closely with those leads to make sure they are staying in the loop. For every team < ~10 people have the team lead follow the first version, just with solid documentation and follow up that they are taking care of their teams. If you are a founder/director etc level start reducing your daily influence with team activities so that the team starts to depend more on the lead, this isn't because you are pulling away or inaccessible, but you need to give space for the team to form around the immediate leadership and not just you. If you don't do this, you will fail as a leader and you will cause all your direct reports to fail over time.

    > 50 you should by now have hired at least one (possibly a few) dedicated HR staff who can help formalize the process more and grow it sustainably. Usually, I'd recommend this around 35-40 people as you just can't deal with everyone's issues. But over 50 it is really mandatory as the laws generally change as to your employee responsibilities etc.

    This is different than some of the other answers, but hopefully gives some insight. Also if you follow this generally the culture revolves around solid constant, quality feedback so it will just be instilled from very early on. Which is really helpful as you grow.

    One last point, this works great with knowledge workers and most business types. If you are leading manufacturing, day labor or unions than things change as the personalities and needs are different. Doesn't make either better or worse, you just have to respect that they are different and have different needs.

  • andrei_says_ 2246 days ago
    - what worked?

    - what could be better?

    Using descriptive terms.