I'm 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.
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.
 |
| LIKE A BOSS. |
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.
Thanks for this post, it kind of makes me want to work at Google!
ReplyDeleteThanks Matt, interesting write-up. I am pleased to see that your are on pager rotation – I find it a great way to take responsibility for what we produce, and also great for learning more about the software and its users (I'm on call as well). I guess "pager rotation" is just a name though, or do you use an actual pager (as opposed to a phone)?
ReplyDeleteAlso interesting about meetings – they can be an incredible time sink if you're not careful.
I actually use my phone, not a physical pager :-) I'm also the guy on the team who knows the most about how the various pieces fit together, so in some sense being on call is lower stress for me than it would be for someone new to the group!
DeleteThanks for sharing your views.
ReplyDeleteI made a very similar career move and couldn't be happier. I went from CS professor to a directorship role in a state government economic development department and back to software engineering. It's more fun to make things than to be important.
ReplyDeleteMatt, now that you've both been a professor and worked at Google, if you were forced to go back to academia, what would you do differently? Have you learned anything at google (either technical or management stuff) that would make you a better professor now?
ReplyDeleteThat is a very good question.
DeleteIf I were *forced* to go back to academia, I would run my group much more like a software team. We would have a clear set of objectives and milestones; we'd do code reviews; we'd all sit in the same lab together (I'd eschew a separate office except for one on one meetings); we'd do regular performance reviews for everyone (at least quarterly). The expectations would be made very clear about what it would take to be successful. I would no longer allow students to meander in twice a week and get nothing done for months on end until the next paper deadline rolls around. And we'd focus on "shipping", both code and papers. I would quickly kill projects that were not gaining traction. I was pretty bad about that and let some projects drag on for years without any tangible results (mostly because I had a grant and there was no downside, apart from the mental load.)
Matt,
DeleteThank you very much for sharing this. As somebody who had spent time in the industry before starting a top-tier Ph.D. program, I was quite surprised that students' work is *not* organized like you specify here. To me it always seemed like a misdirection of human potential.
Wouldn't you say, however, that in the long term, students' lack of focus is what allows them to come out as independent thinkers and people who are able to scope their own problems and figure out their own ways of getting around the problems? Isn't the freedom of exploring -- as opposed to a "focus on shipping" -- isn't it a distinguishing feature of a Ph.D.?
I'm asking since I, personally, would also run my group more like a software team. I keep wondering why many people do not -- whether this is for the lack of faculty time, or whether there is a particular wisdom to it.
Dear Matt and Anonymous #1,
DeleteI feel that the difference is about whether you want to maximize the output of your research group (as a way to ensure tenure) at the cost of developing independent research skills in your students.
Many successful profs micro-manage their students to the extent of defining their problem statements, designing experiments, analyzing results, and writing most of their papers. These students seldom become successful academics themselves.
Just my 2 cents on this.
Hi Matt,
DeleteThank you for a very insightful writing.
Continueing with question of being *forced* to return to academia world. I wonder if your experience working as a software engineer influences your perspective of doing research and on how you choose the research project?
Thanks,
H
I can't really respond to the Anonymous comment about "micro-managing" students. That's not what I suggested at all. I think you can run an effective research group in which students are not allowed to slack off.
DeleteAnon#2: Yes, my experience in industry would certainly shape my approach to research. However, the way you win the academic game is by writing papers, not building useful products. Being good at writing papers doesn't necessarily mean you are working on the right problems or can even deliver a working solution to any of them. At the same time I don't think academic researchers should be working on the same problems that companies are trying to tackle.
Hi Matt, just a couple of questions:
ReplyDelete(1) How big is your team? (I imagine there is a big difference between managing a 5 person team and even a 20 person team). Related to that, do all team members report directly to you?
(2) You talked about all the things you prefer in your current job and I have no doubt you are happier and more productive, but are there some things you miss about your academic job? (besides teaching, which you already mentioned)
My team is about average for a project team at Google - more than 5, fewer than 20. But we do have several "sister" teams that we work closely with so the number of folks involved is larger than just my direct reports. Yes, everyone on the team reports directly to me; I'm not (yet) a middle manager.
DeleteI can't say there's very much I miss about academia. The main thing is the connection with the students. Over the years I've had so many amazing undergrads and grad students pass though my research group and courses and it's great to follow their careers and feel like I had a small part in their success. So I guess I miss having the academic "family tree".
Thanks for this great article. It gives voice to the many who are disillusioned with the way universities are being run. As a PhD and a published author, I have been mortified by how many incompetent academics there are.
ReplyDeleteI recently saw a person with the research skills of a 2nd year undergrad given a senior lecture position. The interview panel featured people who similarly cannot write or research.
The 10% figure on meetings is spot on. My friends and I have been to many meetings where absolutely nothing was achieved at all. You mentioned Harvard; imagine what it is like at a run of the mill university. It's much worse.
Meantime, the quality thinkers are alienated. Or find better work elsewhere as you so eloquently showed.
Hopefully, people like you will cause change. Or maybe the new information/research centers will not be called universities per se.
This was an interesting read. I am also a Tech Lead Manager at an education software company and my role sounds exactly like yours.
ReplyDeleteThank you very much for your post! It really helped me.
ReplyDeleteThis was a great read, thanks for sharing!
ReplyDeleteWhat is it do you think that most reduces the "constant pressure to work, work, work" from academia?
ReplyDeleteIs is that your have more people in your group? That they are better qualified or more independent than students? Or simply that there are less time wasters like meetings and reviewing papers?
I've blogged about this extensively before, but the short version is that the professor's work is never done. You can always be working on another paper, another proposal, another talk, joining another committee, whatever. Since the number of things you publish and are involved in is directly related to your success as an academic, there's never a point where it stops.
Delete"If I'm being asked to do more than I can get done in a sane work week, we need to hire more people."
ReplyDeleteI wish everybody saw it that way. Even employees can get carried away with this. I once had a junior programmer who was working 80 hours and maybe being half as productive as the rest of us. I tried to explain to him that nobody is going to notice when you're here in the office at 9pm, and you're neglecting your family, which is making you depressed, and that is contributing to your low productivity. I told him we need you to work 40 hours a week and stop trying to be a hero. He didn't understand me telling him to work fewer hours. I tried to explain that I thought he would get more done if he had appropriate breaks and time to spend with his wife, who was handicapped and needed a lot of attention that he wasn't giving. We eventually had to let him go - primarily because he wasn't doing what he was told - I told him to go home at 6pm every day, and I showed him how to get things done that way, but he didn't do it. So basically, he was let go for insubordination - for refusing to work fewer hours! Can you believe that?
It's sad that the academic system is so lame. But it would be even sadder if people didn't realize it was lame and wasted their careers beating their heads against it. Glad you saw the light as so many of use have.
ReplyDeleteFrom my experience in managing in industry and in academia as a research supervisor, I am not sure that one can really learn the skills necessary for leading or for working on large software projects in today's software engineering programs.
ReplyDeleteGoogle has so much money that practices can work that might be detrimental to a less wealthy company.
Can you give an example? I am not sure what you're getting at here.
DeleteMatt,
ReplyDeleteWhat editors or IDEs does your team use?
Pretty much everything under the sun ... Personally, I use vi :-)
Deleteyou monster! emacs all the way...
DeleteI am working at the same major that I go to school for. At least at computer science major I can easily see how we are wasting our time at school mostly because how professors are leading their classes. I wish it was an obligation for professor to work in an industry, before being teaching students.
ReplyDeleteits something really good intro i have see about you.So now you are do both the activities parallel.and your post will definitely give some way to freshers and students for their career.
ReplyDeleteAfter visiting the Google offices in London and Dublin (Dublin especially) I can see how you are more productive with the great environment and working ethos there.
ReplyDeleteMatt, what is your next career goal and plan? Do you want to move up to higher leadership positions or do you want to stay as "engineer"?
ReplyDeleteGreat question. The short answer is, I don't know. The longer answer is, I have realized that I am happiest when writing code and building real things that real people use. Fortunately at Google, I can continue up the career ladder without taking on more management responsibilities. I don't think I want to find myself in the position of being in meetings all day without being able to code.
DeleteMatt, do you get the same elation when you write code for Google as compared to say when you wrote SORA? I am asking this because - in my opinion, papers are more durable than programs. Everyone might forget your code at Google, but you will still be remembered as the one of the co-authors of SORA (which is I think one of the highest cited papers in WSN).
ReplyDeleteContributing to mankind's knowledge in terms of writing papers like SORA I think is more important than slinging some python code all day long. What say?
I respectfully disagree. I'm glad you liked the SORA paper, but I'm willing to bet fewer than 1,000 people have ever read it (and fewer still understand it). It is true that when you write a *really* milestone paper -- something like RAID -- then it will have tremendous impact both on academia and industry. But very little academic work has this kind of impact. As I blogged about when I decided to join Google, for me it is a question of what end of the innovation pipeline I want to work on. Personally it's more satisfying to work on things that have direct impact on real users. This is not to say you can't be happy working on stuff that might only matter 5 or 10 years down the line - but that's not for me.
DeleteThis is exactly the information I was looking for. Thanks a lot for sharing.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteIf other readers also have useful advice / experience here I'd be really interested to here it.
Delete