Running a software team at Google

原文地址： http://matt-welsh.blogspot.co...

Im often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

LIKE A BOSS.
I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted" because engineers make most of the important decisions.) Unofficially, I'm what we call a "Tech Lead Manager," which means I am responsible both for the technical direction of the team as well as doing the people management stuff. (Some people use the alternate term "Über Tech Lead" but this has one too many umlauts for me.) A TLM is not a very common role at Google: most teams have separate people doing the TL and M jobs. I do both in part because, being based out of Seattle, it doesn't make sense to have my team report to a "regular" manager who would likely be in Mountain View. Besides I'm really happy to do both jobs and enjoy the variety.

There are four main aspects to my job: (1) Defining the technical agenda for the team and making sure we're successful; (2) Writing code of my own; (3) Acting as the main liaison between our team and other groups at Google, and (4) Doing the "people management" for the team in terms of hiring, performance reviews, promotion, and so forth.

Academics will immediately recognize the parallels with being a professor. In an academic research group, the professor defines the technical scope of the group as well as mentors and guides the graduate students. The big difference here is that I don't consider the folks on my team to be my "apprentices" as a professor would with graduate students. Indeed, most people on my team are much better software engineers than I am, and I lean on them heavily to do the really hard work of building solid, reliable software. My job is to shield the engineers on my team from distractions, and support them so they can be successful.

There are of course many differences with academic life. Unlike a professor, I don't have to constantly beg for funding to keep the projects going. I have very few distractions in terms of committees, travel, writing recommendation letters, pointless meetings. Of course, I also don't have to teach. (I loved teaching, but the amount of work it requires to do well is gargantuan.) Most importantly, my team's success is no longer defined through an arbitrary and often broken peer review process, which applies to pretty much everything that matters in the academic world. This is the best part. If we can execute well and deliver products that have impact, we win. It no longer comes down to making three grumpy program committee members happy with the font spacing in your paper submissions. But I digress.

I do spend about 50% of my time writing code. I really need to have a few solid hours each day hacking in order to stay sane. Since I don't have as many coding cycles (and service more interrupts) than other people on my team, I tend to take on the more mundane tasks such as writing MapReduce code to analyze service logs and generate reports on performance. I actually like this kind of work as it means dealing with a huge amount of data and slicing and dicing it in various interesting ways. I also don't need to show off my heroic coding skills in order to get promoted at this point, so I let the folks who are better hackers implement the sexy new features.

I do exert a lot of influence over the direction that our team's software takes, in terms of overall design and architecture. Largely this is because I have more experience thinking about systems design than some of the folks on my team, although it does mean that I need to defer to the people writing the actual code when there are hairy details with which I am unfamiliar. A big part of my job is setting priorities and making the call when we are forced to choose between several unappealing options to solve a particular problem. (It also means I am the one who takes the heat if I make the wrong decision.)

I reckon that the people management aspects of my job are pretty standard in industry: I do the periodic performance reviews for my direct reports, participate in compensation planning, work on hiring new people to the team (both internally and externally), and advocate for my team members when they go up for promotion. Of course I meet with each of my direct reports on a regular basis and help them with setting priorities, clearing obstacles, and career development.

The most varied part of my job is acting as the representative for our team and working with other teams at Google to make amazing things happen. My team is part of the larger Chrome project, but we have connections with many other teams from all over the world doing work across Google's technology stack. I am also frequently called into meetings to figure out how to coordinate my team's work with other things going on around the company. So it never gets boring. Fortunately we are pretty efficient at meetings (half an hour suffices for almost everything) and even with all of this, my meeting load is about half of what it was as an academic. (Besides, these meetings are almost always productive; compared to academic meetings where only about 10% of them have any tangible outcome.)

Despite the heavy load and lots of pokers in the fire, my work at Google is largely a 9-to-5 job. I rarely work on the evenings and weekends, unless there's something I'm really itching to do, and the volume of email I get drops to near-zero when it's outside of working hours. (Although I am on our team's pager rotation and recently spent a few hours in the middle of the night fixing a production bug.) This is a huge relief from the constant pressure to work, work, work that is endemic of professors. I also feel that I get much more done now, in less time, due to fewer distractions and being able to maintain a clear focus. The way I see it is this: If I'm being asked to do more than I can get done in a sane work week, we need to hire more people. Fortunately that is rarely a problem.

Disclaimer: Everything in this post is my personal opinion and does not represent the view of my employer.