#10 - Link Roundup, 3 Apr 2020
Why being a manager is terrible; Sugarcoating feedback; 1:1s; Postmortems; Effective Writing; Getting in the Room
Managing Teams
Why being a manager is terrible…and wonderful - Scott Williams, Zapier
All of the research computing managers I know are very very tired right now. It’s ok to recognize that it’s tough managing even at the best of times, but we should also take the time to recognize that our teams are doing pretty well now and to take some pleasure in that as we enter the weekend.
Are You Sugarcoating Your Feedback Without Realizing It? - Michael Schaerer, Roderick Swaab, HBR
We have to work harder to keep connected with our remote teams now, but that doesn’t mean we stop giving corrective feedback about things that aren’t going well. In fact there’s probably a lot of new expectations about “how we do things”, and there’ll have to be a lot of nudges to get people on the right path.
This article talks about one problem that people have giving positive but especially negative feedback; the “illusion of transparency”. Put simply, people can’t see into your head, and (a) the thing you’re giving feedback about isn’t as clear to your team member as it is to you, who have spent much longer observing and thinking about it, and (b) what you’re trying to communicate the team member may be very clear to you and much less clear to them.
I’m really bad at this, particularly when I’m trying to not be overly negative about something or trying to steer away from being very prescriptive: I often say things that are utterly clear to me but leave people on our team with a lot of questions.
The best way to make sure you’re communicating what you think you are communicating is just to ask! But even just remembering that what you’re seeing isn’t necessarily as obvious to your team members is enough to help us be clearer:
Before the review, we told one group of the managers that the evaluations would not be evident to the employees, and that the employees would be unlikely to see the evaluation the same way as the managers. We found that the managers who were given this warning delivered much more accurate feedback than the others — the gap between the perceptions of the evaluation disappeared.
Managers, Take Your 1:1s to the Next Level with These 6 Must Reads - First Round Review
I’m pleased so many people have read the webpage or ebook version of the One-on-one quickstart; hopefully it’s been useful. Once you’re familiar with them, or for people who have already been doing them for a while and are looking for things to improve, this blog post lists six very useful things to read to add to your one-on-one toolbox:
Deflect common 1-on-1 “types” into more productive directions
Have some very large scale themes that you probe into
Dig into problems, not symptoms
Stay specific, but be empathetic
Keep notes and follow up
Deliver on your actions and make sure the one-on-ones are useful
Most of the suggested reads have helpful questions to ask to help shape the conversation in the way you’re looking to have it go, and those question lists can be useful to keep handy.
5 Best Practices on Nailing Postmortems - Hannah Culver, Blameless
We’ve started doing incident reports - sort of baby postmortems - in our project, which has been an extremely useful practice in growing more discipline about how issues with availability or security are reported, distributed, and dealt with. It also gives us a library of materials that we can look through to identify any patterns that appear.
This article talks about some best practices for running postmortem processes –
Use visuals
Be a historian - use timelines, but sparingly
Publish promptly - the faster, the more accurate the recollections
Be blameless:
People are not points of failure.
Everyone on the team is working with good intentions.
Failure will happen.
Tell a story
I think we’re pretty good with the blameless/tell a story parts in our incident but the prompt publishing has been a problem - we still need to improve the process, and right now I’m a huge bottleneck - and we’re not using visuals just yet.
Product Management
Google’s Technical Writing Courses - Google
Some of us, particularly those of us who were trained in engineering departments, got technical writing training — but most of us didn’t, and the training we did get was focussed more on reserach papers (which let’s face it is a terrible model for almost any other form of writing besides research papers).
Google has made available two of their internal courses on technical writing. The first course is sort of “Strunk and White for people who work with computers”, which to be clear is a good thing - it focusses on short clear sentences in the active voice, considering your audience, and good paragraphs. The second course focusses more on the organization, drafting, and rewriting of larger documents.
The pre-course materials are available at the link above; the course materials themselves and facilitation guides are available upon registration to their technical writer instruction community. This would be of interest to many of us individually, but also to arrange courses within our own teams or to our broader communities. The course is set up to be taught by people who are roughly peers — you don’t need extraordinary expertise in technical writing to facilitate the course well if you follow the materials. There are also links to external resources.
Design Docs, Markdown, and Git - Caitie McCaffrey
Azure Sphere Security Services used a Word/Sharepoint workflow for drafting, circulating, refining, and approving design documents wasn’t working, so they trialed a move to using markdown and git for their design documents. It was a success, and here they write up their approach.
Not every design document corresponds to just on repository’s worth of code, so they chose to have one single repo for design documents for their organization organization, to support discoverability and large/unconstrained multi-codebase architectural designs.
They used standard github comments for discussion, and pull requests with formal lists of approvers for making changes. Although not every PR requires significant discussion, when they do, review meeting invitations are sent around with a link to the specific pull request being discussed.
One of the biggest benefits I’ve observed is the clarity it has brought to how decisions are made, and durably recording when things are done. On a fast growing team like Azure Sphere having clarity and durable communication are key to successfully scaling the business and the team.
Getting in the room - Will Larson
One problem we sometimes have, when “managing up” within our organization, or trying to work with research communities, is the struggle to be in the right room when decisions are being made. Research computing staff, being a supporting role, can often be an afterthought (if thought of at all) when making plans, funding decisions, or setting strategy — with the end result that sometimes decisions are made which are unimplementable, or implementable only with great difficulty, when it comes time to build technical solutions.
This article describes what you need to get into those rooms:
To bring something useful to bring to the room…
…that the room doesn’t already have.
A sponsor in the room.
Stay aligned with your manager.
Optimize for the group.
Speak clearly and concisely.
Be low friction.
Come prepared.
And now to avoid being removed from the because of:
Misunderstanding the room’s purpose.
Being dogmatic.
Withholding consent.
Embarrassing your sponsor.
It’s also important to know when to leave the room — there are a lot of rooms, you can’t be anywhere, and you have to focus your energies where you can do the best good.
Don’t Just Throw Together a Webinar — The Virtual Events Crash Course You Need - First Round Review
Have a virtual event early, have a virtual event often - this article suggests that if you are thinking of starting a virtual event, you should aim high, put more thought into what you can enable with the technology than just a video of someone presenting slides, experiment with those formats, and keep learning from what you try.
Random
The ACM Digital Library is now free and open until the end of June. This is a very useful set of resources.
The presentation Software Engineering Advice from Building Large-Scale Distributed Systems by Jeff Dean at google is circulating around again, and it’s always worth it to take the time to flip through it. The emphasis on Fermi calculations with realistic architectural numbers should be familiar to those with physical science research backgrounds, and it’s a great overview of how to think about these architectural questions from someone who’s thought about a lot of them.
On the more pure math side, I’m not quite sure how to describe the new free book A Singular Mathematical Promenade by Étienne Ghys. Martin Gardner’s old “Mathematical Games” column paired with Gödel, Escher, Bach and a survey graduate course in Mathematics?
Thinking of taking on a new side project? This roundup of Open source, experimental, and tiny tools roundup for game or interactive development contains lots of cute, weird, and interesting small tools to help you get started.
As we build web applications with richer capabilities for data analysis, it starts to make more sense to push computation to the client. Emscripten has long allowed the cross-compilation of compiled C code to Webassembly which allows high performance code execution in the browser, but LLVM’s support for natively compiling to WASM is growing. WebAssembly without Emscripten walks you through some cases.
So I heard you were looking to be able to edit in vim on a rotating, 3-d cube? Great news!
Oh, wrong 3d? I must have mis-understood — I see, you were looking for an immersive stereoscopic terminal experience like with an Oculus? Right, my mistake. Here you go.