#74 - 16 July 2021
Accountability in teams; Hiring before, during and after the interview; Making time with timeboxing
Hi, everyone:
I hope you’re doing well.
I’ve neglected the “managing your own career” section lately, which I’m going to try to fix; we spend a lot of time here talking about helping our team members develop their skills, which is good and we certainly have an important role to play there, but we have to look after our own careers as well. Luckily in the past week several very relevant articles have crossed my browser, and so I present for you this week an attempt to bring that back into balance a bit.
Are there particular things you’re doing to track your own career progress, or get ready for future next steps? Are their particular gaps you’re not sure how to address or questions about how to progress? Please feel free to email me at jonathan@researchcomputingteams.org or just hit reply, and I’ll answer as best as I can and with your permission ask the newsletter readership to chime in, too.
For now, on to the roundup:
Managing Teams
A Manager’s Guide to Holding Your Team Accountable - Dave Bailey
A lot of research computing team managers - especially those of us who came up through the research side - aren’t great at holding the team accountable. It’s pretty easy to understand why - the whole idea of being accountable for timeline and scope is a bit of an awkward fit to that world. Something took longer than expected, or someone took a different tack than they had committed to earlier? I mean, it’s research, right? If we already knew how to things were going to go ahead of time, it wouldn’t have been research.
But supporting research with computing and data is a different set of activities, and to give researchers the support they need we need to hold team members accountable for their work, and team members need to hold each other - and you - accountable. Mutual accountability is what separates a team from a bunch of people who just happen to have similar email addresses.
So going from a role in one world to one in the other takes some getting used to. It’s easy, as Bailey reminds us, for accountability conversations to feel confrontational - maybe especially to the person starting the conversation. But he summarizes our role as:
Asking probing questions about what happened
Clarify our report’s explicit and implicit commitments
Deliver feedback clearly and constructively
In particular, he distinguishes between “holding someone to account” and “giving feedback”. Holding someone to account involves clarifying the expectations and asking probing questions about what happened; giving feedback means providing your reaction about what has unfolded.
There are familiar points here for longtime readers - Bailey includes discussion of the Situation Behaviour Impact (SBI) feedback model - but distinguishing between holding to account and feedback is useful and new, and the article is worth reading. Bailey also gives a helpful list of probing questions:
What were you trying to achieve?
What was your plan?
What options did you consider?
What drove your decision?
What actually happened?
How did you react?
When did this happen?
What did you learn?
What would you do differently?
As well as some starting points for accountability conversations.
Secret tips for effective startup hiring and recruiting - Jade Rubick
How do you identify great engineers when hiring? - Yenny Cheung, LeadDev
These articles read together give a sense of what a really good hiring process could look like. Rubick’s article starts well before the job ad goes out, and continues well past the hiring of any one candidate; it’s about strategy pipeline, and iterating. But it’s intended to quite a wide audience, so doesn’t go into the details of interviewing for a particular type of role, which is where Cheung’s steps in.
Rubick’s article starts very early on in the process. What is your hiring strategy? Why should someone work on your team as opposed to any of the other myriad of opportunities out there? What does your team offer, what can you be flexible enough or emphasize? A clear and well articulated set of reasons and benefits here can be used in a number of places - your careers page, how you recruit, where you post ads, and more.
Rubick then recommends putting real thought into the job description and ad, testing the application process to see what it looks like, (he also has a nice article on creating an interview plan), and moving quickly.
A great idea I haven’t seen anywhere else is to start assembling useful information for candidates - like an FAQ, and which can be added to with real candidate questions - and when it’s big enough to be useful, to begin sending it to candidates as part of the process once they get through the resume screen stage. He also recommends giving feedback to and asking for feedback from candidates, keeping in touch with promising candidates, and actively recruiting based on everyone’s network.
Cheung’s article goes into the process of interviewing. She starts with some basics, like having clear expectations up front; having gone through the resume and detail and mining for questions; and staying away from hypothetical questions (I can’t agree with this enough; either have them do the thing and evaluate it, or ask them how they have done the thing in the past, don’t ask them to just make up how they might do the thing).
The secret sauce, in her estimation (and again, I strongly agree) is in the followup questions. If you’re not digging deeply into the answers with more questions, you might as well just have people email in their responses. Digging deep into the whats and hows is how you get the information you need to evaluate the candidate.
Managing Your Own Career
Dropbox Engineering Career Framework - Dropbox
We’ve talked a lot in the newsletter about career ladders, but it’s generally been for our team members - the path of increasing technical seniority. What about us? How do we know what skills we should be developing; how do we know if we’re making progress?
In our line of work career progression is slow and comes in fits and starts, but that doesn’t mean we can’t be levelling up our skills. Dropbox has an unusually clear engineering management ladder, starting with M3 (the link above) through a more senior (but still front-line) M4, through an M5 Lead-of-leads (Senior Manager), M6 (Director - manager of senior managers) and M7 Senior Director. It has plain language descriptions of what they expect to see - in terms of behaviours and outcomes - for leaders at each level.
Areas covered are the big picture scope/collaborative reach/impact levers (how you get things done), Results, Direction, Talent, and Culture.
Do those line up with what you’d expect a research computing manager to be or aspire to? What are the biggest gaps?
Writing is Networking for Introverts - Byrne Hobart
This is an older (2019) article that recently started circulating again, and I really like it.
Relationships are a key part of being an effective leader, and for building your career. Trust speeds collaboration, and we trust people we already know and have interacted with.
Increase the circle of people who trust you (and you trust) so you can have more effective and frequent collaborations requires building your relationship network. “Networking” has come to sound like a suspiciously disreputable process, especially to people like us in research, but it needn’t be. Meeting and interacting with other people who share our interests, and in doing so building professional relationships, is a good and healthy thing.
It’s also super hard to start doing if you’re an introvert, which many of us at the intersection of research + computing are.
Hobart encourages those of us who find in-person networking uncomfortable to think of writing as a way to build our professional network; as he points out,
You don’t have to introduce yourself to anyone.
You don’t have to conversationally grope around for something to talk about.
Your conversational partners are pre-selected for having shared obscure interests.
As an example, you might want to start a blog or a newsletter. You know, hypothetically.
I’d add that in our work, giving a talks at conferences is another great way to speed networking for introverts. Once you’ve given a talk the rest of the mingling events at the conference are way easier to navigate. People come to you to ask questions about something you were interested enough in to give a talk about.
Timeboxing: The Most Powerful Time Management Technique You’re Probably Not Using - Nir Eyal
I’m a little surprised to see that timeboxing hasn’t come up on the newsletter as often as I would have thought - it was one suggested strategy out of five in one article we covered in #53. It’s a very useful technique for making sure you get things done, and for scoping those things.
Problem with a to-do list include:
Many of us aren’t great at breaking down the to-do items into discrete-enough chunks, so there’s a lot of open scope
It doesn’t help deal with distractions
There’s always more stuff on the todo list, so at the end of the day you feel like you haven’t done enough.
Timeboxing involves actually blocking off time on your calendar to do certain tasks - or classes of tasks, and assigning items to any particular box. It’s great because it actually schedules you to do task X in an hour on Tuesday afternoon, meaning you’ve scoped it better than just a bullet point saying “X”, and by committing to that you’re less likely to be distracted during that hour.
Eyal cautions us to:
start small,
iterating to get it right,
sticking to the schedule - if something came up and you didn’t do X, follow the schedule anyway and do Y next
learn what works for you.