Posted on
by
Gmail: Behind The Scenes
#gmailbehindscenes
Presenters:
pastedGraphic.pdf Arielle Reinstein
pastedGraphic_1.pdf Braden Kowitz
pastedGraphic_2.pdf Edward Ho
pastedGraphic_3.pdf Jonathan Perlow
pastedGraphic_4.pdf Todd Jackson
Packed room. – Will
  • photo shown: google offices. each person has a ~5 foot long desk, 2 24” monitors. open layout.
  • Jon Perlow: Software Engineer, Gmail Frontend
    • Best known for Mail Goggles: prevents drunken emails by testing you with math problems.
    • Gmail is at it’s best when we start with something that seems crazy at the time. Not necessarily that we know how to do it. But that it would be great for the user.
    • Started with…
      • Email that you would never need to delete anything
      • Spam filters that would just work
      • HTML/javascript interface that felt just as good as desktop applications
    • We didn’t know how to do any of those things.
    • They asked me to implement integrated chat. Browser based chat up to that time was really clunky. if we had limited ourselves to what we knew how to do, we wouldn’t have attempted it. 
    • Think about what is best for the user, and then try to do it.
    • Most of the things we do fail. Lots of false starts before anything launches.
    • Four years ago we worked on stuff like Google buzz.
    • you keep trying until you figure it out.
  • Arielle Reinstein
    • Product Marketing Manager
      • In charge of Gmail blog
      • Gmail sticker set: you could send an envelope and they would send you stickers.
      • Has to deal with outages
    • With scarcity comes demand. People were selling their souls to get a Gmail invite. They thought it was brilliant marketing. In fact, it was just to manage demand. They had never had a free service with so much space.
    • They focus now on how to do word of mouth. 
    • Poll: who in the audience got gmail via banner ad (zero), via signing up at website (almost none), via invite from friend (almost everyone)
    • They work now on generating buzz when they don’t have to manage demand.
    • They have done banner ads, and PR campaigns, but in fact, that is just a drop in the bucket compared to their organic growth.
  • Ed Ho
    • Technical Lead for Google Buzz
    • Was a founding member of Yahoo pipes
    • Building an engineering team culture is at least as important as code quality.
    • He wanted a super engineering team
      • Team to feel like they were on a mission. they could do it, they were one team, they didn’t feel split across front-end and back-end. 
      • Ideas come from everywhere. Someone else might have a might better idea. 
      • I wanted lightning fast decisions, not sitting in for hours in design meetings.
    • Branded the team internally. The people came from all different places. 
      • We called it the Taco Town team.
      • We labeled the milestones after the layers of the Taco Town taco.
      • It was fun, and memorable.
    • Key team things
      • Started the team off by not having a regular team meeting. Didn’t focus on any metrics. Instead we did demos. 
      • Focus team on execution.
      • Not on what you might do, what you say you will do, not what will happen in the future.
      • Open layout, closely together. You can turn to someone and ask a question. No meetings, no IM, no emails.
      • Q: Team is very interruption driven. Doesn’t that interfere with productivity?
        • We want the interrupt driven because we can avoid meetings, and because people can overhear conversations. You can absorb more when the conversations are going on around you. People can quickly in ad-hoc way contribute to conversation and save time.
        • The biggest time wasters are leaving your seat to go to a meeting. It’s less of an interrupt if you your work is still on the screen in front of you.
  • Todd Jackson
    • We do lots of things at Google by consensus. how do you do it well.
    • Product Manager, Gmail and Google Buzz
    • The product managers job is to work closely with engineers to figure out how to put the technology together to make sense to the user. 
      • The ratio of engineer to product managers is 30:1.
      • No one reports to product manager
      • So the only way that the product manager can get anything done is to help build consensus
    • Shit funnel versus for shit umbrella
      • If you are a shit funnel, you funnel all the shit onto your team, and interrupt them all the time.
      • If you are a shit umbrella, you protect your team from it
  • Braden Kowitz
    • user Experience, Google Ventures
  • Work environment…
    • We used to have people split across many different offices
    • We consolidated to fewer offices, but we still have 24 hour coverage
    • Mostly in Mt View, some in Seattle, some in Zurich.
    • By covering Mt View and Zurich, we can cover around the clock – if someone submits a bug at 10pm, people can start working on it right away
  • Gmail scale
    • Google uses Gmail for their mail
    • hundreds of millions of user
    • 53 languages
    • millions of lines of code
    • several hundred thousand lines of javascript
    • C++
  • What is your process like? From having an idea to shipping it
    • It’s pretty chaotic.
    • If you have an idea for something, you do it. You build a prototype or a mockup, and you should it to people, and the idea takes steam.
    • Engineers can push their code changes to a special set of servers, and then the engineers can switch their accounts to those servers. It allows for a tight evolution loop, because all the engineers can start looking at it.
    • Labs is another testing ground, because they can get user feedback, and get a compelling story for why we should release it to the entire world.
    • For example, we released a feature in Labs called “undo send”.
      • debated it for two years because it touched a lot of the stack
      • an engineer, not on the core team, in japan, just implemented it. 
      • it went to labs, and it was most popular, and proved the feasability.
  • We were adding a new feature (drag to labels), but we were fanatical that we would not slow down the user experience. We stopped ship over this. Even though we knew draggle email would be very popular feature, we could not compromise speed. So we worked on a design change — draggable handles, which increased discoverability, and avoided performance hit
  • Buzz Launch — Privacy issues at launch
    • We didn’t discover it inside Gmail, because, to a certain extent, we were in a trusted environment. We didn’t need to be private inside. Once we realized the concern, we made changes.
  • Announcing things before they launch…
    • We usually don’t like to do it, because users want to use it right away.
    • But if we’re going to change the way the system works, then we do need to announce it.
    • We’re doing a little bit more of it in response to user feedback. If people ask us for inbox controls, and it takes us a week to localize it, then we will announce that it is coming so that people won’t worry that it is coming
  • Q: What are your metrics for success?
    • We care about 1 day users, and 7 day users, and “5 of 7 days users”, because we want to focus on our heaviest users. Not 30 day users. We look a lot on users.
    • We have a survey that will pop up in the right hand corner (very low frequency)
      • Look at spam, look at how people rate the speed
      • We saw that people thought Gmail got faster when we changed the color.
  • Q: Do you have user interaction designers?
    • Yes, we do. But our designers are also very technical. Most of them have CS degrees. So perhaps not purely designers.
  • Q: Buzz: personal or business?
    • Millions of people using it
    • We plan to release it for google apps for your domain
    • We find that people can use it to see what is going on inside your company
  • Q: Do you use unit testing?
    • Yes. Not initially, but about 2 or 3 years ago, we became heavily test driven.
  • Q: Any plans to improve Contacts experience.
    • yes, but we can’t go into too much details
    • it keeps me up at night
  • Q: Do features ever get killed for lack of adoption?
    • yes, we’ve killed labs projects.
    • We killed right-side labels, a Labs project, when we introduced draggable emails.
    • We hate to kill anything because there are also some users that love it.
    • There is an online petition to bring back one particular feature.
    • It is hard to get rid of things, but… if it stands in the way of bringing some really useful, we will do it.
    • People complain if we add features, people complain if we remove features, people complain if we don’t innovate and make changes. So we try to do the features that will do the greatest good for the greatest number of users.
  • Q: I’ve never clicked on a Gmail ad. Do they make money?
    • Yes, we can’t go into details, but it is healthy.
    • We are trying to show less ads, but better performing ones.
  • Q: Why wasn’t Wave built into Gmail like Buzz?
    • It was the way it was built. the team was trying to go from scratch.
    • There are some projects that are leapfrog projects: and Wave is one of those.
  • Q: Google Buzz for enterprise – when available?
    • Next couple of months
  • Q: Impressed by framework that allowed them to respond so quickly to buzz launch problems
    • A: Just work really, really hard. We realize the mistake we made, and some people didn’t leave the office until it is fixed. We slept there.
  • Q: How do you feel when you see 3rd parties develop plugins?
    • We love it.
    • We worry that greasemonkey scripts can be somewhat fragile