[jsolson]

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.

[jshen]

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.

[ceras]

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.

[jshen]

But how do you manage scope and deliverables on a team that doesn't occasionally require overtime?

[jsolson]

You ship later or you scale back the scope to something manageable.

[jshen]

Do you work at google?

[jsolson]

Yes. As I mentioned in https://news.ycombinator.com/item?id=8938244, I'm an engineer on Google Compute Engine.

I talked about how my team at Google, specifically, handles this in https://news.ycombinator.com/item?id=8941915

[jsolson]

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.

[jlees]

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.

[sukilot]

Make more accurate (lower) commitments.