Five Google Engineering Mistakes

Original author: Michael Schroepfer
  • Transfer
Michael Schroepfer (Facebook vice president of engineering, formerly Mozilla vice president of development) read Google’s programmer survival tips and decided to briefly comment on some of the key bugs of this engineering management company.

First of all, he says, important points should be noted. Google is an incredibly successful company. She invented and put into production many important computer science concepts.

With 1,500 employees, Google had more flexibility and less bureaucracy than most startups for 200 people. At any size, Google was the best place to work among companies in its class. With the current size, Google is still a more attractive place to work than Oracle, Cisco, Microsoft, Adobe, Apple, and many other well-known companies. This is what makes management errors more visible.

This list of errors does not purport to be complete, comprehensive, or even highlight major errors.

1. Trainings of leading programmers (Tech Lead) and managers.
Team building trainings in the form of meetings with colleagues do not at all develop leadership skills. Leading programmers and managers need to establish contacts with subordinates (for example, have lunch with them at least once a week), and contact each 1: 1 at least once every two weeks. It happens that employees did not see their direct leadership for three months. Some well-known leading programmers work only at night and never meet with their team.

It is necessary to separate the team building from management training and conduct the latter within the company, and not use the services of third-party companies. Management training should be conducted by top-level managers, not people from HR. Costly training is not required.

2. Incentives for leading programmers.
Leading programmers still regard themselves as ordinary employees, this leads to a vicious practice: they take away the most interesting work; provide a negative look for team members so that they themselves look profitable in comparison with them; do not pay attention to the requests and needs of employees; in extreme cases, it leads to confrontation between team members and leading programmers.

Good leading programmers (who take ungrateful work areas and give important projects to the team to help them develop) clearly stand out when analyzing the quality of team work and choosing the best employees suitable for improvement.

A reward system for leading programmers actively provokes bad behavior.

3. Approval, recognition.
The approval and recognition of employee actions is quite rare, although this is even more important than monetary compensation. Employees want their work to be approved by colleagues, and already secondarily take care of the bonus. Sometimes the bonus is so small that people say: it would be better if the manager met and talked with me about what good work I did, and then the size of the promotion would not be important.

4. Recruitment.
At the senior management level, it is considered a critical task. Until 2005, it was not tied to the employee incentive system. After that, they began to register who and how many conducted interviews about hiring, but only this one parameter, nothing is being tracked.

The status of an “active interviewer” is given to an employee with an indicator of 0.1 (on a scale of -1 to 4), and he can receive additional bonuses of up to $ 10,000 or more. This status is a mistake.

Since the goals of a specific development group do not coincide with the goals for recruiting senior management personnel, all managers ignore this status, which gives rise to even more cynicism than if it did not exist at all.

It must be said here that conducting interviews is a separate skill, and not everyone has it. If active interviewing negatively affects someone’s productivity, you need to take measures: either reduce the number of interviews, or include them in the list of employee’s immediate responsibilities.

It is necessary to provide statistics on the average number of interviews. It is necessary to calculate employees who should not do this at all: either conduct trainings with them, or directly exempt from this work.

5. Increase.
Promotions are handled by a special committee that is not directly related to work. As a result, they evaluate the brightest, loudest projects and underestimate the routine hard work, and the “cultural” contribution of the employee is ignored.

They refuse to promote employees who constantly "exceed expectations." Theoretically, this is a competent reception, but everyone - leading programmers, managers and ordinary employees - have already learned how to cheat the system.

Those who have not learned may suffer from this. One very efficient and hardworking programmer quit after being held for six years in a position where he is so efficient.

Recommendations from senior staff are reevaluated. Recommendations from lower-level employees are often ignored or underestimated. As a result, many seek to work with top-ranking developers. There are projects that are not bright enough by themselves, so you will never get the opportunity to increase, no matter how well you do.

At the same time, top-level programmers see that everyone wants to work with them and everyone wants to receive recommendations from them.

Conclusions.
Incentives are very important. They greatly affect the work of the company. But in many cases, nothing is better than too little encouragement.

Conflicts between rewards and goals must be carefully avoided. If conflict cannot be avoided, then you need to at least make sure that the right behavior is not fined, and antisocial is not encouraged.

Many important things are clearly visible at the lower levels of the company, but invisible to management. Managers should manage personally and physically close to employees, and not rely only on surveys. A survey of programmers in 2003-2004 showed that they called the "lack of managers" the main problem. Ironically, they considered the solution to this problem undesirable.

Also popular now: