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.