Thinking about entrepreneurial teams: cannot be technology-dominated

"Vini, vidi, vici? (I came, I saw, I conquered) "-- CAESAR (stabbed to death in 44 BC)
The above sentence should be in line with the mood of the entrepreneurial team that is currently surging. Today, I know how cool the people who say this sentence were, but they didn't die. It seems that most entrepreneurial teams under the web banner are composed of technical personnel. I am also a technical source, so I think it is particularly necessary to discuss the issue of entrepreneurial teams dominated by technical personnel.
A The ignorant is fearless, but sad
A typical startup scenario for a technical team is as follows: to see a very popular website, then a few people will know how all technologies should be done (of course, we know that the systems of 10 thousand million users and 10 million users do the same thing in a completely different way ), so I wrote a few pages and thought "We can do it too! ". Then, drink and get on the road ......
Let me say something. The first question is: have you ever performed website operations (not code? Do you know who and what resources are needed to operate a website? (If you only need to find a few edits to the cloud, there is no hope.) You have never done any of these things, and you have not been very good at inquiring about it to learn and think about it. Are you sure you can do it? 1.3 billion people have the ambition to have only one country in the world!
If you still don't know what you will face and what problems you need to solve, you can understand that success or failure is not a few weeks in the past. All people will tell you that technology is just a small piece of technology that requires so many resources and considerations for website operations and entrepreneurship. So what else do you have in addition to technology when you get started? A lot of things are lacking.
B cannot be technically dominant
Naturally, Program Personnel must be technically dominant. Even if there are others in the team, their opinions and opinions will be marginalized (this problem will be discussed later ). If the problem we want to solve is something with a definite need and the goal is only to implement the system technically, this method is of no problem or even very professional. However, our goal is to design something (the demand is uncertain and will change) and operate it (not to run it, non-technical concepts ), you have to consider the problem from a different perspective. In particular, leaders must go beyond technical thinking. Otherwise, the final result must be "What Programmers think is the best ".
C-train of thought, details
I often say that the highest verbose is about the design details, rather than the implementation details. You can implement the required details in any way, except for programmers who don't care about the implementation details.
Programmers may discuss a specific detail and implementation method carefully for half a day and rebuild your system, but for users, this correction is not worth mentioning for use, the value is almost 0. So it is not worth doing this, but programmers cannot accept imperfect solutions, so it takes a lot of time to do something meaningless.
Programmers will stick to a lot of details, but it is not a bad thing, but it is troublesome to get rid of the details that users are concerned with: You are making useless improvements and users are still complaining. When the entire team focuses on technology, the bias in decision-making is obvious and cannot be noticed by themselves. Only the market will eventually tell you the error.
D. Do nothing.
This proposition is big and has nothing to do with programmers, but it is especially serious in the programmer team. Q: If you are the boss of this programmer team, will you go to code? You said yes. CEOs of all cool companies in Silicon Valley are personally coded, at least in the initial stage.
First, the boss coding is not a prerequisite for success, not a sufficient one. It's a bit tricky; second, the gang did the code after doing what the boss should do, or else it won't be mixed up today.
I would like to ask the boss who is coding all day and who is going to think about strategic issues? Who contacts people and resources? Here, Inaction means two layers: the first layer, you must spare time and energy before you can think about it to discover ignored problems. This is not very important, it is quite important. On the second layer, as the boss, you do specific things. If you do not do well, no one will blame you. No one will raise any objection to the decisions you make ...... Do you think it's bad?
So how can we grow from a technician to a qualified boss? I don't know (or I won't be able to make a fuss here). I can only provide a few reference principles:
1) You cannot be a technical leader
Programmers usually use the oldest and best-skilled people as leaders, but it seems that the leaders of the martial arts school may not be the most martial arts. The most nose is generally hidden behind the scenes, they are not suitable for cooperation with the boss.
I still cannot fully understand inaction, but it is worth thinking about because we are all Chinese and this culture is not available in Silicon Valley.
2) raise requirements and problems and guide the solution. You cannot give the conclusion.
As I mentioned earlier, no one can criticize you if you have done something wrong. No one is opposed to what you say, but you cannot understand all the information about many things (because you are not responsible for the specific work) but if you make a specific decision on behalf of the person who does the work, then there is a possibility of mistake. It is right for everyone to think and decide at their respective levels and in their respective fields. What you have to do is to look at the operations of the entire legion, think about what else you have not thought of, and guide the improvement of a piece of work, all of which are hidden jobs, so it doesn't matter if you don't do it, so it is always ignored by many people, so there must be many losers.
3) Balance small teams in the team
A little knowledgeable, it will certainly attract a few non-technical personnel. But further, you must think about their positioning. First, the boss may not consciously use technical thinking, but speak different languages with them. Second, the boss's cronies are the group of technicians. Therefore, they are isolated and marginalized. However, from a higher perspective, technology should be a small piece, and planning and operation are the most important.