Thinking on the management method of software company team

The company has been constantly on the restructuring of the organizational structure, so far has been almost 4 times adjusted. Also experienced 4 managers. Different managers have different management styles, and perhaps your performance in a team can be recognized by the manager's manager, but the other team is the opposite. Because the management style of each manager is different, the angle of attention to the business is also different. The team that has recently been feeling a little uncomfortable may not be accustomed to the kind of style in which everything needs to be managed. So I take this opportunity to talk to you about the management of the high-tech software team I know. Under normal circumstances can be divided into the following categories: Military management mode economic interest-driven legal identity law

Military management, if you meet a manager like this, he should be able to experience the pro, what things want to control in their own hands, always want to adopt a unified set of management methods to manage their own team. In fact, this kind of compulsive management skills may have just started in the new training process can be effectively implemented, but also allow the newcomers to quickly integrate into the team, but not suitable for long-term use. Will let the old staff feel that there is no devolution to them to do things. This will make the boss and the staff will do more difficult, pure thankless type of boss.

The economic interest-driven approach should exist in very many companies. Wages are sent in two parts, base salaries + performance pay. This may be more applicable in a service company or sales team. But the technical team is not very suitable, because many of the technical staff may be pursuing their own ability to create code and online trouble-free or on-line usability, and so on, of course, the economy is one of the areas they consider, but not the ultimate goal. In fact, they are more in pursuit of their own inner sense of accomplishment. In themselves they have such internal incentives enough to support them to do a lot of things, and if you adopt an economic-interest-driven approach, it turns this internal incentive into an external incentive. When the company no longer pays for the lack of bugs, they think it is unfair and will choose to leave such extreme acts.

Identity law, in fact, this way is more suitable for the technical team, technical team relative to everyone is very simple, interpersonal relationships do not have so much infighting. In fact, as long as we can achieve a unified consensus, for a common goal to fight. They can achieve a great sense of accomplishment in the design of a software or scheme. Only the team can federative, in order to let everyone have a sense of belonging to the family, the team can create greater value. We don't discord to do things.

In fact, for all of us, as a technical staff, we do not like management too rigid, dogma, the need for a relatively loose, free atmosphere, so that their creativity can be played out. If you do anything you always feel that there is an invisible hand behind you, then you will be very sad, everything will be cautious, afraid of failure on the line, afraid of the bug, things will be timid. In fact, meet this manager, you can not care too much about his management style, only need to handle things well, good communication is the premise. The above is just a little bit of the experience of the change, I would like to remember.