What I write below likely applies to fields of theoretical and observational science that involve collaborations, too. I think the experiences that trainees in laboratory science are likely significantly different, as are those people who spent a large amount of time working in a single group in a well-defined large project. I’d certainly like to hear from colleagues from those areas; are there similarities, or are things quite different?
We don’t like to talk about it much, but the natural career path in academia - from undergrad to research assistant to graduate student, postdoc, Junior PI and beyond - involves a progression first towards and then away from the actual doing of science to the coordinating, orchestrating, planning of, and advocating for scientific projects; or, in other words, management (though we’d never call it that; academia is full of open disdain for anything that smacks of management, marketing, or other suspiciously real-world activities).
But computational-science academic environments are pretty particular places, with different approaches to working in a team than, say, in much of business.
First, academic work is largely performed by trainees like students, who have a very different relationship to their academic supervisor than an employee does to their manager. At its best, when an academic lab is run by ethical and competent leadership1, significant effort is put into developing those trainees, giving them increasing responsibilities, and looking for opportunities for them to apply those emerging skills to new problems.
Second, since much of the work is on open research problems, it’s very difficult to judge how long something “should” take, so deadlines in assigning tasks is relatively uncommon; updates tend to sound like “here’s what I managed to get done this week,” and it is what it is.
Third, due to the open-endedness, the trainee/mentor relationship, and modelling the extreme independence of senior academics, there is a norm of collegiality. Directing someone’s work comes across as very heavy handed; the final work output can be ruthlessly assessed, but path to get there, the work process, is somewhat off-limits.
Fourth, it’s common - maybe even the norm - for projects to be tackled with others outside of not only the team, but in different institutions entirely.
Finally, the independence of researchers, the dynamic nature of research, and the fact that so many coworkers are elsewhere mean many working relationships are comparatively short-lived.
So imagine that you are a postdoc - the most senior trainee - in a computational lab, routinely working in multi-institutional collaborations, and this is where you’re developing your people and project management chops. You are directing some particular piece of research that will lead to publications key for your career. You aim to be the lead author on one or more of those papers and you have a clear idea of the path to get there, and you’re driven — you’ll be on the job market next year and you learned at a conference that a competitor’s lab is looking at some of the same questions.
But your “project team” are peers or even academics more senior than you, and many are outside your institution entirely; getting them to do anything is a matter of persuasion. Your local, more junior, trainees are just beginning their journey, and for them to contribute meaningfully you have to find ways to develop their skills and the best ways to benefit from those skills. You want everyone to be invested, contributing, and growing their skills, and you don’t have time to direct people in how to do their work even if you were so inclined. And the clock is ticking.
What kind of skills are you developing as you’re thrust into this situation?
Much of the computing and technical community is teaching itself things about management that the rest of the world has known for a half-century. Famously, Google’s Project Oxygen, which was at aimed least in part at “proving” that management does not matter, started in 2008 looking at management across teams in the organization, and found that it really does. (Surprise!). Their original findings identified 8 characteristics of managers of successful teams, and 3 pitfalls that managers in less successful teams fell into.
Those characteristics of good managers, in decreasing order of importance:
- They’re good coaches.
- They empower their team and don’t micro-manage.
- They express interest in their team members’ success and personal well-being.
- They’re productive and results-oriented.
- They’re good communicators and they listen to the team.
- They help employees with career development.
- They have a clear vision and strategy for the team.
- They have key technical skills that help them advise the team.2
How will our postdoc rate against those criteria? Well:
- They are going to be very concerned with skills development in their direct reports, encouraging them on to bigger and better things — so the postdoc learns to be a good coach;
- They certainly won’t micromanage — they’ll let team members decide how to approach their work;
- They’ll be very aware of the need to develop their team member’s success, partly due to norms around credit, and partly due to expectations that people move up and on in their careers;
- They’re very focussed on high-quality work and the steps to get there;
- Because they’ve never been able to rely on role power or organizational authority to coordinate the getting work done, they will have developed the communication skills necessary to communicate with and listen to the team, at least around tasks;
- Thinking about team-members career advancement needs and goals is going to be second nature, although they might take it for granted that they know what the team members goals are;
- They’ll have quite clear goals and a vision, even if they’re not used to having to communicate it explicitly in an environment where everyone knows that the goal is discrete publications and can clearly see where their work fits in;
- They will typically be quite proficient in their relevant technical skills.
That’s just about a clean sweep!
So I claim that the sort of training that I’ve seen people get on projects in computational (or observational or theoretical) science collaborations equips people with the advanced skills to become great managers.
But there’s a downside. The very hands-off approach to management (indeed, the refusal to countenance that “management” is even an appropriate thing for scientists to stoop to) means that some of the more basic, fundamental, skills are lacking. The same early work at Google pointed out key shortcomings of their less successful managers:
- Have trouble making a transition to the team.
- Lack a consistent approach to performance management.
- Spend too little time managing and communicating.
And those start to look like real sticking points for our postdoc. Almost no one is taught management skills before their first management position, but scientists are more or less taught that management shouldn’t be done; “we’re not that sort of people”. So:
- Making the transition to being the manager of the team is going to be doubly difficult for our postdoc — both in internalizing their role as a manager, and in putting the time in to develop really solid working relationships with the team members.
- Performance communications - giving people feedback (positive and negative) on their work often and regularly, rather than waiting weeks or months for some big sub-project to be done and then assessing the finished project — is going to be completely foreign, if not anathema, to them.
- Our postdoc is going to spend little to no time actually managing, or communicating about the things they haven’t had to communicate about before like sharing the vision aind aims of the team, or finding out the specific career goals of individual team members.
So while many or even all of the advanced skills might well be in place for scientist trainees to excel at management outside of the academy, the basic skills — or even models of what the basic skills would look like — are often going to be lacking.
But those basic skills are the easiest to address! Anyone can learn them, and someone who’s spent a good chunk of their career in the sciences certainly can.
So many computational scientists do end up becoming good — and so quickly become great — managers successfully on their own, but it can take a lot of trial and error, and be stressful for all involved. (My own transition towards becoming good has been…. uneven.)
I don’t think that transition has to be so difficult; today there are some fantastic resources out there to help. And maybe it’s where I’ve been looking or which materials resonate with me, but a lot of the strongest sources that really nail the basics come from people on the more technical side. I’m a huge fan of Manager Tools, which have amassed a huge library a “here’s a number of steps you can start taking today” podcasts and a couple of books, with data to back them up. A number of colleagues really like The Manager’s Path which takes a career-long view of stepping up the career ladder (set in the tech industry but most of the material would carry over to other fields) and the different skills and responsibilities needed at each stage. And Google’s ongoing organizational reasearch and resulting training materials at rework.withgoogle.com are well worth reading.
Scientists learn a lot of transferrable skills in their training, and the world needs more of their input in teams and projects across all sectors. There’s a stereotype about scientists being nerdy introverts, but collaborations across institutions build really quite advanced communications and management skills that can serve them very well almost anywhere. And if they need a little help adjusting to the different skills needed for managment of projects or teams outside of academia, there are resources out there now to help them succeed. If there are some that have especially helped you, please do share them with me and I’ll list them here.