Feedback type: Speed, Quality or Priority

I heard this tiny episode by Developer Tea on Spotify on giving feedback.

The point of the feedback is to say: Things are one way – your actions are producing this outcome; and we want to move to a different type of outcome.

OK… That’s clearly phrased, thank you. Then they go on to have a take on Start/Stop/Continue that I liked:

Most conversations we have about teams, can be boiled down to 3 fundamental attributes of the teams work

• The amount of work being done
• The quality of work being done
• Whether the work done aligns with our priorities

What I liked about the take it how it takes both blame and effort out of the feedback, by removing the idea of wrong or right/bad or good work. Instead, I choose to interpret it as which of these aspects are a priority at the moment.

1. The amount of work (Quantity)

Quantity: we need to move faster, deliver more things. (Continue)

By stating this, we acknowledge that we’re in a state where speed is important. It can be a deadline coming up or runway getting short. State that you are prepared that this may lead to narrower features or less quality, and that’s ok. If that becomes a problem down the line, one can reconsider a different approach.

2. The quality of work (Quality)

Quality: less bugs, more thought into features. (Start)

Are customers complaining about bugs or instability? State that we need to improve our quality of work and that you acknowledge that it’ll likely lead to less speed.

Rather than a general feedback, I would personally bring up X number of bugs or a handful of semibroken features that needs to be fixed. I think the person or team you give the feedback are likely to improve quality in the future as well, because they want to avoid this type of cleanup period. If they don’t, you go another round with new bugs/features. If they overdo it, you go another round (later) with the opposite feedback.

3. Alignment with startegy

Alignment: We are not doing the right things. (Stop)

Maybe they are down a rabbit hole with the complexity of a new calendar feature. Midway, insurance integration became a requirement for a large new customer. So that calendar thing might have been correct to work on when they started, but things have changed. Give reason to why we need to do a, b and c instead, and need to drop x, y and z (at least for now).

Examples of feedback

Often, the feedback has a time component. You may have to produce a lot of features in a short time, but quality isn’t important (#contracts). Or the opposite: there’s a calm period before christmas, so now is the time to improve the stability of calendar availability.

For instance, you may have to priotize Alignment, and say

We have a deadline 1st of August and need to align towards [that insurance feature] that needs to be ready then. I therefore wish that you stop doing [unrelated things] for now. I acknowledge the importance of what you are doing at the moment, and want to revisit that after we’ve delivered [the insurance thing].

Or you may have to prioritize Quantity and say

There is a lot of features in the pipeline that we consider necessary prior to launch our landing page in England. We need to just get those out the door as fast as possible, so I want you to prioritize Quantity. I suggest you cut corners where you feel it’s OK to do so, and acknowledge that it likely means an increased amount of bugs. I know life will suck for support the next couple of months. That’s unfortunately something we’ll have to live with for now, but I promise we’ll revisit these features to polish them and ensure they work for edge cases afterwards.