I'm a software engineer at Google in Seattle. I try to get in by 8:30 but sometimes it's closer to 8:00. I leave between 5:30 and 6:00 depending on when I got in. The office empties out pretty quickly in the evenings.
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.)
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.
The statement isn't necessarily false. You didn't show how the 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 think he means that when you are in a really good groove, you can be way more productive (and happy to keep working).
I don't know about anyone else, but I can definitely relate. This is 100% about your state of mind.
Happy code comes from a happy coder :)
I'm definitely more productive if I can park tasks when I reach a natural stopping point and not have to abort right when I'm in the middle of my flow.
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.
Ex-Googler here, formerly a SWE in Mountain View. My hours were highly irregular - the shortest day I worked involved getting in at 4:30, out at 7:30 (to be fair, I was stuck at the DMV) and the longest involved getting in around 10:00 AM and out at 2:00 AM the next morning. Average was probably about 10:45 - 7:30, sometimes time-shifted to be more like 1:30 - 10:00. 8-9 hour days were fairly typical, and it was only at crunch times that it would go up to 14 hour days and weekends.
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'm another Googler out of the Seattle office (individual contributor on Compute Engine) -- I work roughly a 9am - 5pm schedule, sticking to the ~40 hours/week pretty religiously. I will occasionally triage email outside the office from my phone, but I almost never respond to it. My laptop by and large doesn't leave the bag it came home in. I cannot for the life of me ditch the habit of actually taking it home most days, though.
How does your team scope out and schedule work? For us, we do two week sprints and then have a few hard launch dates a year. It's often hard for us to finish all work we commit to without working a bit of OT.
I've always wondered how google manages this process.
Google is such a big company you will find huge variety between teams. I have not personally worked on a team at Google that expected overtime (all of mine chose to cut or scale back features rather than increase hours when things got tight), but I have heard of others who have.
Others have answered this reasonably (namely that Google has no one way to manage this process and it's really up to individual teams to self organize as works best for them), but here's probably more text than you wanted about specifically how my team handles it.
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.
Varies a lot between teams, even between individual teams in the same organization. Though the teams I was on were pretty good about cutting things if it was clear work wasn't going to all get done.
SRE here. If you can handle your work nobody cares how much you are in the office. At all. However, unless you are insanely organized you won't be able to do this every single week--most successful googlers have several projects going on at once and there will be some times when you need to work hard on more than one.
It's common at Google to have a few projects cooking that you move between. One reason for this (though I doubt it's the sole reason) probably has to do with the mandatory peer review process for all code, which can cause delays in getting your code submitted if your reviewer's schedule doesn't line up well with your own. Instead of introducing a bubble into your pipeline when that happens, it's nice to have a side project you can hack on for a little while until you get your code review feedback.
How are deadlines managed in that environment? Sprint ends or release dates or just "we will do it by Tuesday" all conspire against peer review delays.
Is the frustration level a constant problem if reviews can take ... X longer than thought?
Well, you can always assign a different reviewer if your initial choice is taking too long. I usually try to check with my teammates to see who has time for a review before sending them my code, at least if it's something that I want to get submitted quickly. That ensures that I pick someone who will look at it sooner rather than later. Sometimes the specifics of the process require someone who is not on your immediate team to give their approval, in which case delays are more likely.
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.
No, not TBR. I was referring to the fact that you can +2 your own CL, which allows it to be merged. Officially this is an "emergency" feature, as you say, but a dirty secret is that it's used routinely. I encountered it in both Android and Chrome.
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.
I'm not actually sure this works in... well, not Android and Chrome. I can TBR, but as far as I know I can't self-LGTM (and certainly not self-Approve).
Google Product Manager here. I get on the bus about 8:30 and start working. In Mountain View (where meetings commence) by 10a. Usually pretty solid w/ meetings from 10-4. Get on a 4 or 4:30 bus and work again (email, etc) until I get off at 5:30 or 6.
Probably 2-3 days a week I put in an hour (or two, rarely 3) after the kids are in bed.
I'm a manager (for ~50 people), and my schedule is close to Matt's, without the kids.
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.
SWE in MTV - I'm in at 9:00am, out at 4:00pm 3 days a week. 2 hours on the bus, I might get an hour of work done. Once a week I do 10:30am to 7:00pm (team meeting and game night - dinner on campus). About once a week I do 10:30am to 4:00pm. I agree with the post author - by 4pm I'm pretty fried and useless anyways.
Left Google about a year and a half ago; leaving at 4pm is pretty unusual from the folks I worked with, though I had a couple of team members who would have 'pick up kids from school' blocked out on their calendar, and taking a longish break midday or in the afternoon was totally fine if you didn't have any meetings. Most people I know tended to come in to get the tail end of breakfast, so 9/9:30, and often stay for dinner (6:30). I had a colleague who did 6am-4pm or so to avoid traffic, though, and another who wouldn't come in until about 4pm for the same reason.
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 :)
Yeah, you basically end up treating them that way, but with a low-level amount of annoyance since they should be more available during standard hours. Depending on the person and the role, it can be ok to deal with though -- I'm not totally against the idea of working whenever is most convenient for you, it's just caused me personal frustration when trying to PM a team with multiple folks with differing offbeat schedules.
Depends on what you do and also where you are. I'm in a European office, and due to the fact I deal mainly with US-based folks, I usually start my day at 12pm and end at 6-8pm depending on workload.
