I started Steven Pinker’s new book Rationality recently and was immersed in cognitive biases and fallacies for a couple of days. I didn’t finish it but one might say I was primed to appreciate an HBR article on employee feedback that appeared in my information flow. It struck a number of chords and I think it’s relevant for law library leaders. Since we rise up from a knowledge domain that we then manage, we may forget that our own expertise – and ability to give certain types of feedback – alters over time.
I liked Rationality but it was a slow read for me, it was a limited availability title, and I frankly needed more time to digest than the loan allowed. Also, lots of pages full of matrices on logic. It’s a hard slog on a small device.
Feedback and recognition are so important and can go hand in hand. But feedback is an area that I’ve found it’s better to discard what you’re told and focus on what works. For example, the feedback sandwich is something I don’t do even though it comes up in a lot of leadership training. Since you will be receiving feedback yourself, you can identify what you find helpful and isn’t, and then use that learning in feedback you are giving out.
One reason I found the Harvard Business Review article useful is that it is a bit like pulling your car off the road during a long trip. While you’re on the go, you’re continually adapting and correcting course. But sometimes you need to stop, step out and stretch a bit, and pull all those adaptations together.
Feedback and Expertise
I find expertise fascinating. It may be because, having gone to law school, one is accustomed to the law degree conferring a sense of know-all-ism on its recipients. The unwillingness to say “I don’t know” leads lawyers into practice areas where they’re unfamiliar and incompetent, and researchers into tunnel vision in their approach.
Sometimes we see experts pushing beyond what they know and are asked to guess what might come to be. It doesn’t go well.
Most law library leaders have come up through one of the knowledge domains within the library. We often hear of the outliers (Canada, Phillippines, Library of Congress) but there’s no real reason a library leader has to have been a librarian. Leadership is a different knowledge domain and a curious leader with some humility can bring missing expertise.
If you have don’t have expertise in the area in which you’re providing feedback, you may experience illusory superiority, where people with low expertise overestimate their knowledge. Sometimes role or prestige reasons can cause someone to pretend to be more knowledgeable than they are.
Between writing this post and publishing it, I read David McRaney’s You Are Not So Smart. It’s a very readable look at a couple of dozen cognitive biases. In particular, the method of describing each one with context brings them to life – so you can imagine yourself falling for them – in ways that are helpful.
Alternatively, experts can have blindspots due to their unconscious competence. Someone may have made different choices in a knowledge domain in which you’re an expert. You may need to dig to understand why they made those choices, and not judge them just on your own analysis and expertise.
Positive feedback should be the most straight forward. I think it’s not as frequent as it could be, because we ignore things that go right on a regular basis. It still needs to be authentic, though.
I had one manager who would be talking about one team’s success and would then try to include everyone else (“and your team’s X, and your team’s Y”). But it (a) wasn’t necessary, (b) wasn’t the time since another team deserved its focus, and (c) didn’t feel authentic. If you feel as though you’re not giving out enough positive feedback, it’s easy to fix. “Thank you”; “nice job!” Send an email to a supervisor, cc’d to the staff person or team, outlining what a great job they were doing in a specific instance.
Then there’s the other feedback. I started to type negative but it doesn’t have to be, in the sense of punitive. As with the feedback sandwich, when feedback is viewed as negative, it can create anxiety that isn’t going to improve performance. People start to adapt to avoid the negative feedback. That doesn’t mean they are doing better work, just work that avoids getting them in the soup.
Even the use of positive and negative seems more like the feedback is a judgment: you did well, you did poorly. If it’s just input and feedback is just part of a loop (not necessarily good or bad), then it can be an opportunity to for everyone involved to grow.
I try really hard to keep any of my own expertise at bay when I’m giving feedback. Especially on the technology side, it can be hard to avoid sticking in your oar. But I always remember one person I worked with – hierarchically senior to me – who read a personal technology column in a newspaper. I would dread Thursdays, when I would get an email suggesting some new technology adoption, pulled context-free from thin air. Talk about illusory expertise.
Feedback opportunities are often fleeting unless you do a lot of project-type work. It may be more difficult to provide feedback on a small issue that doesn’t come across as merely corrective. It takes some time to talk though “what else have you tried” rather than “try this.”
The feedback that I’ve received that has been most useful has involved open-ended questions, whether the outcome was what was hoped for or not. This allows the recipient – and subject matter expert – to start to provide the context, rather than assuming facts not in evidence. That gives the person getting the feedback an opportunity to talk through what worked and what didn’t. Sometimes asking “what do you think will happen” after a success comes up with some new opportunities or directions.
An investigative approach can help to show gaps that – even when a project is successfully completed – will need to be filled for it to stay successful. Or that, even with a success, we’re not getting the result we hoped for and so we should sunset the effort.
Surprising no-one, I also use stories, both when giving feedback and when receiving it. Stories can be helpful ways to share how other people have tried similar things or that you have considered other approaches. Stories can also share expertise in a way that causes people to think about what they do or don’t know. Not infrequently, I’ll start a story and it will highlight things that wouldn’t work in this newer, different context!
Feedback is a tricky thing. I think it’s trickier if you worked in a knowledge domain – like law libraries – that is full of expertise, and then move to a supervisory role. A person giving feedback doesn’t necessarily know what the person receiving it knows. That ambiguity can be hard to take on board but the discomfort it causes initially goes away!