#81 - What's your team's specialty?
Plus: Yak spotting; getting the most out of an internship program; management as a technology;
Quick: what’s your team’s specialty?
Your team’s specialty is its reputation for what it’s good at. Not what you think your team is good at; what matters is what specific thing your stakeholders (bosses, clients) think your specialty is. What they recommend you for to peers, what they recommend getting budget for you to do.
In the post-pandemic world, clients are used to getting their work supported remotely from anywhere. To compete, your team will need well-defined specialties.
The pandemic isn’t over, but the end of this phase has begun. Last October I wrote about what post-pandemic research computing is going to look like, for instance, and it’s holding up pretty well.
This is an opportunity for well run, focussed teams to grow and prosper. But it’s going to take more planning and forethought than decades past, where one could count on having a near monopsony, of being the only available seller of services to local researchers. It’s going to take developing and maintaining a strong reputation. That’s easier with a specialty.
Now, on to the roundup
Managing Teams
Yak Spotting - Aviv Ben-Yosef
A good way of catching yak-shaving (video example here), for ICs or for managers - “Why are you doing this?”
Creating an Internship Program for Software Engineers - Tom Sommer & Gábor Zöld, Level→Up Podcast
Understanding the mentorship mesh - Daniel Peck, LeadDev
Internships are a lot of work for those hosting the interns. But that work can pay off, for large enough organizations. Some advantages of a robust internship program, routinely bringing in several interns at a time, include:
Constant hiring, and so continual maintenance and improvement of your hiring process, even at times when you’re not hiring permanent staff;
Constant onboarding, and so continual improvement of your onboarding documentation, explicit documentation of implicit knowledge, etc, which makes information easier to find for everyone, not just the new interns;
Improved recruitment of known-quantity high achieving candidates from your internship alumni;
Constant influx of new tools, new ideas, etc. from the interns (a trivial but telling personal example: it was interns who finally got me using VSCode after 20+ years of vi use).
Level→Up engineering, which is a routinely interesting podcast, has started writing up blog posts from their interviews, which is handy (I’m very hesitant to include un-skimmable resources like audio or video in the roundup unless they are exceptionally relevant). In this episode, Zöld interviews Sommer about Redbubble’s internship program, and what’s worked for them.
Some highlights:
Actively working with local organizations to source interns
Defining clear expectations
Having a lightweight version of the same interview process as for permanent staff
Interns arrive in cohorts, so they go through the experience together, even though…
They are embedded separately into teams, and may rotate between teams
Interns have volunteer mentors separate from their managers
Intern’s growth is monitored, for their own sake and for future hiring - rapid growth is a stronger signal for later hiring than high but constant level of technical competence
Interns who are on a path for hiring still go through the permanent-staff hiring pipeline
Peck’s article talks about the next stage of onboarding, for permanent hires. For this longer-term mentoring, having a single mentor isn’t enough; Peck prefers a “mentorship mesh” approach, with a team of people providing different kinds of mentorship:
A peer they’ll be working with, on the same career path (but somewhat advanced)
A senior person who is still further advanced
A domain expert in the area they want to develop expertise in
Their team lead/mentor
Management as a Technology - Nicholas Bloom, Raffaella Sadun, John Van Reenen, Harvard Buisness School Working Paper 16-133
Management is important, and the issues involved are complex, and like a lot of things that are important but complex, it’s the subject of a lot of study. That study looks different than those of us who came up in the natural sciences are used to - people systems are way harder to examine than, say, fluid systems - but it can be every bit as insightful.
This working paper from a few years ago results from interviews with 11,000(!) manufacturing firms in 34 countries, asking questions about whether the company followed industry best practices, and their practices around process improvements, performance review and tracking, feedback given, clear targets, high performers rewarded, low performers removed, and hiring and retaining staff. (The anonymized data is available by filling out a form at http://worldmanagementsurvey.org/)).
They then analyzed the data in a slightly unusual way - using the existing framework of analyzing the adoption of a new technology across firms and companies, and looking to see if the new technology improved productivity or not. But here the “technology” is good managerial practices.
The technology of management (literally a body of knowledge and techniques) might be a useful mental model. It’s not magic, it doesn’t require inspiration or a particular personality type - it’s the roll-out of a well understood set of practices. That doesn’t make it easy, but hey, adopting new technology can be challenging.
Bloom et al. find that management “technology adoption” accounts for 30% changes in total factor productivity across entire organizations, or even between countries. If anything, I’d guess that number is understated, since management approaches can be pretty heterogenous within an organization so there’s likely an averaging effect. I don’t find it hard to imagine at all that well-managed teams are at least 30% more productive than replacement-level management of teams; just take a look at the software development waste article below.
Project Management
Software Development Waste - Greg Wilson, It Will Never Work in Theory
Software Development Waste - Todd Sedano, Paul Ralph & Cécile Péraire, ICSE 2017
The domain being studied here is software development, but it’s a classic litany of project and just task management efforts gone wrong.
Wilson briefly summarizes a paper by Sedano, Ralph, and Péraire, who looked at eight software development projects at Pivotal, a software development company, for 2 years and five months, interviewed team members, and analyzed retrospectives. They identified nine broad categories of wasted time and/or effort in the projects:
Building the wrong feature or product
Mismanaging the backlog
Having to re-do work
Implementing unnecessarily complex solutions
Extraneous cognitive load (from technical debt, large/complex stories, poor tools/code, etc)
Psychological stress
Waiting
Knowledge loss, and
Ineffective communication
These are incredibly common problems that come from ineffective project management.
Rethinking Best Practices - Will Gallego
This is a nice thoughtful article on the role best practices do and should play.
I find that in technical fields, there are two bad and opposite attitudes to best practices; overly-deferential unquestioning “that’s what everyone does”, and just as unquestioning knee-jerk “that would never work here”. Gallego walks us through a third way, with a quote from a 2016 paper by Klein, Woods, Klein, and Perry in J. Cognitive Engineering and Decision Making:
We should regard best practices as provisional, not optimal, as a floor rather than a ceiling.
If you’re starting from scratch, or even rebooting practices in a team, industry best practices are the right starting point. They’re common for a reason, and if you choose a different starting point odds are better than even that you start off further from optimal. They also give you access to a language and a literature to discuss and compare approaches with other practitioners.
But effective teams are constantly experimenting and measuring, and so learning, what works for that group of humans on that set of problems. Very little should be left to received wisdom.
Random
A 1981 TRS-80 adventure game found, fixed and put online.
Making homemade silicon chips.