The real dilemma facing tech-focused business schools: Scientists now understand business, but why haven't their actions changed?
I once met a founder of a robotics enterprise, who holds a doctorate in engineering. After starting his business, he realized the importance of commercial capabilities and went on to study business administration. During our communication, I could feel that his cognition had indeed made breakthroughs.
Later, he hoped to communicate with the CEO of a listed company to seek cooperation opportunities. Since I knew that CEO, he sent me a message, which roughly meant: Could you help arrange a meeting so that we can get to know each other, have a chat and a meal together? After receiving this message, I did not know how to help him.
There is a huge amount of work between knowing a CEO and facilitating a valuable industrial cooperation. Why would the other party want to meet? In which business scenario could the two parties cooperate? What judgments need to be verified in advance? What reasons should I use to introduce this, and what information can I endorse? None of these points were mentioned in that message. This incident made me rethink a problem that is easily ignored in business education: Even if a person has acquired commercial cognition, why does he still follow his original way of acting in real scenarios?
It also pushes the value of technical managers to a deeper level: Are we just supplementing knowledge and finding resources for scientists, or building a sustainable operating organization for a technology?
I. A Dinner Invitation Message Exposes the Unfinished Cooperation Design
The problem of this founder cannot be simply attributed to his poor writing of messages, nor can we judge all his commercial capabilities based on this single scenario. But in this request, he turned a cooperation that required careful design into a meeting that only needed to be arranged. He had already decided who he wanted to meet, but he had not yet figured out why the meeting was worth holding and what progress could be made after the meeting. This means that he handed over all the work of defining cooperation opportunities, judging the other party's interests, and organizing communication topics to the introducer.
The introducer also faces another cost: credit. If I forward this request to the other party, the other party is very likely to interpret it as: I have judged that this matter is worth discussing, and at least confirmed that it is related to his business. If I do not have sufficient materials, this introduction will need to use personal credit to fill the gap in commercial information. Relationship can reduce contact costs, but cannot replace the reason for cooperation. This is also why having a contact in the address book is completely different from having a real customer opportunity in hand.
From getting to know each other, to the other party being willing to meet, to having relevant personnel in the other party's organization take over the matter, invest resources, and assume responsibility for the pilot project, each step has different thresholds. A single approval from the CEO may not automatically generate the budget of the business department, the verification arrangement of the technical department, and the cooperation of on-site personnel. If the cooperation plan has not yet been formed, the higher you send the request, the more likely you will get a friendly reply of "we can learn more about it", and then the matter will stop at the lower level. What really needs to be prepared is often a page of cooperation suggestions that allows the other party to make judgments: What business scenario do we have a preliminary hypothesis for; what value the technology may create, and what evidence is still insufficient; which position do we hope to verify with first; what do we plan to verify in the next step; what both parties need to invest, and to what extent can we decide whether to continue the cooperation.
These contents do not require entrepreneurs to know all the answers in advance. It requires entrepreneurs to organize the unknown into a problem that is worth verifying together. In this way, the meeting has a clear purpose, the introducer knows exactly what he is introducing, and the other party also has a reason to mobilize his internal team.
II. Cognitive Change Is Only Part of Capability Formation
After years of working in business education, I am increasingly wary of an overly smooth assumption: as long as a person understands customer orientation, he will naturally act in a customer-centered way when facing customers next time.
Reality is often not that smooth. A person can agree with the idea of "understanding customers" in class, but when he returns to the actual scene, he will still talk about his own technology first; he can understand that "cooperation requires win-win results", but when sending a request, he will still only put forward his own needs; he can know that "an organization needs authorization", but when encountering important decisions, he will still take all judgments back into his own hands.
There are at least three levels here. Knowing what is important is cognition; being able to identify and take actions in specific situations is action capability; only when you can continue to do so without reminders can you form a stable behavior pattern.
Wood and Neal's research on habits points out that repeated behaviors will form associations with situational cues; new goals or understandings do not necessarily directly rewrite the formed responses. This provides a mechanism for understanding the phenomenon of "understanding but failing to achieve", but we cannot diagnose a certain entrepreneur as having a habit problem based on this. The real gap may also come from not knowing the sequence of actions, lack of on-site feedback, or no time and organizational support.
Therefore, to change behavior, we need to further ask: Facing this cooperation request, does he know what to study first, who to verify with, what materials to prepare, and what scale of next step to propose? When the other party does not respond, can he judge whether the problem lies in the value, evidence, timing, or that he has found the wrong person? These judgments can hardly be completed only by remembering the four words "customer orientation".
Training transfer research also divides the application outside the classroom into two tests: Whether the learned knowledge can be applied to work, and whether it can be used continuously; the research also discusses the influence of trainees, training design and working environment. For science and business schools, the problem lies here: if the assessment only stays at whether the trainees understand the content and whether the report is complete, the cognitive progress will be prematurely regarded as the formation of operating capabilities. A deeper misjudgment is that all the capabilities required by the enterprise are included in the personal learning tasks of the founder. Even if this scientist can gradually change his behavior, the enterprise cannot wait forever for him to become the product leader, sales leader, organization leader and financing leader at the same time. Personal growth has its own speed, but the survival of an enterprise has deadlines for cash flow, delivery and customer windows.
III. Productization Covers the Whole Process of Customers Adopting the Technology
An important challenge for scientists to start a business is to turn their achievements into products that customers need. But the phrase "what customers need" is also easy to be understood too superficially. Customers may admit that the technology is advanced, admit that the problem exists, and even be willing to watch the demonstration, but still refuse to make a purchase.
Because between technical value and adoption value, there is still a set of operation calculations. Take robots entering industrial sites as an example — this is a theoretical explanation, not an experience that has occurred in the above-mentioned enterprise — the performance advantages need to be put into the actual working conditions: whether it will change the existing process, whether it requires shutdown for transformation, who will resume production in case of abnormality, who is responsible for maintenance, and whether on-site personnel are willing to use it.
In addition to the procurement price, there are also costs for integration, training, downtime, maintenance, and liability for failures. The technical gains may be offset by the cost of organizational adoption. What is more complicated is that these benefits and costs do not necessarily fall on the same person. The management expects cost reduction and efficiency improvement, but the on-site person in charge first bears the risk of production interruption; the R&D department is willing to try new technologies, but the procurement department needs clear specifications and delivery responsibilities. For a start-up enterprise, proving that the performance is feasible, is two different things from getting these stakeholders to jointly promote the matter.
This requires someone to complete a kind of work I call "commitment design": Transform the value that technology may create into the next step that all parties are willing to invest within clear boundaries. It at least needs to clarify: who is responsible, what to invest in, what evidence to use for acceptance, how to control losses in case of failure, under what conditions to expand cooperation, and under what conditions to stop.
A good design does not necessarily strive for a large order from the very beginning. Sometimes it is a working condition verification, sometimes it is a test with clear boundaries, sometimes it is to confirm that cooperation is not suitable at the current stage. The key is that each step can reduce the uncertainty of the next step. If this work is missing, entrepreneurs will easily keep introducing the technology, keep looking for higher-level relationships, but fail to increase the specific commitments that customers are willing to undertake.
Financing has similar problems. What the technology has proved, what the customer has verified, and which risk the next sum of money is going to eliminate, need to be explained separately. Capital can provide the time and resources required for verification, but it cannot automatically complete the verification for the enterprise. When no one assumes the operating responsibility, increasing funds may only prolong the repetition of the original actions.
IV. Technical Managers Need to Be Reclassified According to Their Assumed Responsibilities
The value of technical managers should be understood in the above-mentioned gaps. The relevant policy interpretation of Beijing in 2022 has covered the work of technical managers to technology productization, commercialization, resource organization, and helping scientists find partners and form entrepreneurial teams. It can be seen that when understanding this profession, we cannot only focus on information matchmaking.
But on the other hand, we cannot require every technical manager to become a CEO. I prefer to distinguish three types of work according to their actual responsibilities. The first type is to facilitate transactions. Identify supply and demand, find partners, and assist in technology licensing or transfer. This type of work has independent value, and its boundary can be a clear transaction.
The second type is to organize transformation projects. Coordinate technology, intellectual property rights, verification, industrial partners and delivery arrangements, so that an achievement can go through multiple links. The responsibility extends to the agreed project milestones.
The third type is to build enterprises. Participate in selecting application directions, defining products, developing customers, organizing teams and arranging funds, so that an operable entity can gradually grow behind the technology.
The three types of work can overlap, but they cannot be handled with the same set of capability requirements, remuneration methods and assessment standards. The business complementarity required by scientists to start a business mainly occurs in the third category. Some people are suitable to serve as CEO, some are suitable to assume COO responsibilities, and in some stages, in-depth operating partners can take on clear tasks first.
Becoming a co-founder means that he has to jointly assume the trade-offs. Technology can develop in multiple directions, but which one should the limited funds be invested in first? A customer is willing to try the product but puts forward a large number of customizations, should we accept it? The most valuable subject for R&D conflicts with the products that must be delivered in the near future, how to arrange it? These problems cannot be solved just by translating technical terms into commercial language. They require someone to continuously organize evidence, coordinate interests, and take responsibility for the actions after the decision.
This is also the difference between a mentor and an operating partner: a mentor can put forward valuable suggestions, while an operating partner needs to turn the suggestions into product priorities, personnel arrangements, customer promotion and cash expenditure. Its scarcity lies in the ability to organize actions with incomplete information and bear the feedback brought by the actions.
V. Whether Complementarity Can Be Established Depends on Which Decisions Scientists Are Willing to Hand Over
Finding a person with commercial experience does not mean that business complementarity has been formed. Excellent managers in mature enterprises are often good at improving efficiency in existing products, customers and processes. However, early hard technology enterprises may not even have determined the application direction, customer budget and delivery boundaries. The experience required in the two stages is not exactly the same.
When judging candidates, we should ask less about how many people they know, and pay more attention to whether they have done these things: find specific scenarios when the demand is vague; modify products based on customer feedback; organize the process from pilot to delivery; deal with the conflict between technical commitments and resource constraints. We should also see how they face bad news. Can they truthfully bring back the customer's rejection, can they suggest suspending a certain direction, can they explain the reason when there is no progress, instead of constantly covering up old problems with new relationships.
But the real difficulty may lie on the side of scientists. If the operating partner is responsible for customers but has no right to adjust product priorities; is responsible for cash flow but cannot participate in expenditure decisions; is responsible for the team but cannot clarify post and delivery responsibilities, then he only gets the tasks, not the power needed to undertake the tasks. If scientists verbally accept the business logic, but all key decisions are still handled entirely according to their personal scientific research preferences, the complementarity will degenerate into "someone helps me sell the technology". Handing over part of the business judgments to complementary partners is the most important behavioral change in scientists' entrepreneurship.
This does not mean that scientific research judgments must obey short-term sales. Both parties need to clarify: which technical boundaries cannot be broken through, which application directions can be verified, who is responsible for which decisions, and how to deal with major differences. The co-founder relationship should at least match responsibilities, authorities, continuous investment and income arrangements. Giving a title but no authorization, giving equity but no mechanism for joint work, are not enough to form real complementarity.
A more reliable matching method is to jointly promote a real project first. Only by experiencing customer rejection, insufficient resources and priority conflicts together can we see whether the two parties can cooperate. A pleasant dinner cannot reveal these things. At the same time, we cannot transfer all business uncertainties to technical managers. Verification costs still need to be covered by funds, and operating positions also need basic support. Only requiring a share after success and long-term unpaid investment will easily screen out people who can undertake operating responsibilities, leaving only those who prefer short-term matchmaking.
VI. Science and Business Schools Should Connect Action Training with Team Building
Looking at science and business schools from this perspective, courses are still valuable, but they need to serve a more complete capability formation process. The first level is to help trainees change the way of explaining problems: understand how customers, organizations and capital make their respective judgments. The second level is to train actions around real projects: conduct a demand interview, prepare a cooperation proposal, promote a bounded verification, and then modify the judgment according to external feedback. The third level is to identify who the enterprise is missing, and how to get this person to truly participate in decision-making.
The I-Corps program of the National Science Foundation of the United States provides a specific reference: the team includes a technical leader, an entrepreneurial leader and an industrial mentor, and the training emphasizes carrying out customer discovery with potential customers and partners. It cannot prove that a certain team configuration is bound to succeed, but it puts role complementarity and real business contact into the same training process.
For science and business schools, a more worthy teaching unit is also "a team in a real task", rather than just founders who attend classes alone. The teaching staff needs to have people who can observe on-site actions, not just those who can teach frameworks; the assignments need to include the cooperation materials actually sent and customer feedback, not just the organized roadshow reports; the assessment needs to observe whether the trainees can adjust their actions according to evidence, and whether they can actively repeat effective actions in the next similar scenario. Changes at the team level should also be included in the assessment: whether there is already a clear person in charge for product definition, customer verification and business promotion, and whether the person in charge has the corresponding authority.
If trainees only become more and more good at talking about business in class, but never complete an effective verification, nor form a business division of labor, the course needs to continue to face this gap. Science and business schools and transformation platforms can participate in finding operating partners, organizing joint training and stage verification. But when the cooperation enters the enterprise, it is necessary to gradually hand over the decisions and responsibilities to the entrepreneurial team. Otherwise, the more the platform can help, the more likely the enterprise will fail to form its own operating capabilities.
Back to that robotics founder. He has been willing to step out of the laboratory, learn business knowledge, and is willing to seek industrial cooperation. These progresses are worthy of recognition. But the next step of capabilities will not be formed automatically just because he has met more CEOs. It is reflected in: Whether he can sort out a wish into an opportunity that others are willing to judge, promote an opportunity into a bounded joint verification, and then configure the capabilities required in the verification process into his own team.
Therefore, the support system for scientists' entrepreneurship needs to answer a more specific question: In addition to helping scientists understand business, have we ensured that there is someone in this enterprise who is continuously responsible for business actions? The long-term value of technical managers as operating partners lies in this continuous responsibility. Education can help people see gaps, training helps people change actions, and complementary organizations allow enterprises not to wait for one person to learn everything.