> This was in contrast to a typical Googler who received an average of about 450 emails per day, many of which were important to at least read, with a good chunk of them requiring a reply
That's ... quite a lot. The fact that the company manages to produce so much IT products with such big overhead on the engineers is amazing.
You can see this sort of thing in open source projects where every status change for a issue or a patch automatically sends email. If you're subscribed to lots of issues and patches, and monitor the user support mailing lists as well, it adds up.
A good deal of it is change lists (CLs), which are sort of like pull requests on github, and issue tracking. With inbox I have all CLs that mark me as a reviewer explicitly in one bundle, all the ones in my "___domain" but not with me as a reviewer in another, and all the remaining in a third. This bundling helps me keep vaguely on top of what's going on while only spending a second or so per email reading the subject line. Obviously, I spend more time on things where I'm marked as reviewer. If none of the CLs stand out to me as something that needs digging, I can just click the check mark for the whole bundle.
If we assume an average time spent dealing with each email of 15 seconds, that adds up to around 2 hours per day. If most emails require replies, then average time/email will be much greater than 15 seconds.
This is a great point and one that so many people miss. Time spent managing email is not necessarily time wasted. Working with a team involves communication, and often that communication happens via email, and so managing email can be productive. When I'm in the midst of coding, I'd much rather my teammates send me emails that I can handle asynchronously than have them stop by my desk and interrupt me to say the same thing.
There's a low signal/noise ratio and the noise is overhead.
And that's exactly the situation people customised Gmail to do (using filters etc), and what Inbox is designed to do from the start.
The problem is that "noise" is very, very context sensitive. 30 messages of commit-spam, 10 comments on a bug and a 60 message long thread in an internal mailing list suddenly become very, very relevant when that bug lands on your desk.
That's ... quite a lot. The fact that the company manages to produce so much IT products with such big overhead on the engineers is amazing.