16.01.2013 Views

1EQQ8ZzGD

1EQQ8ZzGD

1EQQ8ZzGD

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

tiate for more resources for your team given the company's<br />

resource allocation process, etc. Some amount of this is necessary<br />

to do well, and some of the negotation and persuasion<br />

skills will help in the future, but to the extent that much of<br />

this learning deals with the particular bureacracy or process<br />

that you need to deal with, it's significantly less valuable than<br />

other types of learning.<br />

When you first join a company, the learning curve usually<br />

starts really steep (hopefully, if you've made a good choice).<br />

You're immersed in new technologies, in a new product, and<br />

on a new team, and there are opportunities to learn along<br />

multiple dimensions. When I first joined Google right out of<br />

college, I learned a lot in my first six months there. Google's<br />

done a great job with their GoogleeDU training materials.<br />

I soaked in all the codelabs that discussed why core abstractions<br />

existed and how they worked. I studied programming<br />

style guides to learn best industry practices. I read design docs<br />

about search indexing and other scalable engineering systems<br />

being built internally. I learned to build and ship something<br />

seen by tens to hundreds of millions of people per day on<br />

google.com.<br />

Your learning rate might decrease due to organizational<br />

issues (maybe processes have become too bureaucratic and<br />

limit your ability to iterate and launch quickly) or due to maintenance<br />

issues where the team doesn't grow quickly enough to<br />

scale with the complexity of the product. The second makes it<br />

hard for you to switch projects and work on new things.<br />

Warning flags for me at Google started to appear when<br />

I realized that many projects either had no concrete launch<br />

paths or depended on non-transparent approval processes<br />

over which I had little visibility or control. Being able to<br />

launch products was important to the extent that I wanted to<br />

learn how to build great products, and quick, iterative feedback<br />

is a necessary foundation for learning. When I projected<br />

what I could accomplish and reasonably launch by staying an<br />

additional year, I didn't feel satisfied, so I left. There was certainly<br />

more I could have learned by staying — I could have<br />

dug into the internals of more major systems — but my rate<br />

of learning no longer mirrored what I encountered when I<br />

first started.<br />

392

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!