Academia to Industry Part 2: Cash and Commercialization Rules Everything Around Me
Part 2: Welcome back to my exploration of lessons I’ve learned in my journey from academia to industry.
In case you missed it, in the first part I explore how the transition from academia to industry affects who you are at your molten scientific core.
I’m an Astrobiology PhD who has spent the past 15+ years pioneering innovative data-driven solutions in the biotech and energy industries. These days I’m the CTO of Cemvita, where I lead the development and deployment of nature-inspired biosolutions to enable the transition to a carbon-neutral future. I’ve been fortunate to pivot my career to a point where my grad school self would be amazed. This journey hasn’t been easy, and I’ve made more mistakes than I should probably admit 😊
That said, as we continue to ramp up technology scaling and development to actively tackle the energy transition, there is a glaring need for scientists and interested academics to tackle some of industry’s toughest challenges. In the spirit of helping and enabling the next generation of scientists transitioning to industry, I’ve written up my list of the most impactful lessons I’ve learned. These are broken down into four main themes.
Today, we’re diving into part 2: getting into the business. Or, how you can develop the business acumen to do work! As Wu Tang Clan says, Cash Rules Everything Around Me, and that was a huge awakening when transitioning to industry.
Quick disclaimer: my opinions are my own, all names have been changed to protect the innocent, and as with everything in your life, your mileage may vary.
Build on!
-Liz
Theme 2: Cash/Commercialization Rules Everything Around Me
Lesson 4: Always work backwards from what you’re delivering to a customer
Probably the most obvious difference in industry, is that everything you’re doing should be connected to a line of business. You should be able to draw a line from what you’re doing every day and how it will impact a customer, either an internal or external customer.
With R&D work, there is a direct relationship between the efforts now and how your company will be able to expand or improve their current offerings. This isn’t actually as straightforward as it may seem. Businesses can be complex with competing priorities and nuanced workflows. The key thing here though, is if you’re not absolutely sure how what you’re doing is connected to a line of business, ask.
If you’re on the frontlines, and you think that a scope of work is maybe a “nice to have” but not a “need to have”, then say something. Your job is to understand the product and project roadmap, how your pieces feed into that, and advocate for your science. Don’t assume that your manager and your manager’s manager understand the same things you do.
Lesson 5: Escalate early, escalate often
Now, this is something I learned working at AWS. One core part of the culture was escalation. I had a manager tell me during training “escalate early, escalate often”.
At first I thought that meant being a tattle tale, telling on people who were slow or not nice, but it’s not that at all. It’s not about the personal at all, it’s about the professional and reframing how you see things.
Your manager is your coach. If you’re having challenges or frustrations, don’t keep it all in and then at the end say “Well, we didn’t have X, Y, or Z, no wonder we couldn’t get this project done.”
You need to bring up issues and blockers and ask for help, support, and coaching. It is on you to escalate those, and not assume that the “higher ups” will magically understand the urgent and important issues. To me, this was a pretty big shift. It meant that if I had a customer call and was hearing feedback about a service or solution, it was on me to go and talk to the product teams, ask for support, and advocate for the technology, something I never thought I’d be deputized to do at a 200k+ person organization.
Lesson 6: if you show up with a problem, bring a solution (or three)
When you escalate blockers, escalate solutions.
This was a big learning for me. As a first time director many years ago, I sharply remember my first senior leadership staff meeting. In these weekly meetings we’d go around the table and give updates (aside, this is actually a sub-optimal way to run a meeting). At this meeting, my first one after being promoted to middle-management, it was my turn to talk, and I said something akin to “oh, we’re getting all these samples from customer X, based on our models, it’ll take us 6 months to run them, and we need the results in two months.”
The CTO, my mentor and manager, turned to me and said “Okay, how are you fixing it?” I was flabbergasted. I looked at him and stammered, looking around the room, and said something like “working on a solution is top of mind this week”. He said something curt like “Liz, next time you bring up a problem to the leadership team, you better bring a solution”.
I think I had to pick up my jaw from the floor, because I had a great relationship with my manager and in that moment saw it all flash before my eyes, thinking that I wasn’t able to sit at the Sr. leaders table any more. I had my chance and instead of responding with a clean answer, I stammered.
We grabbed coffee later and he said it was a great coachable moment. He directly told me that as the CTO his job was to set the precedent for the leadership team. If you’re going to come with problems, you come with solutions. You can’t just show up and winge at that level. It wasn’t personal, it was feedback for me, and to set a precedent for the broader team.
It’s also something that I’ve internalized: if I’m calling out problems, it’s not just “this is a problem”, it’s “here are three different solutions, here is why, and here’s my favorite”. This is also what tends to separate the managers from the true leaders. It doesn’t matter if you are an individual contributor, middle management, or CTO, one of the chief indicators of excellence is being able to explain problems and the solutions to your co-workers.
Lesson 7: This is not a zero-sum game
Reflecting back on the last story, a key part of what enabled me to learn and grow from that staff meeting, was that I had the trust and relationship with that CTO to know that he had my back. He wasn’t looking for ways to take me down. He and I were on the same team trying to do the best applied biotechnology we could.
This isn’t academia where we’re all battling for a few grants. There are strong interdependencies within industry, as a general rule. A rising tide really does lift all ships, and teams that succeed tend to bring others along the way. We’re all interconnected.
