I manage a development team at Google

Since I left Harvard, people often ask me what kind of work I am doing at Google. I guess many people will think that there is a big gap between a tenure professor and a software engineer. However, in addition to this title, I am still very happy to work, and in this new role, I work more efficiently than I have ever been teaching at Harvard for eight years-although being a professor and managing a development team is very similar in many ways.

I lead a development team in Google's Seattle office. This team is responsible for a number of technical projects on the Performance of mobile website. (You can learn more about my team background from my previous blogs .) The Data Compression Proxy Support in the recently released mobile Google browser is one of our complicated projects. We are also responsible for the technical development of the pagespeed series, focusing on the optimization of mobile Web, there are some other cool technologies, but I cannot say here.

Google Seattle office

My formal title is only "software engineer", which is the most common but coveted role in Google. I say "coveted ", it is because all important decisions made by Google are made by software engineers. In private, I am called "tech lead manager". That is to say, I am not only responsible for technical guidance, but also for personnel management. At Google, "tech lead manager" is not a common job. Most teams have dedicated personnel responsible for technical work and management work. I have two roles, in part because my office is in Seattle. If my team reports to a "full-time" Manager at the headquarters, there will be a lot of inconvenience. In addition, I like both roles very much, and I like this diversity.

My work involves four main aspects: (1) Preparing routine technical work items for the team to ensure they can complete their tasks smoothly; (2) writing some programs on their own; (3) as the focal point between the team and other Google Project Teams, I finally (4) perform "Personnel Management" for some teams, including recruitment, performance appraisal, and promotion rewards.

Those who work in the school will immediately see the difference between these and being a professor. Lead a team in the school for academic research. The professor is a mentor who sets the technical scope for the research team and guides graduate research. In Google, the biggest difference is that I cannot regard these people in my team as my "Apprenticeship"-just like the relationship between mentors and graduate students. In fact, most of my team members are more technical personnel than me, and I have to rely entirely on their hard work to develop strong and stable software. My job is to protect these engineers from being disturbed and support them in various aspects to help them complete their tasks smoothly.

Obviously, this is different from the college life. Unlike professors, I don't need to raise funds to continue my research project. I am rarely disturbed by the work of the Committee, various surveys, letters of recommendation, meaningless meetings, and so on. Of course, you do not need to teach students. (I like teaching, but it takes a lot of work if you want to get a good result .) Most importantly, the success of my team is not determined by casual or subjective personal review processes-almost everything in the school depends on this review. Here, this is my favorite part. If we do well, submit the product and attract users, then we will win. It's no longer necessary to make those Review Committees well-behaved.
The old man is happy and has a hard time pondering what kind of font should be used in academic papers. I am a little confused.

It takes me about 50% of the time to write code. I really need some fixed time to write code every day, so that I can be quiet and clear-headed. Unlike other people in the team, it is difficult for me to have a long period of time not to be disturbed, So I mainly develop some simple tasks, such as writing mapreduce code to analyze service logs, and generate performance reports. I really like doing this. This kind of task allows me to access massive data and use various interesting methods to disassemble and summarize them. Because I don't need to show high programming skills to get a promotion opportunity, so those very eye-catching new features let the team do better than me.

In my team's software development, I will have an important impact, including design and architecture. To a large extent, I have more experience in system design than the guys in my team. Of course, on some details that I am not familiar, I need to follow the opinions of the actual coders. A large part of my work is to set priorities. When solving a special problem, I need to make a choice between a few solutions that are not very good. (This also means that if the decision is wrong, I will take responsibility .)

I estimate that my work on personnel management is no different from the practice of others in the industry: write periodic performance appraisal reports, develop salary floating plans, and recruit new employees to the team, win a promotion opportunity for team members. I regularly communicate with each of them to help them understand their priorities, eliminate their doubts, and guide their career development.

One of the biggest changes in my work requires several team representatives to contact other Google teams to ensure smooth communication and cooperation. My team is only part of this large Chrome project team. We have contact with the development teams of various technical departments across the world of Google. I often attend meetings to determine how to work with other teams in the company. Therefore, my work will never be boring. In addition, our meetings are very efficient (most of them can be done within half an hour). Even so, my meetings are close to half of my college work hours. (However, in comparison, only 10% of university meetings can produce substantial results .)

Despite the complicated work and heavy workload, I spent nine to five hours working on Google. I seldom work overtime at night or on weekends unless I am eager to do something and no one will send me an email during my work hours. (Because of a scheduling program of the development team, it took a few hours to modify a product bug in the middle of the night recently .) I feel that this is a relief from the work, work, and work status that is unique to the Professor under continuous pressure. I feel that my work is growing and it takes less time, thanks to the reduction in distractions and the ability to maintain a focused mindset. Our current approach is: if we need to do more work than a week under normal circumstances, we will recruit more people. Fortunately, this does not seem to happen.