I occasionally get asked for advice by people who are about to make the transition from academia to industry: they’ve successfully navigated the path to industry and landed their first job, and now they’re nervous about completing the transition. They’ve heard that things are different in industry, but no one really gives specifics beyond “there are more meetings.”
They usually ask something like: “what is your number one piece of advice for me in my new job?” I used to say something about keeping your Outlook calendar up to date so that people could schedule you in meetings without having to check with you about your availability first. I still think that is good advice (although you might find your company uses Google apps instead of Outlook), and from what I’ve observed, it is still something new arrivals in industry often fail to do.
I don’t think prosaic advice about calendar software is what most people are looking for when they ask that question, though. They want something that gets at the heart of what makes working in a for-profit enterprise different, something that can help them acclimate to their new role more quickly, so that they can stand out and shine. I may finally have some advice that is more along those lines. It is:
Assume that your part of the project is the easy part.
This advice works for any large multidisciplinary project and these days there are plenty of those in academia, so perhaps more of the people coming out from academia now already understand this. In my experience, though, most people do not follow this advice, including a distressingly large number of seasoned industry old-timers.
Essentially all projects in a company are multidisciplinary. Even in the unusual case in which all of the technical work is done by a team of people with similar skills, that work is being done for some other group, either inside or outside the company. If it is another group inside the company, those people are part of the project, too. If it is a group outside of the company, there will be business development or marketing people involved in the project.
So: let’s just say all industry projects are multidisciplinary. Next, let’s think abut what makes a project team successful. That’s too big of a topic to really address here, but most people probably wouldn’t argue with the assertion that there must be trust and good communication within the team. One of the surest ways to kill that trust and destroy communication is to have one subset of the team looking down on the work done by other people in the team, assuming it is “easy.” This insults the people with the supposedly “easy” work to do and puts them on the defensive. Worse, it cripples problem-solving, because it leads people to make false assessments of the amount of effort required for various solutions. As trust degrades, team meetings begin to devolve into cagey, overly formal discussions or outright confrontations rather than the collaborative problem-solving sessions they need to be.
I can understand the tendency to underestimate the effort required to complete work in a different discipline. When we don’t fully understand something, it is easy to gloss over the complexities, and in doing so, gloss over half of the work that is required. And who has time to fully understand everything that everybody on the team is doing? In most cases, a full understanding would require years of study and training. This is why we hire specialists to do the work!
The solution is to assume that everyone’s work is hard, and that everything you ask someone in a different discipline to do is a big undertaking- until they tell you otherwise.
I saw this put into practice early in my career, in my second biotech job. At the time, the company had scientists who produced and/or analyzed data and programmers who created applications to speed the analysis. One of our managers noticed a tendency for programmers to say things like “can’t you just do XYZ analysis,” blithely disregarding the hours of data preparation and further hours of fairly manual number-crunching required to complete this analysis. Meanwhile, scientists would say things like “can’t you just add a button to do ABC,” blithely disregarding the hours of algorithm development, coding, and testing that would require. This tendency was called out to all of us, and we semi-jokingly banned the word “just.” Of course, we didn’t really ban the word, but you would catch yourself saying “can’t you just…” and stop, laugh, and ask the other person whether or not your idea was practicable.
The company already had a nice, collaborative culture, but this made it even better. We accomplished some things that I still look back on with great pride. It took me many more years and my own turn managing multidisciplinary teams to really understand the wisdom in banning the word “just,” but “assume yours is the easy part” is now something of a mantra for me, and I offer it up as advice for anyone just starting out on a multidisciplinary team. Live by it, and your teammates will appreciate you more, you’ll learn more, and you’ll all get more done.
The lab I did my PhD in worked from systems biology principles and involved collaboration between the theoreticians and the biologists. I can see now that the attitude and dynamic of assuming the other group had it easy and were lazy so-and-sos you describe here contributed significantly to the dysfunction in the group.
The theoreticians/mathematicians who did the modelling for us biologists were always asking us why we hadn’t done “simple” experiment xyz? or worse, demanding that we perform it asap, without any understanding of the biological work involved. Needless to say, that “quick experiment” would in fact most likely take months, if not constitute a whole separate PhD thesis! Consequently, that idea would bite the dust. But the biologists were seen to be making excuses.
The biologists were meanwhile reliant on the mathematicians to turn our work into theoretical models. There was more than one occassion when a mathematician’s work outright contradicted the biological finding, or missed a basic biological principle, and the mathematician would go away assuming the biologist was wrong! Dysfunctional and unproductive to say the least!
Finally, the theoreticians were also supposed to provide better software for the time-consuming data analysis bottleneck that is still a major problem in the project. Improvements were so slow in coming that I never used a version of the software that made it out of beta phase. The bitterness on the part of the biologists about this, directed at both the PIs (management) who had no clue how much of a productivity issue it was*, and the theoreticians who hadn’t done any of the requested work, and so were clearly useless, lazy, incompetent and arrogant to boot, didn’t help matters.
An understanding on both sides that none of the work is easy might have helped quite a lot.
*Not the only significant management failure on the wider project. Sigh.
I’ve seen similar dynamics far too many places. It is rare to find a multidisciplinary team with really good communication and teamwork- and even once you find it, keeping that team culture requires active commitment from everyone on the team. But it is sort of magic to work on a team like that. You accomplish things that seemed impossible.
I look forward to the day when I get the chance to work in a functioning team! I’ve seen glimpses of it in artificial career/personal development situations but never where it mattered. Otoh, being 25 with precious little experience outside academia, that’s not a great surprise.
The flip side of assuming that your part is easy, is understanding what your collaborators mean when they tell you something is “easy”. I find that communicating with people in different disciplines is an acquired skill, just knowing what information is assumed and what isn’t can be a major headache. I suppose this is less of a problem in industry where you’ve at least got managers in place, but in academia there is often a pretty big gap with no one trying to bridge it. I sometimes daydream about starting a consulting company that just provides management for large multi-disciplinary multi-centre projects. Big problem is that I really don’t like spending all my time talking to people. I like getting in there and getting my hands dirty.
Oh, it is still a problem in industry! I joke that a lot of what I do is translation, but that is true- different fields have different terms, and different assumptions, and different operating cultures. If you want people from those different fields to work well together someone has to do the work of helping them learn how to communicate effectively with each other. This is particularly true if your team has “newbies” who haven’t done a cross-disciplinary project before.
I’d absolutely love to help out academic projects, too, but there is a lot of work to do to even convince people that they need help.