#132 - Hiring: Make An Onboarding Plan First
Plus: Performance Improvement Plans; Manage Your Career Growth; Strategy Should be Meaningful and Ongoing
In #130, we talked about some general purpose first steps when taking on a new responsibility. Let’s talk about the other side of that, now — how to make sure someone we’re bringing on to tackle some new challenges can be as productive as possible.
Back in #126, we talked about beginning with the end in mind: having clear goals for the person taking on a new role, what it should like in the day to day. When scoping out a new responsibility, it’s important to define what success looks like after they’re fully onboarded. That onboarding timeframe may vary: say after 3-4 months for an individual contributor, maybe after 6 months or even longer for someone with significant complex duties (like leadership). That doesn’t mean they won’t continue to grow after that! But by that point the goal is that they’re functioning competently in the role. Our job, then, is to help them get there as quickly as possible, for the sake of the team and so that they can start feeling settled in and successful. That means designing an onboarding process.
There are four kinds of information to gather to design the onboarding process:
Make a list of all the knowledge skills and behaviours the person will have to learn to be at that successful end-state
Make a list of the people that the person should meet and talk to to understand the inputs to and impact of the work they’re taking on
Take an inventory of the resources (people, but also training materials or funding for training) you have available to help bring the person up to speed
Identify meaningful self-contained projects, increasingly non-trivial, that they could work on that would give them concrete places to apply to what they’re learning, and that could be milestones to being an onboarded, independent team member.
Building these lists will be iterative: items on one will suggest items that need to be added to another. Both you and the people you’ve had help you scope and define the responsibility can add to it and discuss it. For a software developer writing the lists lists might look like:
Understand one part of the code base extremely well and have a general understanding of how other components behave, know the CI/CD system and how we write tests, know the project management tools, how the team meetings are run, be able to run standups and retrospectives, understand our expectations around code review, pair programming and mentoring juniors
Meet everyone on the team, key users, and key potential users (oops, forgot about knowing how our user experience testing works), key administrative contacts
Resources include more senior developers, our existing practice of pair programming juniors, previous architectural decision documents, (oops, forgot about knowing where those documents are and expectations about documenting and how decisions are made), an institutional subscription to a MOOC platform where they can learn intermediate level skills in our programming language and version control systems, (oops, forgot about introducing themselves to our institutional professional development staff and other peer teams)
Projects include a complete solution to a small ticket (including adding a test and running the test suite), running a standup, building feature X that users have been waiting for, updating the onboarding documents, writing an architectural decision document, running a user test…
With those in mind, and collaborating with the people who are helping define the responsibility, you now have the raw materials to put together on onboarding plan. Stage the resources in such that they are always building towards application in some meaningful contribution. Introduce them to people in the (increasingly) broader community so that they have growing connection to the inputs and impact of the work of your team. At earlier steps in the onboarding plan, feel free to be quite prescriptive (e.g. preschedule a pair-programming session with one of the seniors on pieces of the code base); at later steps, the training wheels start coming off, and you can just list the people resources and let the new person make the connections and learn the material themselves. (You can always become more involved where needed).
As always, none of this is rocket surgery - it simply requires recognizing that onboarding is important, putting together a plan with the resources you have available, and then committing to seeing it through.
What’s the best onboarding plan you’ve seen (or experienced)? What’s the worst? Hit reply or email me at jonathan@researchcomputingteams.org and let me know. And as always, members of our community can always feel free to schedule a quick call with me if they have thoughts or questions.
And with that, on to the newsletter!
Managing Teams
Should I Create a Performance Improvement Plan for My Direct Report - Lara Hogan
We, myself included, don’t talk often enough about underperforming team members. It’s uncomfortable! But letting a team member struggle indefinitely is bad for them, and bad for the rest of the team.
In that context of reticence about poor performance, Performance Improvement Plans (PIPs) frequently have a pretty bad reputation as a perfunctory, performative step taken before firing someone. The following situation isn’t uncommon: A manager repeatedly but only indirectly discusses with a team member some area of underperformance. The team member remains blissfully unaware, or thinks (perhaps reasonably, given the signals they’re getting) that it isn’t a big deal. The manager, increasingly frustrated by nothing changing, eventually blows up and goes to HR, gets a template for a performance improvement plan. With HRs guidance the manger fills it out, setting a timeline where change is unlikely to be able to happen effectively, and presents it to the team member as a fait accompli. Eventually the team member sees the writing on the wall and to the ineffective manager’s relief resigns, or the team member is fired.
The above is a pretty crummy scenario, and is absolutely the fault of the manager. It shouldn’t be and doesn’t have to be this way. Getting HR involved absolutely should be a final step, but in the scenario above, many earlier steps were skipped.
It’s vitally important to give clear, actionable feedback when something isn’t going well. It’s unfair to the team member not to. There are several methods (#65) including Hogan’s own that focus on behaviour and impact, typically bookended by questions. And waiting until things are too late to change isn’t fair to you or them.
Hogan describes the pros and cons of PIPs, and while documenting your feedback and working with them on a plan to improve in the needed area can be very useful, getting HR involved in the process is a pretty hard-to-retract step.
If you find yourself in the position of seriously considering one, Hogan has a nice decision framework here:
Are you confident then will not be able to meet expectations in a reasonable mount of time? Then starting the process of managing them off the team in one way or another is appropriate
If you think they could, then ask yourself: “What haven’t I stated clearly/bluntly yet to this person about what I expect of someone in this role?”
Meeting with the team member and clearly discussing the expectations and consequences is the next step.
Then start thinking about how to get from there to here.
There’s also useful sections on what to do if the team member doesn’t see the importance of meeting the expectations, or don’t have a shared understanding of the expectations. This reminds me of a nice article on the five necessary conditions for improvement mentioned in #28.
By the way, the discussion above assumes that the thing they’re being given feedback on to improve is the performance of their own personal tasks. Adapting to new work is hard, and a fair amount of patience is justified in giving people a chance in getting up to speed. In that case I’m fully on board with Hogan’s clear, measured approach.
But there’s another domain in which people might be getting corrective feedback - about how they’re behaving to other team members or the broader community. If they’re being toxic to others, do not feel any such need for patience. Correct them once or twice, each times explaining the expectations and consequences, and document the behaviour. The next time it happens, begin the firing process, whatever that means in your institution. Do not allow toxic behaviour to damage the team or your research community.
Managing Your Own Career
How To Drive Your Own Career Growth In These 6 Easy Steps - Lighthouse Blog
This blog post lays out a great plan for making sure your career growth is a priority - its worth considering for ourselves, but also keeping in mind for our team members. Like so much in management, there’s no silver bullet here, it’s just having a clear plan in mind and constantly advancing it bit by bit.
Start from even before the beginning - during the interview process, ideally, making it part of your negotations. (Unfortunately, it’s a lot easier to advocate for your career growth in a new job than it is to start advocating for it an existing job where you’ve been stagnating for a while. )
Bring it up in your one-on-ones
Have clear career growth goals, and break them up into small manageable pieces. Take note of progress
Get your manager involved, in ways that are easy for them. Small budget items, introductions, keeping an eye out for future opportunities.
Write down your plans and share it with your manager
Consider your manager, and align your growth priorities to their needs
By the way, the article starts by pointing to charts from PwC and Deloitte on what’s important for employees, highlighting career progression and growth as being top priorities. It’s worth comparing these graphs to those from our own community, Understanding Factors that Influence Research Computing and Data Careers (#133). They’re indistinguishable. Team members in our profession want the same things everyone wants - growth, recognition, flexibility, purpose, pride in their work and their team, manageable workloads, the tools to do their job well, and enough compensation that they don’t feel undervalued. We’re constrained somewhat on pay, but all of those other pieces are at least partially under our control.
Random
A record-breakingly powerful gamma-ray burst 2.7 billion light years away measurably disturbed Earth’s ionosphere.
ar5iv, from arXiv labs: read (v1 of most) papers in reactive HTML5 instead of PDF by changing the ‘x’ in arxiv in the link to ’5’.
A fascinating three part series on the steam engine and why it wasn’t invented earlier when several key pieces were known as far back as the first century.
Working with hexagonal grids.
Interesting blog post summarizing a paper about how software developers use CoPilot (and presumably similar tools). The paper distinguishes between acceleration of what the developer was already going to do, and exploration of what to do next.
Rendering galaxy clusters, black holes, and Saturn in Minecraft.
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