An Interesting Story
Today, I stumbled across this thread on Twitter from Peter Reinhardt. In this thread, he recall an experience as CEO of Segment during its growth period.
The premice of this story lies in the fact that the rapid growth of this start-up was stalling and, given its short existence, it would soon become threatening to the future of the company itself. Customers were being attracted by competitors’ solutions, their product was starting to lag behind the competition, and the team was getting demoralized. Peter, the CEO, had a feeling that the ship was heavily taking water and the point of no-return was nearing.
Then came the electric shock in terms of a frank discussion between him and another employee: the staff was inefficient at their job because they didn’t know what they should work for! This came as a shock to the CEO as he thought the mission of the company was clear to everyone, and each employee already knew what to do. It turned out that it was actually quite the opposite and he was almost the only one who know which problems needed their attention, let alone knowing how to solve them.
Summoning everyone into an honest all-staff meeting, he exposed the problems he saw as being the important ones, without knowing how to pull it off on time to save the company. This had the effect of clarifying the situation to all the staff and this newly gained sense of clarity subsequently motivated everyone to find effective solutions to the real problems that the company was facing. This turned out to be a success (suvivor bias?) and Segment has been thriving since then.
Peter explains this by the fact that his was trained as a programmer, aka a problem solver, who thrived at solving problem by himself and only sharing the solution. Instead, what he needed to do instead as a CEO was to identify and clearly explain to his team what the problems are and let them figure those out by themselves.
I invite you read the Twitter thread by yourself to get more details and insights from Peter himself.
Parallel with Academic Life
This story and its conclusion somehow resonated with me as this is a concept that I’m still battling in my academic job.
On one hand, the academic training (PhD then PostDoc then junior Lecturer) heavily emphasises on the individual training, booster-rocketing the future Principal Investigator (PI) into the expertise stardom in a (narrow) topic. The main if not only human resource is the researcher themselves and they have to come with solutions, then report them confirmed as the solution for the stated problem. Yet, when it comes to actually creating and sustaining a research team, the PI should be the last resource used to actually find and implement the solution since their time is so valuable (writing lecture material, managing courses, interacting with students, taming their emailbox 🙁 supervising student projects, writing research proposals, creating research contacts, surviving and running the university admin, repleneshing the coffee machine…). Like the CEO of Segment at the time, the PIs should instead focus on identifying the important and relevant problems (i.e. research questions), communicate these clearly to their research team and let them work on it!
This is often frustrating as we are often drawn into this advanced technical world by the technique itself. I’ve been personnaly drawn into engineering to learn how systems work and design/build them according to my problem solving skills. However, I acknowledge that I no longer have had the time for many years already to do everything myself and just delegating tasks is not sufficient, nor effective either.
Maybe this is a concept I need to implement as well.
And what do you take out of this story? How do you think academics could be running their mini-company which is their research group? Is there another academic or research model out there?
Thank you for reading. See you tomorrow.