#1 - Link Roundup, 31 Jan 2020
Hi; I hope you’ve had a good week!
This week, Clayton Christensen died. He was most famous for his book on The Innovator’s Dilema, which has more going for it than ”disruptive innovation”; and for his influence on Andrew Grove, who turned around Intel in the 80s(Grove then wrote a book, High Output Management, which remains extremely widely recommended in tech circles for those who want to improve their management and leadership skills; it advocated quite early on for regular one-on-one meetings, for instance).
But Clayton Christensen was also beloved by students at Harvard Business School for the genuine interest he took in teaching, and he felt equally strongly about management:
Management is the most noble of professions if it’s practiced well. No other occupation offers as many ways to help others learn and grow, take responsibility and be recognized for achievement, and contribute to the success of a team.
I believe this to be true; especially in areas informed by research, where the stakes are high and where management is not only in bad shape generally but treated with active suspicion (“going over to the dark side”). Many of us have given up the the day-to-day satisfaction of hands-on advancement of science to instead help other people have those achievements and that satisfaction, so that more of the right research computing and more science can be done. And so yes, god help me, there’s importance and nobility in that - or there can, and should, be.
Highly technical research-informed fields as a whole can’t professionalize until there’s a cohort of professional managers. Excellent individual contributors can’t do their best work if they’re led by professional managers who don’t understand the field; and they can’t work effectively if they’re led by researchers who haven’t yet been taught to be professional managers and so still assign work poorly, don’t set or enforce expectations, let issues fester, don’t help with career development, or can’t advocate properly for the team.
As a community we certainly didn’t get that training from our institutions, so it’s up for us to teach ourselves.
I’m getting ready to start things in mid-February, and based on feedback I’ve gotten from you, I’ll be starting off focusing on three areas:
Managing Individuals - Working with individuals to help grow their careers, giving them feedback to build their skills and align on expectations; delegating tasks.
Managing Teams - As above: building the team, retrospectives, supporting the growth of peer-to-peer accountability. Leaning on work from the tech, business, and nonprofit worlds, because our environment is like (and unlike) all of the above. Techniques, tools, best practices.
Product Management - The emphasis in research is around project management, since we’re funded through grants for projects. But we actually do product management as managers, which includes constant communication with customers; communications and advocacy (which never ends; even when a product is ”done” and a success, if you want those lessons to be learned for the next time, you have to keep advocating), and prioritization across projects - program management.
If there’s specific topics you want to see in those areas, just hit reply and send me an email.
So enough editorial, on to this week’s links:
Managing Teams
Hire Good Writers, ”Getting Real”, Basecamp
A short, thought provoking section from an interesting write up on building web applications by Basecamp.
“If you are trying to decide between a few people to fill a position, always hire the better writer…. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone elses’ shoes. They know what to omit. They think clearly. And those are qualities you need.”
Breaking ties when hiring is genuinely hard, and I’m going to take this suggestion seriously when the next opportunity rolls around.
On being “technical” as an engineering manager, Sean Voisin
How technical do you have to be to be a technical manager? I think this blog post has the right answer; ”enough”, where enough will depend on what your team is doing and what your role is on the team.
You have to be able to make sure the team’s doing the right work and progressing satisfactorily, but that’s a different kind rather than a different amount of technical knowledge necessary to actually do the work. For us it will require a certain level of subject matter/domain science literacy as well as staying on top of what other teams are doing and using to solve nearby problems.
Do Introverts or Extroverts Make Better Leaders? Wally Bock
I don’t think it’s controversial to suggest that the population of people who have chosen (a) research and (b) computing for a career tend to be introverts, and that can make the transition to managing other human beings a jarring transition. But managing well is a set of skills, and there is no one who finds all of those behaviours - seeing the big picture, sweating the details, working closely with people, working closely with abstractions (and all simultaneously!) - immediately natural.
“When looking at CEOs who met expectations, we found no statistically significant difference between introverts and extroverts. High confidence more than doubles a candidate’s chances of being chosen as CEO but provides no advantage in performance on the job.”
While that’s very nice to hear, there’s something else here - those of us in the research computing field probably aren’t aware of studies like where that came from:
It’s based on their review of 17,000 leadership assessments.
There is actually a lot of data on the basics of good management, lots of which comes from quantitative studies at single large organizations (so where a lot of other variables are held constant). It’s noisier data than in say astronomy, because between-people variability is larger than that between stars, but that just means that you need large N. The basic low-hanging fruit of things people can do to manage well are not controversial or in serious question; people use (and argue over) different techniques to do the same basic things, but in the end you need to build good, trusting, working relationships with and between your team members, set consistent expectations and give constant feedback against those, help team members develop needed and desired skills, and give them increasing responsibilities. Our context may differ from manufacturing jobs, which matters, but the basics remain.
That’s it…
And that’s it for another week. As things start in mid February we’ll have more frequent emails but the individual emails will be shorter (I promise); I hope this wasn’t too much of a slog.
Have a great weekend, and good luck next week with your research computing team,
Jonathan