#59 - When to use different feedback models
Plus: 1:1 summary notes template; meeting kinds; tools don't matter, outcomes do; virtual internships; being an interim manager; coding interviews, boo
Hi, all!
Last issue, I left you with a couple of models for giving feedback. We had Situation-Behaviour-Impact:
“When you presented the proposed plan at the project kickoff meeting, the material you presented had a really good balance of just enough relevant context and case for the plan overview. That helped ensure the discussion afterwards was well informed and not sidetracked into irrelevant details.”
The Manager-Tools model:
“May I give you some feedback? [If yes:] When your presentations have the right background material without anything extraneous, and a good overview of next steps, that makes the whole meeting and following discussion more productive. Thanks!”
And the beginnings of a formulation from Better Bosses/Raw Signal Group:
“My expectations are…”
So when would you use each of these?
The Manager-Tools model is great for giving small, easily understandable feedback to those reporting to you. In the negative-feedback case, it ends with a second question; something along the lines of “Could you do that differently next time?” and that is all you need for something small or familiar. For something new or slightly bigger, I typically leave it more open and explicitly invite a conversation; but for tiny and routine things that’s not really necessary (and the more tiny and routine you can make a piece of feedback, the better it goes for everyone).
For peers, you’re not necessarily in a position to make a direct ask like “can you do that differently”; that’s when I use something like Situation-Behaviour-Impact. For what it’s worth, Manager Tools agrees as well with their peer feedback model, which is just behaviour-impact; I talk to my peers relatively infrequently, so it’s useful to bring up the context of the situation, although I suspect they would tell me that doing that anchors the feedback too much on what has happened in the past rather than the future. Either way it’s probably better to not wait long enough to give the feedback that you have to remind them what happened.
To my mind, a conversation that has to start with with “my expectations are” is a much bigger conversation about a serious situation (good or bad); it has the advantage of explicitly owning the expectation, but isn’t something that I’d use for routine feedback.
The roundup this week is already a bit long, so I’ll leave things here for now and next week talk about the process of starting to give feedback in these models, and then tying that into longer-term goal setting expectation communications.
But for now, the roundup!
Managing Individuals
Private 1:1 Notes Template (Google Doc) - Don Neufeld
One-on-ones are an incredibly useful tool for listening to your team members, and building up the trust so that they’ll actually tell you things. Over time you’ll learn a lot about your team members desired career development, and between those and setting and reviewing goals you’ll get good information about their strengths and gaps.
Periodically reviewing those one-on-one notes and distilling them into some key “headline” areas - and keeping those headlines updated - is an extremely useful practice. It can be useful to tie that practice into something related you’re doing periodically with the team member, like goal reviewing and goal setting.
Neufeld shows his template for what that summary document would look like, including strengths, gaps, likes and dislikes, preferred communications or feedback style, hiring date, etc.
9 Tips for Effectively Sharing Peer Feedback in the Workplace - Mara Carvello
Worth comparing this to what we discussed earlier on feedback. Carvello councils use of on-judgmental language, and focus on the problem not the individual; those are consistent with talking about behaviour and impact. Be prepared to have a conversation - makes sense when talking with peers. We’ve talked in other issues about how the “feedback sandwich” approach is known not to work; the way to “cushion” negative feedback with positive feedback isn’t to batch them in threes, it’s to be frequently giving positive feedback!
Beyond that I think the assumption behind this article is that one has feedback conversations only occasionally, a special thing you have to brace yourself for, rather than it be an ongoing part of everyday work conversations.
Managing Teams
Do We Really Need Another Meeting? The Science of Workplace Meetings - Joseph E. Mroz, Joseph A. Allen, Dana C. Verhoeven, Marissa L. Shuffler, Current Directions in Psychological Science
We should really eventually do a series on meetings. As a manager, one of our responsibilities is to keep people aligned and disseminate information. One (one!) tool available to us are meetings, which can be extremely efficient when run well and continually improved; but ugh, how many meetings have we gone to that aren’t that way?
We actually know a lot about meetings, what works and what doesn’t. Mroz et al. cover and summarize a lot of the literature. It’s a review article, so it’s hard to usefully summarize. I think it’s worth calling out a few specific things, like some purposes of meetings (it’s very hard to run a good meeting without being very clear about what the purpose is):
Share information - these can often but not always be made asynchronous
Solve problems & make decisions - lots of value to having at least the final stages of this be synchronous
Develop and implement an organizational strategy - this is a little specific, I’d reframe it as “alignment”; not just sharing information but getting everyone on the same page and committed to a direction
Debrief a team after a performance episode - a retrospective, or after-incident review, or hotwash
They also usefully highlight known facts about necessary meeting preparation steps and separate leader and attendee responsibilities - arriving on time, following an agenda, make sure attendees are participating, intervene when necessary, send out meeting minutes and action items immediately after, and revisit meeting structure and find out from team members whether they’re happy with the meetings as run.
Most of these points won’t be surprised to people who care enough about managing teams to subscribe to a newsletter on the topic, but it’s still a good short read and emphasizes something that might not be obvious - these aren’t just rules of thumb, people have been studying meetings since at least 1986 and we know what does and doesn’t work well.
Why Senior Engineers Hate Coding Interviews - Adam Storm
Storm’s piece is related to the discussion last month on hiring criteria, and matching evaluation to what people would actually be doing on the job. It’s about software development, but can be read more broadly, for any kind of work skills test (which I’m all in favour of, if they are well thought out, tightly scoped, and relevant to the real work of the job).
Senior developers spend a more time deciding what to code than doing on-the-fly coding, and putting them into a whiteboard coding interview is stressful, unfamiliar, and doesn’t measure what you care about. Storm emphasizes this point, and suggest that if you really want to see if they can code or not to give them a take-home assignment.
Project and Product Management
The Tools Don’t Matter - Ken Norton
Just a reminder that as technical folk, we tend to jump straight to tools when we’re starting to manage projects or teams for the first time. I’m flat out embarrassed by how long I spent choosing planning tools, processes, etc when I started out in my current job. It had the advantage of feeling like accomplishing something, but it was basically just stalling the harder work of managing projects, products or teams - communication.
Norton has a list of questions that should be asked differently which I’m just going to quote in their entirety:
“What tools do you recommend for roadmaps?” → “How do you communicate what’s coming in the future to internal and external audiences?”
“What tool do you use for product visions?” → “How do you motivate your team around a shared future vision?”
“What’s the best tool for tracking OKRs?” → “How do you decide and communicate what’s important to the company and what’s not?”
“Which do you recommend, Scrum or Kanban?” → “How do you decide what to build and what not to build?”
“Can you recommend a wireframing tool for sharing concepts?” → “How do you communicate early product ideas?”
Managing Your Own Career
How to Step In as an Interim Manager - Rebecca Knight, HBR
Research: Becoming a Manager Doesn’t Always Feel Like a Step Up - Nishani Bourmault and Michel Anteby
Here are two articles in HBR for new or about-to-be managers.
In the first, Knight writes about a challenging but pretty common first management (or first directorship) role in either fast-growing teams or research environments; a field “promotion”, official or not, when the original manager leaves.
Being manager of people who were just last week were your peers is genuinely a awkward-feeling situation, but it’s not as bad a situation as you might worry it is. You got the role because people thought you could do it, you already know the work going on and most of the people involved pretty well (which is a huge advantage compared to the most common alternative, being parachuted into an existing team).
Knight has good advice and a couple of case studies. One piece of advice - don’t overplay your authority, do be collaborative rather than directive - can be useful for some. There’s two opposite unsuccessful ways to deal with the sudden change in your role power as a manager of the team you were part of; overplay the “I’m the boss now” card, or underplay it - “I’m just the same team member, you know? We’re still work buddies”. Both can go pretty poorly.
If you think at some point you would like to be a manager, a good way to prepare for a situation like this is to start showing some leadership in some area of your team’s work. It will help train those skills about collaboration and direction, and it can build trust with the team so that if you are asked to take on more responsibility it won’t seem to come from nowhere.
Another advantage to taking on some earlier smaller leadership tasks is described by Bourmault and Anteby int the second article. Becoming a manger can be really discouraging. The things that many love being about an individual contributor - the hands on work, seeing direct connection to results - just don’t happen any more. The problems you are working on are quite different, bigger-picture, longer-term, and connections between what you did and what ended up happening are much more tenuous. It’s not at all unusual for new managers to feel what is described here as “the managerial blues”. That passes for many managers, but others find that the work just isn’t what they enjoy. Best to find that out as early as possible in small doses.
Random
What if an arduino, but legos? That’s what pockit.ai seems to be building.