#47 - 18 Dec 2020
No triangulated feedback; self-review; tech lead manager roles are a trap; collaboration agreements
Congratulations, everyone; we did it.
2020 is now or is soon to be officially at a close for some of us. For the rest of us, while there is some work remaining to be done, things are winding down. We made it to the end of 20-frickin’-20.
I started this newsletter together with you in January, which seems like a decade ago. It’s been a hard year for our teams, and a hard year for managers. We’ve had to keep things together and moving with the world falling apart; help team members through incredibly tough times and keep the research and researchers who depend on us going.
We’ve done incredible work, and because of what we’ve done as managers our teams are going to come out in late 2021 stronger than when this started. The trust we’ve built with our teams by seeing them through the tough times will make the team work even better together. Our improving and making more intentional our team communications, necessary for the abrupt move to all-distributed, will be of benefit in the years to come. Our upping our management and prioritization skills will help our team through whatever future challenges come our way.
I’ve learned a lot writing this, and I hope it’s been helpful to you to read this over the past year. Over 100 of you have subscribed and stayed subscribed through some mis-steps and mis-fires, and I appreciate it and your feedback. From your feedback I’ve learned:
Almost all of us were flung into management without any sort of preparation
Technical teams are awash in technical information but almost nothing about any of the other aspects of running our teams, providing service to our stakeholders, or advancing our own careers
Organizations are still trying to figure out how to organize technical teams in their institution - centralized, embedded, distributed, or some combination thereof, and business models for same are even more confused
Hearing each others questions during Ask Managers Anything was really popular, and we’ll revisit that next year
I think we all more than deserve a couple of weeks worth of rest. I’ll be back January 8th, recharged and ready, and I hope you will be too.
And now, without further ado, the last link roundup of 2020!
Managing Teams
Say “No” to Triangulated Feedback - Esther Derby
This one hits a little close to home this week.
Derby’s article talks about the perils of “triangulated” feedback - team member A tells you something about team member B and you bring it to team member B. A team is a group of people who are accountable to each other in working to a common goal. By being a cut-out in these accountability conversations we short circuit these needed conversations, eroding trust, and give ourselves a bunch of worse-than-meaningless busywork to boot.
The reason this hits home is last week I actively made a situation between two team members significantly worse by interjecting myself too soon and too forcefully. I felt like I was doing the right thing - my intense personal preference is to avoid these situations, so taking decisive and immediate action “seemed” right to me - but it absolutely was not. In this particular situation, monitoring and checking in after a day or so would have worked much better. To be clear, being completely uninvolved is not a solution either, but we can’t be a first- or even second-choice option for dealing with between-team-member conflicts except in extraordinary circumstances.
Why Capable People Are Reluctant to Lead - Chen Zhang, Jennifer D. Nahrgang, Susan J. Ashford, and D. Scott DeRue, HBR
In a study of 400 MBA students, three risks held people back from stepping up to lead, in projects or in taking decisive action:
Interpersonal - risking friendship/collegial relationships
Image - “I don’t want to seem like a know-it-all”
Accountability - “I’ll be blamed for bad results”
As we try to make sure our team members have growth opportunities, and increase their scope by giving them more responsibility and project to manage, these are the key concerns they are likely to have (or, frankly, we are likely to have as we grow in our careers). To mitigate this, the authors suggest
Go the extra mile to support risk-sensitive team members
Manage conflict, and treat respectful conflict when it happens not as a catastrophe but a normal part of humans working together on things they care about
Give (or take!) increasing responsibility in small manageable increments
Managing Your Own Career
Writing a Performance Self Review for Software Engineers - With an Example - Gergely Orosz
Orosz writes this in the context of getting ready for a performance review by your boss. Many of us don’t have such reviews in any meaningful way. But this is a terrific process to go through every quarter or so, for yourself and for your team as a whole. It’ll help you communicate your value to your boss, yes, but also your teams value to your organization, and other stakeholders; it’ll help you focus on the positive accomplishments and identify areas for improvement; and, more or less for free, it’ll help you keep your resume up to date for that next opportunity.
Orosz suggests focussing on:
Goals/expectations for the period ahead, and comparing to those from the period behind
List your accomplishments (if you do this in succinct bullet points they also become items you can put on your evolving resume and LinkedIn page)
Talk about the “how” - how you work with people, examples of helping people/teams, etc.
Reflect on competencies
Tech Lead Management roles are a trap. - Will Larson
When I was asked at my SORSE talk if it was possible to be both lead developer and manager, I replied that anything was possible but it is really, really hard. The most stressed I’ve been in the last couple of years was when I’ve had both significant technical and managerial responsibilities - they are completely different skillsets requiring your mind to be in different kinds of places. Bouncing between the two is definitely playing the game in hard mode.
Larson agrees, especially for new managers:
The reality is that when you’re trying to learn something brand new, like team management in this case, you’re almost always going to be better off getting to focus on that area.
Collaborating with Someone You Don’t Really Know - Rebecca Zucker, HBR
Starting projects with other teams is pretty common for many of us. Zucker suggests clarifying things right from the start - these conversations can be a bit awkward but go way easier at the start of a working relationship. The good news is that I think our experience as managers makes it simpler:
What are our goals and process for this project?
Who will do what, and by when?
What are our individual preferred working styles and strengths?
When and how will we give each other feedback on our working relationship?
What do we need from each other to do our best work?
I honestly think I wouldn’t have been able to answer my part of the last three questions clearly before having worked as a manager for a while. It’s only been since I’ve been working with colleagues with very different working styles, and making it my job to understand and accommodate those working styles, that I can actually recognize my own.