I'm a tester (whenever it suits me) and as testers, we specialize in feedback. Good feedback is true and timely, and while we think of feedback as the things people turn into words, a lot of times it ends up being non-verbal.
We look at an application for the purposes of testing, waiting for it to "whisper" where it has problems. The application is my external imagination and all I need is to give it a chance to tell me the very quiet messages that I can then amplify. I need to be ready to listen to multiple narratives:
Similarly as people give feedback on quality of applications, sometimes we need to venture to an even harder side, giving feedback on the quality of the people producing our applications. It is easier to look at an artifact and describe its features we appreciate and don't than to do the same for our colleagues.
When it comes time for saying something about our colleagues, I find that we discover a human feature of conflict-avoidance. Leaving things unsaid is a choice many of us make. Making choices of when to say and when not is something every one of us needs to learn.
As peers, we are asked to give feedback, but in case of a potential conflict, as peers we can more easily step away, say that continuing as if it isn't *that big a problem*. What I'm learning is that this is one of the many reasons organizations task managers to deal with small problems before they grow big.
Telling someone they should shape up their game isn't easy. It makes me feel awful, especially when it turns out to be a piece of feedback that may be hard for the receiving party. But all I do is turn something they're not paying attention to, something bubbling under, into words with the hope that through seeing it, you could do something.
When your pull requests get very little feedback, you could think of it as absence of errors, or what it truly is, absence of feedback. Why aren't you getting feedback?
When your colleagues don't complain about your work, that could be absence of errors, or absence of feedback?
What can you do to get to the absent feedback? And don't tell me "get a manager who turns it visible for you, as a service" and start servicing yourself. Feedback is the lifeline to improvement and absence of it is a road to stagnation.
The idea of turning implicit to explicit, invisible to visible and abstract to concrete could well be my tester guideline of what to do, I grow uncomfortable in providing this as a service while manager. It's something everyone needs to learn to do for themselves, and for their peers.
We look at an application for the purposes of testing, waiting for it to "whisper" where it has problems. The application is my external imagination and all I need is to give it a chance to tell me the very quiet messages that I can then amplify. I need to be ready to listen to multiple narratives:
- does it do what we intend and reasonably expect it to do?
- does it have adverse side effects to anything we care about?
- does it cause someone problems, either now or when trying to keep it running in production?
Similarly as people give feedback on quality of applications, sometimes we need to venture to an even harder side, giving feedback on the quality of the people producing our applications. It is easier to look at an artifact and describe its features we appreciate and don't than to do the same for our colleagues.
When it comes time for saying something about our colleagues, I find that we discover a human feature of conflict-avoidance. Leaving things unsaid is a choice many of us make. Making choices of when to say and when not is something every one of us needs to learn.
As peers, we are asked to give feedback, but in case of a potential conflict, as peers we can more easily step away, say that continuing as if it isn't *that big a problem*. What I'm learning is that this is one of the many reasons organizations task managers to deal with small problems before they grow big.
Telling someone they should shape up their game isn't easy. It makes me feel awful, especially when it turns out to be a piece of feedback that may be hard for the receiving party. But all I do is turn something they're not paying attention to, something bubbling under, into words with the hope that through seeing it, you could do something.
When your pull requests get very little feedback, you could think of it as absence of errors, or what it truly is, absence of feedback. Why aren't you getting feedback?
When your colleagues don't complain about your work, that could be absence of errors, or absence of feedback?
What can you do to get to the absent feedback? And don't tell me "get a manager who turns it visible for you, as a service" and start servicing yourself. Feedback is the lifeline to improvement and absence of it is a road to stagnation.
The idea of turning implicit to explicit, invisible to visible and abstract to concrete could well be my tester guideline of what to do, I grow uncomfortable in providing this as a service while manager. It's something everyone needs to learn to do for themselves, and for their peers.
