#112 - Professionalism Is Process
Onboarding staff; Production bioinformatics; Tracking big-picture items; Why new outside gigs are hard
The (157-item!) intern process checklist from last week generated a few interesting discussions, and those plus an interesting slide deck by Chris Dwan that came out this week discussed below return to a common theme here in the newsletter - of projects versus processes, or learning versus production.
In #82 I alluded to the fact that what distinguishes a hobbyist from a professional is repeatability. The hobbyist is still developing their skill, trying to make their one-off thing come out with high quality. The professional is no longer struggling to make one thing well; they’re trying to ensure that things reliably, repeatedly come out with the same high quality.
The hobbyist is thinking about the mean quality, and trying to get it to trend upward; the professional is concerned with the variance, and reducing outliers. (Mean matters, too, but for a professional, a high mean quality is table stakes). There’s a progression from focussing on skill to focussing on reliability, from craft to process. One of Dwan’s slides says:
Amateurs practice until they can play it right; professionals practice until they can’t play it wrong.
There’s something of that in leadership, too. You’re leading people, but you’re managing and creating processes so that the team can reliably do their best work. Those processes can’t be created ex nihilo; they have to come from having learned how do the thing well once, and then you can start building a process around it so you can reliably do it well.
Whether you’re hiring, or adding a node to the cluster, or building and deploying a new release, or adding new data to a resource, professionals have SOPs that they follow so that the thing gets done well. You don’t have one of those to start with, of course; it’s all figure-it-out-as-you-go at the beginning. Then it gets routine, then it’s documented in an SOP, and then as you find still better ways to do it, that make it even more reliable, you update the SOP. Or automate parts of it! Either way, instead of people spending time thinking “how does this go again?”, they free up time and brain space to improve the process, or to work on something new.
As you’ve it progresses and matures and solidifies enough to the point that others can also reproducibly do the thing, it’s becoming development, and then production. It’s an input that others can use to do research, rather than a research output. This is also good and important work, but it’s of a different kind.
On to the roundup!
Managing Teams
The Ultimate Guide to Onboarding Software Engineers - Csaba Okrona
Eventually I’ll try to do a similar onboarding process starting-point checklist for full time staff. Okrona’s article touches on what some of the biggest differences will be (and it isn’t particularly limited to software developers)
When you’re hiring someone you hope will be on your team and successful for a long time (at least a couple of years) doing work you don’t even know will happen yet, then there are other things you need to add to the onboarding. Okrona has on the list onboarding into the wider organization - getting them familiar with and maybe introduced to stakeholders, other departments, communities of practice of relevant, etc. Also there is onboarding into the team and organizational cultures - what matters most to those groups.
What I really like about this article though is the part about expectation management - for you, for stakeholders, and of course for the new team member. Okrona strongly suggests having 30, 60, 90, and 150 day milestones, what you expect them to have accomplished or to be able to do at those points. Not only does that give them something to aim towards, and milestones by which they can gauge their progress, it’s also something to use to set expectations for stakeholders or team members (“Frank just got here 3 weeks ago! We don’t expect new team members to be doing code reviews until month three, remember? He’ll get there, don’t worry”).
I’ll add that those milestones are great to share with potential new hires even when they’re just candidates - you can put them in the candidate packet or even job description. A more ambitious version is to have defining those milestones be the first part of the hiring process, before even writing the job ad, and to back out all the candidate requirements from those milestones. Having that kind of clarity adds a coherence to the hiring process, makes it very clear to job seekers if this is a job that they’re interested in, and provides them with some kind of evidence that there’s a plan for their success if they do join the team.
Ditch Your To-Do List and Use These Docs To Make More Impact - Brie Wolfson, First Round Review
We start off in tech with ticket trackers and to-do lists, and tend to carry that through to our first leadership jobs. But they’re inadequate when you become a manager or lead.
As a leader you no longer have the comfort of merely being responsible for set of discrete tasks that can be independently ticked off. You’re probably not even only responsible for individual projects. No, you’re responsible for much more nebulous things like ‘priorities’ and ‘efforts’ and ‘directions’ and ‘staff development’ and ‘stakeholder management’. Stuff that you can’t just cross off the list one day and be done with. How to keep track of stuff like that? They each certainly generate individual to-do tasks with alarming frequency, but you need some higher-level meta tracking too.
There isn’t a single answer, a single thing that you can do. (Isn’t being a leader awesome!) This article offers a number of documents Wolfson finds helpful, broken down into daily, monthly, and quarterly documents.
Ones I think are or might be particularly useful are:
An ongoing stack rank of all those nebulous ‘efforts’ and whatnot, with their priorities and broad themes of current work - it’s helpful and clarifying to have a list of all such things in one place
Updated lists of things you’re proud of, things you got stuck on, and things you learned
Going back periodically (how often will depend on the kind of work, I think) and updating a list of things you or your team got done that had real impact, and what the impact was
How to run a Retrospective - Chase Seibert
Siebert writes this in the context of sprints, but this short and solid how-to for running retrospectives applies to any project. (A sprint is just a a mini-project, after all - it has well-defined objectives, along with a beginning, middle, and end). Indeed, you don’t need to wait for something to end to run a retrospective; periodically going over what's gone well and what should be improved is a fantastically healthy process for any team.
Siebert feels that actually following up on the retrospective is out of scope of an article on how to run the retrospective meeting, which is fair. Don’t take that as a sign that the followup is secondary, though! People will stop contributing if they don’t see good-faith efforts to incorporate the results of the feedback into improving the work. After all, that’s the whole point, right? For a recurring retrospective after a sprint, you can introduce things in the next sprint kickoff, or some other regular part of the cycle. For longer one-off projects, you might write something up distilling the results and circulate it.
I’d also add that these retrospectives, like standups, can work really well if you as the manager don’t run it, and rotate leadership of the meeting through willing members of the team. It helps develop skills, gets everyone more invested, helps you delegate a task, and lets you pay more attention to the content of the meeting (or even participate!) than the operation of the meeting.
Managing Your Own Career
Why Success Is Often Elusive at the Highest Echelons - Cindy Sridharan
It’s good and healthy to move between organizations, to both gain and bring new perspectives. But doing so is way easier in more junior positions, whether as an IC or a manager.
Sridharan walks through the challenges of moving into new organizations in a more senior leadership position, and why so many who do don’t succeed. That doesn’t necessarily mean fail - it can end up meaning just “meh”. But a year or two of “meh” in a senior leadership position can mean a loss of trust. You get longer to prove yourself in a leadership position than a more junior one, but not years.
It’s laid out very clearly in Sridharan’s article: at some point mere competent execution isn’t enough, you need to be both executing and improving things around you. But being able to improve things at leadership levels is a team sport. You need a support structure of colleagues to get anything substantial done. You need deep knowledge of the context to make sure what you think is an improvement actually is. And you need knowledge of the culture to know how to communicate and effect the improvement. Those require trust and connections and communication, which take time.
As high achievers, and as people who probably have done well at hard things in the research world, we disproportionately tend to march into a new situation pretty sure we can handle this. We probably can! Succeeding in a senior leadership position at a new organization certainly isn’t impossible. There are good practices - The First 90 Days is kind of a classic text on the subject, but there’s been a lot since.
But knowing that it’s a real challenge, and understanding the shape of the challenge, is the crucial first step. Sridharan lays out the challenges well.
Preparing to Tell Your Boss “I Quit” - Nihar Chhaya and Dorie Clark, HBR
So knowing that, you’re going to take that new position anyway? Great! You’ve got this. Now you just have to tell your boss.
(And by the way — you have to tell your manager before your peers or your team members. You just do. I’ve seen people try to do it the other way. It’s worse for everyone.)
Like preparing for any awkward conversation at work, there’s really no way forward but through. Think about what you’re going to say, and it’s good to be prepared for a few different kinds of reactions so you can know how you’ll respond rather than playing it by ear in the heat of the moment. Chhaya and Clark lay out the possibilities. But don’t spend hours or days dwelling on it - just do it, the sooner the better, and do it as “face-to-face” as the situation allows.
These conversations tend to be awkward but generally positive. Yeah, your manager will be surprised and disappointed, but people move on.
Random
If Apple, Google, and Microsoft are all behind it and developing standards, maybe we do finally stand a chance of getting rid of passwords.
As we now know, computers were a mistake. However, this week I found one valid use for them - a remarkable explanation, with interactive visualizations, of the working of a better class of technologies - the mechanical watch.
There are very very few truly new ideas. Distributing workloads in heterogeneous distributed systems - in 1969.
Ever wonder why the huge jump from Windows as a DOS GUI (Windows 3.1) to Windows as a real network operating system (Windows for Workgroups 3.11) had such a small version change? And why Windows NT’s first release was version 3.1? It was for legal reasons.
What if google translate, but for programming languages?
What if man pages, but nicely formatted and organized and with the examples first?
What if pandoc, but for http api content types?
That’s it…
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your team,
Jonathan