Day in the Life of a Google Manager(matt-welsh.blogspot.com) |
Day in the Life of a Google Manager(matt-welsh.blogspot.com) |
He left the office every day at 6:30 sharp and, like clockwork, would answer emails and code reviews starting at 10. Eventually we learned to time our emails and code reviews according to this clock.
The consistency of the timing was remarkable; our favorite theory was that was his kid's bedtime. I guess in effect, he was putting two sets of kids to bed each night :).
Given that Matt did get tenure he clearly is really good at such managerial roles, and probably couldn't help but step up. I bet Google leadership try very hard to get people to do management--it's not easy, on the contrary engineers don't like it and it's a fight to get the good ones to step up. I would bet too that the managerial type things at Google are a lot more fun than the academic ones.
Oh thank god. Not about bitcoin specifically but it feels the whole world has managed to find the time to do a course on FRP, brush up on SEO, configure a Hadoop cluster, grok Haskell monads and still work out what a Mocachino is.
Glad to know mortals still exist.
After an evening of chasing kids around the house to get them to eat, wash and sleep, email does feel like freedom. Especially if you like your job. Also, not all email is alike. Usually no one expects you to answer important email in the evening, so you can quietly catch up on stuff you decided to leave out during the day, some mailing lists, etc. It's kinda like reading HN, just more productive.
I find myself using the evenings to catch up on email, because I can take my time and do it in between other things. I'm sure once family life becomes more prevelant I'll change my tune.
All in all, it is very relaxing compared to my last job. I was full time remote, and probably worked 80 hours a week. I have a much better work/life balance now, as I generally leave my work at the office.
Not all that 9.5 hours on campus is working time. I generally take a break for breakfast & lunch, hit the gym a few times a week, and try to spend an hour or two a week on fun, non work related things (like author talks).
People really have totally different preferences. It's more striking when laid out like that.
I loved the emphasis on family and balance. Timely article for me, I guess.
As far as "wasting education" is concerned, I've blogged extensively about the differences between doing applied research in industry and doing that kind of work in academia or in a more pure research setting, see for example http://matt-welsh.blogspot.com/2010/11/why-im-leaving-harvar...
I find that applying my skills as a systems and networking researcher in an industry setting, where I have the chance to develop and launch real products, is far more satisfying than just writing academic papers. But this is of course not for everyone.
I work for an "extremely" progressive company in the valley, and I have three whole weeks of paid vacation per year, and I'm chafing at that, because I'm used to having six weeks of paid vacation per year.
I will never understand the american work ethic.
You'll note that there's approximately zero 'goofing off' time in his schedule, he's either working productively, or not present at work. This is a good way to be productive and maintain sanity.
I almost never work longer than that. (I honestly wish I could sometimes. I end up having to interrupt myself in the middle of things to leave on time, but such is life when you have kids.)
If he's also doing a bit of email in the evenings, leaving at 4:00 doesn't seem unreasonable. I've never seen or heard anyone fret about work hours at the office. My experience has been that the company is very results oriented.
(This is still hard for me to adjust to coming from EA where I worked a lot of hours and company culture, unintentionally or not, placed a lot of emphasis on how long you kept your seat warm.)
But why? You won't produce more, you won't earn more, you won't learn more?
My role was also one that was pretty amenable to sprints of intensive working followed by periods of rest. I did a bunch of prototyping and working on high-profile, tight-deadline projects, and there was naturally a bunch of downtime in between them.
I've always wondered how google manages this process.
It's interesting to hear this - can you expand?
Probably 2-3 days a week I put in an hour (or two, rarely 3) after the kids are in bed.
I don't always go in "that early" (normal people would slap me if i didn't put that in quotes), but i'm completely responsive on email/IM/etc by about 8:30.
The main difference from Matt is that when I drive (i bring my dog in, and it's not safe to bike with her on shoreline), if I don't get in before 9, IMHO, it's essentially not worth driving in until ~10am.
You'll just waste the time sitting on shoreline.
Biking, yeah, it's always 10 minute for me.
It's difficult to work with folks with 'unconventional' schedules if they are involved in cross-functional or managerial stuff. Fine if you're an individual contributor, but if you need to get a few folks in a room together frequently (project leads, etc) and their working hours have zero overlap, someone's going to get grumpy. I appreciate flexibility in schedule, don't get me wrong, but I also appreciate a bit of self-awareness :)
Matt, your schedule looks so much better than mine! :-)
In addition, you have the legal right to take four consecutive weeks of vacation in the summer, but you might not get to choose exactly when if you insist on four weeks, depending on scheduling for your work. If you're a blue-collar worker, you typically get July off, so the entire manufacturing industry shuts down simultaneously.
I love my (non-Google) job and love my family. So, I'm happy on Fridays when focus changes to family, but I also often love Sunday evenings when focus turns back towards work.
Not everyone has a dreadful, barely tolerable job...
We have more or less a rolling set of goals/projects and individuals who own those. As projects move from in progress to something we're willing to attach the word 'done' to, the folks working on them either pick up the next best thing on the list (that is, the next thing on the list for which they're the best suited person to own it) or they find another project where the owner is looking for some help and pitch in. Engineers are mostly expected to self-allocate based on what we understand to be really super important rather than simply really important.
The projects are sometimes defined internally ("Hey guys, wouldn't it be neat if...") and sometimes externally; rarely do they have hard ship dates associated with them[0]. Additionally, individual components have moderately well defined ownership, although this can shift over time as people's interests change (for example, I currently own the virtual NIC presented to GCE guests, so I tend to end up on networking projects).
My experience is that (for us) this works fairly well. From time to time someone puts on their manager hat (someone who actually has direct reports, that is) and asks people to shuffle around a bit. My experience with this workflow has been uniformly happier than my time (prior to Google) working with sprints, story points, and rigid deadlines that always slipped anyway.
Again, this is not necessarily indicative of how Google works in general, and your mileage may vary. Also, we're hiring :D
[0]: There are targets to help with prioritization and dependency tracking, though.
If you're "in the groove" so to speak with coding, continuing work could be much more productive. At the times he wishes to work later, his additional work could be dozens of times better than a typical day. In contrast, coming back to code you were in the middle of a day later can have an hour of delays as you work just to get back to the state of understanding you had before.
In this way he will produce more. Producing more sometimes leads to earn more (that one's not as definite). Learning more... well, the more projects you complete the more you get to do; the more chances to learn.
This isn't to say that having a fixed end time is bad, just that your statement is false.
More time spent staring at a text editor (or even spent pounding on a keyboard) does not mean that you produce more. Maybe if your production metric is characters typed you produce more, but in terms of usable features there is going to be a point of negative returns on time spent.
I don't at all think my long term productivity increases if I work more than 40 hours a week, but I think it would increase if I could be more flexible (just +/- an hour or two a day) about when those 40 hours happen.
Is the frustration level a constant problem if reviews can take ... X longer than thought?
I'm an SRE, which means most of the code I write isn't directly user-facing, and thus isn't normally subject to hard external launch deadlines. That means I'm rarely rushing to push my changes through on a tight schedule. If there's a production emergency and I need to make an urgent change to avoid or mitigate an outage, there are escape hatches at our disposal to temporarily circumvent the code review system when no one is immediately available to do a review, but the need for that is pretty infrequent.
I rarely find it frustrating. On the contrary, I really appreciate Google's emphasis on code quality, even though it does come at the cost of some agility. I used to work at a company where the implementation of code reviews was generally resisted, and though we did get new code out the door faster, we ended up with some real maintenance nightmares as a result.
I talked about how my team at Google, specifically, handles this in https://news.ycombinator.com/item?id=8941915
I've seen lots of self-+2s under the following circumstances:
1. You are the only engineer on your team, or all other engineers on your team are out for an extended period of time.
2. All other engineers have very different skillsets, and are not capable of doing effective review. Think Rails engineer attempting to review a touchpad firmware fix.
3. You have a hard deadline (e.g. product demo or factory build) and you're desperately trying to get as much working as you can. You may even be in a location where coordination is difficult and Internet access is poor.
For SWEs working on, say, web services, you probably have at least a medium-sized team (4+ engineers) and a week's slip is no big deal. But not all software is like that at Google.