#34 - Link Roundup, 18 Sept 2020
Noticing change; Taking advantage of your team's know-how; Your values are the rules they break; Bucketing your time; Offboarding yourself; Leadership lessons from TV show writing;
Hi
As always, reply or email me (jonathan@managerphd.com) if there are things you’d like to hear more about, stories or topics you think our readers would like to read, or any other feedback.
Now on to the roundup!
Managing Teams
Noticing Change - Aviv Ben-Yosef
One of the recurring themes of this newsletter is that research computing is important enough to do with professionalism, and that professionalism is nothing more than being deliberate about what you’re doing, while continuously learning from what you and others have done.
Learning from what you and your team has done necessarily means noticing that there’s been a change. And there’s no way to systematically notice improvements - or regressions - without gathering data, taking notes, and otherwise keeping track of changes and their response.
One suggestion Ben-Yosef makes that I’ve been meaning to try is to make “decision logs” as a manager - or even as a team. When you make a change, or a decision, log it and periodically review to see how that decision played out.
From Procedural to New Knowledge: Leveraging Your Team’s Know-How - RC Victorino, Slab
This article comes at an interesting time for our team, where we’ve been trying to figure out how to do exactly this.
The argument Victorino makes is that “procedural knowledge” - how to do X - is undervalued, and hard to usefully document. One of your team members learns how to do the thing - say how to (in our team’s case) set up a particular test suite, or configure VS code to develop in a remote container, or convert certain workflows to a new tool. Now, sure, they can probably write up a document that has all that information in one place, but many of those facts probably already existed in other documentation - it still takes someone new real time to learn how to do it.
But this procedural knowledge is actually really useful, and is a stepping stone to more valuable knowledge. Now that people have learned skill X, they can use it in all sorts of ways – “Hey I can use X to speed up that thing Y that’s been holding it back”. So transmitting it within (or beyond!) the team is valuable. And the best way to do that transmission is with shared experiences - pair programming, talks, etc. Anyway, it’s a good article and if it interests you, you should read it.
From our teams point of view, this would also have the advantage of helping the team grow together, would help more junior team members get practice giving talks and mentoring, and potentially put videos up of their talks helping grow their (and our project’s) visibility. So we’re going to try to figure out a way to do this - current best idea is to batch 2-3 short (10-15 min) talks/demos/workshops on related topics into mini “conferences” for mainly internal consumption but with relevant people from interacting groups invited.
Has your team tried similar things? How has it gone?
Your Values are the Rules You Break - Stephen Prater
When they don’t know what to do, they’ll do what they know. - Marcus Blankenship
These are two interesting articles on understanding two different reasons why your team may not be doing what you are telling them to do. They’re probably not intentionally thwarting you or ignoring you; they’re probably responding to different incentives.
Prater’s article focusses on larger picture concerns. Say your organization, or even you, routinely tell people you “value” X — high quality code, collegiality, inclusion and diversity — and want them to, too; and yet they repeatedly break those rules and behave differently. The issue here can very easily the difference between those stated values and the actual values or behaviours of you or the organization. If you “value” high quality code but actually reward or reprimand based on meeting overly-tight deadlines. you aren’t going to get high-quality code. They’ll break that rule in favour of the real values, cranking out whatever to get stuff out the door. Similarly, if the organization “values” inclusion and diversity but doesn’t actually act in a way that brings in people from diverse backgrounds and truly include them, they’ll break those rules too because they see that those “values” aren’t actually lived up to.
The second article is more focussed on your actions as a manager - if a new project, task, or behaviour isn’t clearly and continuously communicated, with instructions and examples as to how to Do The Thing, people will inevitably drift back to what they know how to do. Because then they’re doing something, instead of sitting around being uncertain. Part of a being a manager is communicating about something in a zillion different ways until you’re sick and tired of hearing it - because it’s just about then is when it’s starting to get heard by people.
Managing Your Own Career
Bucketing your time - James Stanier, The Engineering Manager
We’ve talked about organizing tasks in buckets before - In Issue 37 I’ve mentioned my experiments with trello, and in Issue 39 I linked to an article about having a “dashboard” that covers both issues, things to keep an eye on, and future-looking work.
This is a nice article about why I find these approaches work well for me - it’s a way of systematizing the discipline of not just getting lost in the day-to-day while also highlighting important-but-not-urgent tasks at a variety of timescales. If this something that you wrestle with too, this is a nice article to read. I’ve certainly found being able to keep track of “today/this week/coming month/coming quarter” tasks useful to keep my eye on the ball. Stanier also distinguishes between recurring tasks and one-off tasks, as a way of showing what tasks would be more valuable to delegate.
OffBoarding as an Engineering Leader - Iccha Sethi
We’ve had a few articles here about your-first-90-days at a new job; this is an article about your last days as a manager as you move to a new position.
Sethi mentions several areas to focus on:
Your team - informing them, and documenting pending performance issues, salary, equity, or promotion status, and then informing them of the departure
Documenting the status of the team as a whole and their projects
Documenting the status of any projects or initiatives you were pushing for
Stakeholders - peer teams, and for us research groups - informing them and having a clear plan to hand them off to a specific individual
Documenting a clear transition plan
There’s a lot to do! The good news is that if you’ve been following the practices we’ve been recommending in this newsletter - one-on-ones with notes, regularly quarterly planning and reviews, project documention, and the like - many of these tasks become much easier. And if not - well there’s no need to wait until you’re going to start a new job!
Seven technology leadership lessons from TV show writing - Daniel Jarjoura, TLT21
The community has built a lot of analogies between technical expert work (like software development or data science or bioinformatics or…) and engineering, but engineering isn’t the only discipline where people have to work together to build complex and intricate stuff under tight deadlines and shifting requirements. Jarjoura tells us seven lessons from successful show runners that he believes carry over to computer systems or software development teams
They know their show and tell everyone what it is - there’s a common, shared, and continuously communicated vision.
They create a safe space - show runners need to create an environment where everyone feels safe to share so the best ideas can surface, even in an environment where dozens and dozens of ideas will get knocked down before one or two are chosen to work with
They make writers pitch - no episode gets written just because “it’s Joe’s turn” or “because Jessica said so”
They give everyone a chance to talk - along with 2, show runners make sure everyone speaks and has their voice heard
They combine creative thinking and passion
They rotate writers and make them work collaboratively - well before “pair programming” was a thing
They write and rewrite quickly
The same analogies over and over again can be limiting, and I like the idea of borrowing from other successful industries
Random
Jailbreak your TI-CE calculators.