Five things I've learned in five years at Google

Today is my five year Googleversary! I thought I’d take a few minutes to share some things I’ve learned over the past five years related to developer advocacy, working in tech, and other random thoughts.

Here’s a picture of me riding a bike during Noogler orientation way back before phones had Pixel-quality cameras:

1. Ask for opportunities

When I first started working in tech, I would come up with goals and then just sort of hope they would fall into my lap. If I thought about it hard enough, maybe my boss would let me work on that other project or spend time learning a new skill. In our next meeting, my manager will definitely ask me to help work on this thing I’m desperate to work on, I’d tell myself. None of my managers have been mind readers yet, and I quickly learned that you have to ask for things you want (spoiler alert: this is not easy). Looking back, most of the things I’ve accomplished or had the opportunity to work on are things I asked for.

A good analogy for this is ordering food at a restaurant. Let’s say I’m craving a Caesar salad with grilled salmon. The menu has ceaser with an optional addition of chicken. Darn. Oh wait, I see grilled salmon in the entrees. Could I…combine them? The wait staff can’t read my mind, but maybe they could make it happen. I ask, and they say yes. Everyone wins! And even if they had said no, I still didn’t lose anything by asking.

Along with asking for opportunities, I’ve also shamelessly asked some people I admire in tech to meet with me so I could hear more about their stories. Through simply asking, when I first got into programming I met a former CTO of Twitter for coffee. More recently I got to meet a badass woman who worked on the first home computer.

The moral of the story is just ask. Disclaimer: if you do ask to meet someone for coffee, please don’t do it in a creepy way (sadly this has to be said).

2. Admit what you don’t know

This is the secret to not being afraid of doing Q&A after a talk, I just wish I had figured it out earlier. There is so much to be said for admitting you don’t know something rather than panicking and / or trying to spit out what you think is the right answer. Most often, people will respect you more for your honesty. I used to beat myself up for not knowing the answer to something. It took me awhile to realize that no one has all the answers, even if they’re an expert.

If you’ve been to one of my talks you’ve almost definitely heard me say “I don’t know for sure, let me get back to you on that.” 😉

The same thing applies to asking someone else a question. If I’m in a meeting and someone starts talking about an acronym I’ve never heard or a concept I’m not familiar with I try to ask what it is as soon as possible. The longer I wait, the harder it becomes to pretend I know what’s going on (and I am bad at acting, for better or worse).

3. Speak up

I almost left this section out and replaced it with something else, but I didn’t feel like I could adequately talk about my time working in tech without talking about the elephant in the room in most situations I encounter: “there are very few women or minorities here.” Sometimes I’m able to push this aside but other times I’m quickly reminded of it with something as small as an off-handed comment that makes me feel like I don’t belong.

From talking to friends in different industries, I know this issue goes way beyond just tech too. Even in 2019, the travel industry seems hesitant to accept the idea that a woman might be traveling alone on a business trip. When I check in at hotels I’m frequently asked if it’s “just me.” Even worse, one time a hotel staff member delivering food to my room made inappropriate comments about my body while in my hotel room.

In tech this sort of behavior can take many forms: comments on videos and blog posts, assuming someone isn’t technical because of their appearance, leaving people out of important discussions, and way more. For example, I’m often told (both online and in person) that I don’t smile enough when I present. Here are some comments I’ve received:

It’s frustrating that women are expected to smile and be polite while we don’t hold men to the same standards. For better or worse (and also because I believe you can always improve), I actually took some of these comments to heart and did a few speaker coaching sessions. I could tell I improved, but I also learned an important lesson: don’t change for other people. I love building fun demos to get people excited about machine learning, but if I got on stage and started exuberantly talking about them while constantly smiling, that would just not be genuine.

Lately I’ve been trying my best to speak up when these things happen. The industry can’t change overnight but I’m hopeful that small progress over time can slowly make tech a more inclusive place. A few months ago, I found an example in a product’s documentation that didn’t represent women fairly. When I spoke up about it, it was fixed in the same day.

This was a long way of saying:

• Speak up if you’re in a position to do so
• Check your unconscious bias before you judge someone

On a lighter note, speaking up can also take the form of providing product feedback when things are broken. I think one of the most important parts of my job is writing something we call friction logs. These are logs of your experience doing something with a product for the first time. You write down everything you did including code snippets, and then color code it based on what went well and what didn’t go well. Writing these is a great opportunity to provide feedback from a “customer zero” perspective. I also find it way easier to influence product direction when you can provide concrete examples of what you tried, what happened, and what you think should have happened instead.

Of course, it is way faster to build something without logging your experience every step of the way. But whenever I find myself working without a friction log in the next tab, I force myself to go back and log what I did while it’s still fresh in my mind. My role puts me in a unique position to provide product feedback from an external perspective to the people on the inside who are building it.

4. Try things that scare you

Every now and then an opportunity comes along that terrifies me and my initial reaction is hell no. But it turns out that these are the opportunities where you learn and grow the most. Often when something scares me it’s a good sign I should do it. You can’t beat the feeling of accomplishing something and thinking “hey, I did that seemingly impossible thing and I would even…do it again.”

As an example, back in 2017 I was trying out an early version of the Cloud Video API and built a demo that visualized the API response for a video. A few people started using it internally for presentations and then someone asked me if we could use it in a keynote demo. Whoa. My demo looked ok on my 15-inch laptop, but the thought of seeing it on a 100+ ft screen at Moscone Center sounded daunting to say the least 😱. Somehow I decided to ignore the little voice in my head asking “what could go wrong?” and go for it. After a couple weeks, I was happy with what I’d built and felt comfortable handing it off to the demo presenter.

Then, about a week before the keynote, the person who was supposed to present it said: “I’m not sure I’m adding much value to this demo, why don’t you present it?”. I had presented to big audiences before, but never close to thousands of people. Despite how terrifying this sounded, I decided I didn’t have much to lose. If I hated it, I wouldn’t do it again. Was I scared? 100%. I spent the hour beforehand pacing back and forth backstage listening to “My Shot” from Hamilton, replacing “guy” with “girl” whenever he said “Let’s get this guy in front of a crowd!”. Long story short I did it! And then I even did it again.

I’ve found the best progress comes with a healthy balance of trying something scary, getting comfortable with it, and then repeating the process when you feel you’ve stopped growing.

5. Failure is ok

With the exception of the amazing JK Rowling, people rarely talk about failure. For good reason, it’s uncomfortable to talk about when you messed up. I wish people talked about it more because it’s a necessary part of improving at what you do. Things rarely go 100% perfectly the first time, but on the outside we often only see the near-perfect version.

Even though it sucks, it’s ok to mess up! I’ve made tons of mistakes, written buggy code, and done things without fully thinking through the implications. And while talking about failure in the abstract is ok, I’ll give you some concrete examples of times I failed:

• I was doing a live demo of deploying a web app via the command line at one of my first big talks. I’d practiced it 20 minutes before going on stage and everything went smoothly. The demo was in the last minute of my talk and the first 29 minutes had gone great. Sometime in the interim, my login credentials expired. I hadn’t logged into the service in awhile, and not only did I forget my password but I typed my attempts at remembering it in plain text on my terminal for everyone to see. I finally got it right after realizing everyone could see what I was typing. And yes, I did change my password after that talk.

• The night before a Firebase launch I was helping write docs for the new feature. It was late, and I am not a night owl. Despite a merge conflict, in an effort to quickly push my changes I did a git push --f on my local branch. For the next ~24 hours the entire website repo was in a weird state and no one could figure out why. One of our engineers finally emailed GitHub support, who told us that someone with the username sararob had done a force push. Friends, never use the --force. I haven’t since this incident, though admittedly my git skills could still use work (if you have recommended resources on this, please lmk!).

• For a product launch, I came up with a demo idea that I thought was really cool and solved a problem for a specific group of people. Everyone I pitched the idea to agreed, and was excited to see what I came up with. I proceeded to build it until someone asked if I had asked that group of people what they thought of the problem I was trying to solve. Somehow, because everyone in my “vacuum” had validated my idea, I had failed to ask the people it was intended for what they thought. Turns out it didn’t resonate so well. I changed course, and thanked people for their honest feedback.

Recovering from failure can take many forms: evaluating what you can do differently to prevent the same thing from happening again, apologizing if necessary, thinking about how you’ve grown from the mistake, and then moving on and trying not to dwell on it too much.

---

If you made it this far, hi! I’d love to hear your thoughts on anything I shared. Feel free to reach out on Twitter, my DMs are open.