Providing feedback to developers - what and how?

[iteles]

There is a general consensus that receiving feedback is important for morale and development as well as [increasing self-awareness] which in turn should improve a person's character/actions.

Currently the means of feedback to developers in dwyl are:

• Code reviews on pull requested code
• Sprint retrospectives (for client projects)

We need to implement more consistent ways of providing constructive feedback so that everyone has the opportunity to learn and grow from it.

• 1. Understand what kind of feedback is required
  • Who from?
  • What kinds of questions?
  • Qualitative vs quantitative
• 2. Implement feedback collection mechanism
• 3. Determine feedback delivery mechanism - who delivers it (if a person) and what are the guidelines for this?

[ghost]

@iteles

1. Are we sure feedback should be anonymous? Might be some good arguments for it to be open/attributed.

2. If it is anonymous it's quite simple to do this via a google form

[iteles]

@markwilliamfirth I would suggest anonymous with an optional name - if you're collecting feedback on a person's colleague, they might be unwilling to be fully transparent if they are named.
For now, I don't think trolling is an issue.

Happy to hear thoughts on why the anonymous option shouldn't be given!

[ghost]

I've been recommended by a few people to read this but haven't got round to it yet. @nelsonic maybe one you might be interested in too. Delves into the importance of being upfront and discussing things openly and honestly in business. Different approach, not sure if it's the best, but it's an interesting idea we could think about.

[iteles]

Happy to try it!

[iteles]

@markwilliamfirth Is this captured somewhere else?
This was one of the things I mentioned as one of the most important tasks when you joined a few months ago but I don't think it has been established yet. Unsure what the update is here?

[ghost]

@iteles I was closing because of the feedback app that's been created by Jack

[iteles]

@markwilliamfirth That doesn't solve the problem of providing feedback to developers working on our teams, we need to actually do a little study to understand what would be useful, who it would be useful from and how it needs to be delivered.

[nelsonic]

Failing to capture the feedback of people working on our team(s) is a recipe for failure.
Making people feel loved, cared for and listened to is essential.
If anyone is not doing what they love,
we should be helping them to find exactly what they are passionate about,
even if it means "losing" lovely people.

The question we should be asking is, how can we use the Feedback app created by @jackcarlisle
to ask a specific question and send out an anonymous feedback form to everyone ASAP?

[Cleop]

The book Time, Talent, Energy (Nelson has a copy if anyone wants to read it) says:

• Don't focus feedback during salary reviews.
  Feedback is valuable and if an employee is focussed on negotiating their salary it loses the valuable opportunity for ideas to be shared as an employee might feel defensive towards criticism if they fear it may effect their salary.
  A mentor told me:
• Get feedback consistently, the more often the better. If you get feedback only after big deadlines or events then you will fear it and find it hard to accept. Small chunks little and often make it easier to digest and apply at the time rather than when you've lost the context you were working in. Feedback shouldn't be a big deal, it should be routine.

Personally I feel dwyl's existing feedback mechanisms potentially lack personal feedback a bit (perhaps this is intentional?) Ie. code reviews is about the code and sprint retros often talk about 'how the time was used'. Maybe I think about personal feedback because it's what institutionally I'm used to and I'm not sure if it's actually good for you/helpful. I'd be interested to know what other people think?