Becoming reflective
I recently cut a deal with another team: we have spent a week reviewing their source code, and soon they will review ours.
Our first challenges are to think about the code we write, and to participate in working relationships required for the job. The second challenges are to think about how we write the code, and to participate in redesigning relationships that aren't going well. This isn't an easy transition to make. Doing a review can be an opportunity to gain deeper levels of reflection.
After we had reported to the other team, we discussed the experience. I said that it was a shame we hadn't done it a year earlier. One person replied that we couldn't have done it then, and we have matured over the last year. This was a third level of reflection: he was discussing how we think about how others code.
I'm reading "Effective Teaching and Mentoring" by Laurent Daloz. Although written in an educational setting, it is very helpful for thinking about how people make these transitions at work too, and how to help them.
Limited steps
After a release I ask for comments on ":-)" and ":-(", the good and bad aspects of what we have just done. I rather grandly refer to this as an After Action Review, although we usually just spend ten minutes on it.
A recent development cycle was rather difficult, in part becuase of a decision I took and communicated poorly. The initial comments were mutually contradictory, so I proposed we took additional discussion. After half an hour we had a deeper understanding of what had happened, and how such things can be done better in future.
I then suggested that we curate the list of recorded comments to reconcile the contradictions. However, this wasn't agreed. The team meeting preferred to move on.
People are often reflective about their work, when they have a sympathetic ear. But being willing to debate about process and relationship issues, and to accept responsibility about drawing conclusions about what we do next, is another step; one that fewer people take.