Those pits for finding technical partners

For non-technical entrepreneurs, there is often an illusion. For example, we need a CTO to start a business, or, a programmer. If you were that CTO or programmer, would you go? What if you were paid handsomely in the first place? My advice: don't go because it won't be long before you're out.
The immaturity of the founder and the strong position in the team can make a good technical partner feel at a loss. Several typical characteristics

of founders with sales background : performance-oriented, work results are linked to salary, low base salary; low awareness of technology, lack of ability to judge workload and technical difficulty; lack of trust in people, more belief in people Games and checks and balances, not trust and cooperation; doing things without a plan, one idea a day; working with such people is a test of emotional intelligence. Let’s talk about performance orientation first, which basically doesn’t work in the technical field. Because there is a long chain from technology to sales performance, there are operations, marketing, promotion and other links in the middle. Even if technicians have a sense of ownership, they are often helpless, or they will be said to be nosy. Nowadays, many Internet projects do not make money in the first few years (the channel model - the project that accumulates users is like this), and it is even worse to link with performance and revenue. In the assessment of technical personnel, I generally tend to complete the assigned tasks on time, quality and quantity, and this task may often be refined to a day or a week: communicate and follow up at any time without a clear quantitative indicator. Because the founder is the maker of the rules, the technicians have to adapt, and if the dissatisfaction of the technicians accumulates to a certain extent, they will let go. Low awareness of technology is a common phenomenon. The example I gave at the beginning: there is only one CTO, mainly referring to this kind of person.













For example, in the order management system of e-commerce, it is easy to query according to the price range of the order, but the technical difficulty increases sharply if the query is based on the level of the user to which the order belongs. Simple, but if it exceeds 1 million, this piece has to be completely rewritten. The original work task that only takes 2 days may become 2 months.
There are also promotions like seckill activities. If the load is not considered, the technical difficulty and workload are less than 10% of that when the load is considered.
Bosses who don’t understand technology may communicate with technology like this. Look at this coupon function, the e-commerce website has it, why haven’t you done it in two weeks? Lack of respect and trust in technical personnel is a fatal mistake that many young entrepreneurs are prone to make.

You let your boss trust you unconditionally? Unless you are Lei Feng.
If you blindly meet the boss’s schedule requirements and work overtime, you are likely to owe a technical debt. After a year, the system will not be maintained. No one dares to make a move on the system, and the entire system will have to be completely redone. At this time, the boss may want to change a group of people and develop version 2.0.

For the kind of salesperson who has one idea a day, it is not so much the ability to respond quickly to the market as the lack of foresight of the market. Because of the change in demand caused by this kind of head-beating, technicians are often complaining. In the IT industry, I heard that one of the major reasons for leaving is the repeated changes in business requirements.

Let me criticize the technicians again.

The background of technical personnel
can be divided according to the type of company:
from foreign companies; from
large private enterprises;
from small and medium-sized private enterprises
; Let’s talk about foreign companies first. Many foreign companies say that they are research institutes and R&D centers located in China. Just like IBM's advertisement in Chengdu Shuangliu Airport a few years ago: Smarter Earth is just a marketing tool. In fact, they are just fooling those graduates.




There are generally three types of development centers of foreign companies in China: overseas outsourcing (customers are Europe, America and Japan), domestic and foreign outsourcing (projects), and enterprise insourcing (such as IBM's internal OA system, not the company's core products).
If it is overseas outsourcing, this kind of work usually starts from the detailed design, which means that others with technical content such as architecture design and outline design have completed it.
If it is a project against Japan, it will be coded directly, including the method naming, others have written it, and it is purely a software factory - a code worker. At that time, I saw a Japanese project with the file names 201.jsp and 202.jsp, and I immediately became petrified.
But you have to admire the Japanese's accomplishments in the field of software engineering: they can decompose the work to be done by college graduates, and the project progress can be controlled within 10%. At present, only the manufacturing industry can do it.
And these project managers, the main job responsibility every day is to update the Excel schedule, and then submit it to the customer by email.
You say, if you meet these halo technicians or project managers, you can resist the temptation? And the other party is from a famous school, because these foreign companies generally only go to famous schools to recruit.

Think about domestic software project outsourcing, Party A tells you, I want xx function, you can make it for me in yy weeks, how much money does it cost? After the two parties' prices have been blended, Party B starts the construction. During the period, I don't ask, Party A will accept it after yy weeks. Is it dumbfounded?
Software is essentially an abstraction of business. If Party A does not sort out the business, how can Party B abstract (transform it into a software model), not to mention the implementation of the technology behind it.
Many Party A (startup companies) think that software outsourcing is the same as doing SPA. If so, the probability of failure is basically above 90%.

Generally, there are two modes of software development quotation: quotation
according to the software development process: demand document + rendering + function development
volume
Mitigate project risks.
But the problem is that, without seeing the runnable program, Party A generally takes the requirement document and renderings seriously; in
addition, some Party B write the requirement document very abstract (find a universal requirement document template to copy), the core The requirements are scattered in huge redundant text, and it is difficult for Party A to judge that the requirements in the document are what they want.

Quotation based on functional requirements = functional capacity * 2, which also shows that development only accounts for about 50% of the workload, and the other 50% is business research, demand analysis, product design, and testing.

The above also mentioned one: software insourcing, as well as domestic and foreign outsourcing of foreign companies, and to do it well, in addition to having excellent technical personnel, it also requires excellent technical management personnel: proficient in software process management.
Next, I will talk more about software process management, because it is the Sun Tzu Art of War of software management.

CMM5 (Software Development Capability Maturity Model), and the RUP software process management methodology matched with CMM3. This kind of outsiders is difficult to understand, so you can treat it as the SOP (standard operating procedure) of the manufacturing industry.
Domestic software outsourcing giants generally need to spend money to do this kind of certification, just like the current agricultural products need green food certification in order to sell at a good price.

Not to mention the CMM5 specification, its specification document can probably be printed into several textbooks. The RUP process is a set of IBM software development SOPs, and it is also a magnificent system. Anyway, I have not fully understood it after three years of research. Later, IBM pushed Agile RUP, which is the tailored RUP. The thing is, there are several people who are capable of tailoring.
I still like RUP very much. For complex business in some traditional industries, I don't see a more effective methodology at present (don't talk to me about SCRUM, this is not used to manage demand).
The maturity of software engineering is far worse than that of the construction industry, with an estimated annual increase of less than 3%. I've been in business for 10 years and I don't feel like developing a module 10 days ago is now 5 days. The bottleneck of software productivity lies in the non-standardization of business requirements.

There is also a kind of people who say that they know the agile process, but in fact they are still using the waterfall development process.
Whether he uses an agile process or not, depends on whether he pursues perfectionism when releasing the version: he must wait for this feature to be developed before it can be launched. Many people have this similar complex: no online payment, no refund function, no online customer service, how can an e-commerce system be counted?
Agile focuses on iterative development, but this kind of person understands it at first glance, but forgets it as soon as it is done. Standing morning meeting, sticking todo on paper, that is not called agility.
Agile processes are built on trust and cooperation, otherwise the morning meeting will become a critique.
Also, the team has 1 senior, 2 intermediate, and 10 junior, don't stress about agility, those newcomers will be forced to vomit blood.

I have talked so much about software process management (note: not project management), but I actually want to say that those who have been using this heavy software development methodology, or the methodology of a professional software company, let this technology Is it easy for managers to abandon their martial arts when they come to an entrepreneurial company, give up aircraft and cannons, and replace Xiaomi with rifles?
Moreover, when the project starts, when you see those high-level documents, you may still have this illusion: I finally found a technical master, although you basically can't understand it.

Another point that cannot be ignored is that he came from a large software company. In the past, he faced a group of demand analysts who knew both business and technology. They were responsible for collecting and sorting out customer requirements. Colleagues in all departments are computer illiterate, and basically have no software abstraction ability for business. Communication will test the IQ and emotional intelligence of technical partners. If there is a lack of empathy, technical staff will complain in their hearts: this group of SBs . Over time, the sectoral Cold War is on the verge of breaking out. The reason why I bring it up in particular is because the technical gurus generally have low emotional intelligence.
Elevating a tech genius to a tech manager is one of the most serious mistakes founders make.

In addition, for knowledge-based employees like software companies, if the Taylor management method (industrial management) commonly used in traditional industries is used, such as strict attendance and leave system, it will seriously dampen the enthusiasm and creativity of technicians. Daniel is a night owl. If the founder does not understand the culture of the technology-based company, it is easy to have a communication gap with the technical partner.

There is another kind of person who is more popular with start-up companies, and is born in BAT.
I heard that in the first two years, as long as it is from BAT, investors will follow up and ask, I will give you 3 million first, and you can start a business. Just make it a joke.
Now there are thousands of BAT technicians, and there are hundreds of people in any product line. Except for a few directors, senior managers, and technical managers, most of them are screws, and they may drill deep into a certain piece, but technical Not enough breadth.
These tech giants are accustomed to technology implementation thinking (executors) rather than solution thinking (managers). If you don't come up with something technical, or use someone else's ready-made cloud services, it's a sense of achievement.

Some time ago, I saw a resume of Lipin in the Chengdu area with a 25k CTO. The last entrepreneurial project was community O2O, one of which was to make friends in the community. When talking about the technical feasibility, I wrote (original): Demonstrate mobile instant messaging, text, picture, voice, and video solutions; demonstrate the role of LVS in the project, and determine the number and cost of servers.
If our Boss encounters such a technical person in charge, it is estimated that he will cry. Fortunately, others just demonstrated, not developed. Anyway, I can handle these functions with 100,000 (there are corresponding SAAS and IAAS cloud services).
I guess this is the high-end talent of BAT: he has done instant messaging solutions for large-scale high-load, high-availability, and massive users.

Small workshop-style private enterprises, I will not complain. There is no shortage of tech giants in such companies, but they are all reckless heroes. If you've been in a big company, it's perfect: you can bend and stretch.
I won't talk about state-owned enterprises, and technical personnel should not be seriously affected by the bureaucracy of state-owned enterprises. But there is this habit: the operation, marketing, and customer service departments must be pulled together for any nonsense demand.
In fact, there is a way to break the situation: do it again, and then correct it if it is wrong; actively seek advice from relevant departments on key needs, pay attention to face-to-face, not email + CC.
As we all know, the survival rule of state-owned enterprises is to seek no fault but no fault. To put it bluntly, you are still afraid that someone will punish you.

What I said above seems to be somewhat professional, and I will talk about a few more easy-to-understand pits.
Headhunting recommendation
Recommended by headhunters, it may be the best choice for some mature companies. If you recommend a CTO to an entrepreneurial company, be careful that he will lead you to the pit.
What a headhunter can do is to recommend a group of candidates, and whether they can find the one who is really suitable, the premise is that the entrepreneur has a reasonable positioning of the CTO, and then the matching identification. Just like the HR of a well-known company, all they can do is collect resumes, and they need to be screened by an interviewer.

If an entrepreneur in the early stage also asks the headhunter to find a high-level CTO, it may make the company die faster: cost overruns and schedule overruns.
It is planned to have 10 million users in three years, but whether the company can survive with 100,000 users in the first year is still a problem.
I will not talk about the problems that may arise after finding a CTO that I think is suitable for me: during the
product development period, the CTO's technical vision and management capabilities are limited, so it is impossible to achieve product goals with limited funds, manpower, and time. ;
During the business operation period, the technology is in a state of maintenance. Because of the unreasonable positioning of the technology in the early stage, the equity ratio was improperly granted, and they have been thinking about how to get the CTO out of the game.
Many founders have taken a long time to realize that their company was not driven by technology; at the
same time , Because of the stable business, the cost of the original technical team is too high. If you want to start working on the technical department, and the CTO who lacks team support and technical challenges, his career development will come to an end.

The economic status of technical partners The technical partners are
doing well, and most of them come from rural areas and have poor families. Moreover, because of their own circle and social class, the family background of the object they are looking for will not be much better. After 5 years of working, it is generally the age to buy a house. Saving money to buy a house or monthly payment is a real pressure.
And entrepreneurial men like inspiration, the general economic situation is not much better. Did Wang Jianlin say he was starting a business when he was doing e-commerce? . Entrepreneurs give a blank check - equity. The probability of cashing out is less than 5%, and technical partners usually receive 1/3 to 1/2 of their salary. If the project does not see hope for half a year or a year, it is time to test the humanity of the technical partners.
Besides, if someone else moves to another place, their salary may triple, and they are stable and have an identity, and they can immediately solve their immediate needs. In addition, how do you know that when others are professional managers, they must not be able to obtain equity or options?
Many technical partners had plans to retreat when they could not see the prospect of the project or the economic pressure was too great.

Therefore, looking for a technical partner, if the main goal is to have excellent technical resources, rather than reducing costs, I suggest that you give enough money and don't let him be distracted.
If the funds are abundant and the partners are happy not to take shares, then pay high wages and become employees.

Using technical partners as product managers
From the perspective of the software development process, business research, requirements analysis, prototyping, and the outline design and prototype documentation of its deliverables are all tasks that product managers should do. Technicians get these deliverables and start developing features. The completion of these deliverables will probably take up more than 30% of the project’s man-hours.
There should be more than 80% of technical partners who do not have product design capabilities. This is not a problem. The problem is that they do not realize the shortcomings of their own capabilities, resulting in unexpected or unwillingness to recruit a product manager.

I highly recommend against a CEO looking for a product director who is on the same level as a technical partner. Communication and collaboration can be a big problem. In addition, because it is difficult to rationally divide labor between products and technologies, disputes over product decision-making rights will lead to serious internal friction. For example, does the UI designer belong to the product department or the technology department? And what about big data analysts?
If the founder is from a product background, after the product is defined, you can temporarily not find a technical partner, just find a programmer to work.

The capacity bottleneck of technical partners is
not all technical personnel can keep up with the company's growth. At different stages of the company's development, the technical partners' capacity requirements are different.
At the start-up stage, a technical partner who can write code is enough. With the rapid growth of users, there are requirements for its software architecture design capabilities;
with the growth of the company's business, there are requirements for its technology foresight and the management capabilities of medium-sized technical teams. At this time, let's call it technical director;
When the company develops to the point where it needs a real vice president of technology, it needs to be forward-looking in the industry structure, such as when to invest what resources to strengthen which technology, and excellent business/technical balance ability, maybe the original CTO/ The role of CIO is also incompetent; of

course, at each stage, technical partners can look for better technical personnel than themselves, but the management work still cannot be replaced by someone, do you expect him to be a good person?
When introducing technology partners, founders should be aware that there may be such problems and develop a win-win technology exit mechanism. Otherwise, after the CTO leaves, the code is deleted, the database is destroyed, and the server is formatted, which is a tragedy.

If you are not sure about the capabilities of technical partners and are concerned about the exit mechanism, it may be more reliable to find a temporary technical team-a company that provides technical incubation services.
After releasing the first version of the product and bringing in capital, you have enough leverage to attract good technical partners.
When the company is still a diaosi, don't expect to attract Bai Fumei; when you grow into a towering tree, the phoenix will come.

Please indicate the author when reprinting:
Chen Zhiwu http://weibo.com/zwchen
Personal WeChat ID: zhiwuchen