
Silicon Valley’s Productivity Secret - rguzman
http://blog.idonethis.com/post/16736314554/silicon-valleys-productivity-secret
======
tlogan
You have to careful with this. Really really careful. The status reports can
be sign of a broken company - and in a broken company they are used for
politics and other gains in the worst possible way. And sometime reports will
make a good company into a broken company (I saw it with my own eyes).

Furthermore, please understand that for many types of positions the snippets
will not work very well because work on hard problems is then discouraged
(causing low quality code).

In short, I don't think TPS reports are the key of Silicon Valley's
productivity...

YMMV

------
rickmb
It's basically formalizing what happens naturally when you still have a small,
physically colocated team. (Of course, most methods are.)

And like all formalizations, it's not so much the method but the people and
how they deal with it that determines its success. All formal methods, no
matter how lightweight, can become sheer bureaucracy if they become detached
from their original intent, and I'm already seeing anecdotal evidence
(including from inside Google!) in this discussion that "snippets" is no
different.

It's all about communication. If your no longer deliberately communicating
something _and_ getting valuable feedback, alarm bells should go off. Always
keep asking "why?".

------
georgemcbay
I always kind of assumed that most developers who work at these Google-level
places automatically reflect without a specific process to force it, but maybe
I'm just projecting.

Personally, I have a hard time _stopping_ myself from reflecting on the code
I've just written and the code I'm currently planning to the point where it is
almost a social problem. (eg. my girlfriend will be telling me about her day
and in the back of my head my brain is rewriting some code I actually wrote in
an editor earlier to be simpler and more efficient... great for my
productivity, bad for my relationships).

------
natfriedman
We do this at Xamarin. Every employee sends an email to the entire company
first thing Monday morning, containing their A&Os (Achievements and
Objectives).

We're a very distributed team and A&Os are one of the ways we keep everyone in
touch.

Also, doing this Monday morning is pretty important -- it means people focus
on planning the upcoming week, instead of just summarizing the week that
ended. Having a time every week where you set goals for yourself, and then
communicate them to all your peers, seems to be pretty effective. And one
benefit of having these emails go out to the whole company is that everyone
can read them and comment on what people are planning, before the work starts.

------
gbhn
A missing ingredient here is that the snippet/update/whatever system needs to
be policed by the CEO as the ONLY way such data can be collected. It doesn't
work if eight levels of managers across three teams each decide they want the
same "just five minutes per week!" updates in 16 different formats in
constantly shifting docs/apps/styles.

------
ChuckMcM
Of course they don't mention how annoying writing snippets can be (although I
agree they are a good way for an individual to remember what they've done).
They also don't mention that you can tell who is 'in' at Google and who isn't
by the fact that they haven't written a new snippet in over a year.

~~~
kragen
Can you elaborate for those of us who aren't Googlers? Why are they annoying?
If you write new snippets every week, how can you not write new snippets for a
year? Is it the "in" people who haven't written new snippets for a year, or
the "isn't in" people?

~~~
ChuckMcM
Sure, its pretty simple actually. Your manager says to you 'I want you to
write snippets every day' and you find yourself writing silly snippets like

"Spent the morning trying to get the six people who care about serial numbers
together to talk about the serial number issue, then argued with them for
three hours over changing the return value of getSerialNumber to return 'None'
when there was no serial number rather than 0 so that the machine database
won't have several thousand machines with serial number 0. Argument against is
that they will have to change their script to deal with a non-integer when the
serial number doesn't exist."

Now your manager might not think that was so great, they might think you
"can't get things done" because it took you all day and you didn't actually
get a decision, the other 6 folks are pissed off because you slammed them in
your snippet for being lazy, and you get slammed back for not being a team
player. So you write a more 'friendly'

"Spent the day working on the serial number issue, not a lot of progress was
made."

And now your manager complains that you are being so imprecise in your snippet
that nobody can tell if you're working or slacking off. So you go looking for
others who are nominally at your grade level and their snippet streams. You
see either snippets like:

"Organized a summit meeting of key stake holders around our efforts to re-
architect the serial number categorization issues which are have been plaguing
SRE for months. Using the input received I've put together a comprehensive
plan of action for addressing system wide issues."

Which is eloquently worded bullshit which makes young managers feel all happy
inside but really doesn't say anything, or you see

"No snippets in the requested range, last snippet was xx/yy/zzzz (some year
and a half to three years ago)."

You ask around and folks will say "Oh everyone knows what <some engineer> is
up to." but you ask and say "Do you?" and they admit that no, they don't but
its probably important, after all they've been here forever and they are a
'big cheese' in the system.

And of course if you point this out and it causes trouble for the 'big cheese'
where it comes out that you asked their manager why they didn't seem to need
to write snippets, well things would get really bad for you for a while. And
its then that you note that what snippets 'are' is not at all obvious or
useful.

That being said, I've always kept a note book and I write notes in it and
track various projects. Its great to review and figure out what is stuck and
what is making progress and it is wonderful to dump all the state into a
single page or two so that I can work on a different project but 'swap back'
into the stalled one just by re-reading my notes. Its exactly like keeping a
lab notebook of your experiments so that when you go to write the paper all
the data is right there. So I don't think snippets in general are bad, just
that as a management tool they are easily abused.

~~~
tlogan
This is exactly what happen in my previous company.

The story goes like this:

* one of engineers started sugarcoating his reports to look better than others

* then other engineers notice that they now look bad in eyes of the manager because they were blunt in then assessments, so they started sugarcoating their reports

* quickly the point of these reports is lost (they become garbage with no useful information about problems, challenges, what is actually done, etc.)

------
RuggeroAltair
I think that the article is identifying just one little secret, and not
necessarily an important one.

There is a lot of reasons why silicon valley is productive, one for all is
that most people with decisional power are also expert in the field.

Certainly if you plot the percentage of managers that are competent (with
possibly degrees) in the field between silicon valley companies and startup
compared to all the rest of the world, I'm sure that managers or CEOs with
just MBAs are less present in the Silicon Valley than in other areas.

But I still think that the main reason for the productivity in the Silicon
Valley is that the people are in general good and most companies and startups
aren't just dinosaurs that need $M's a year in consulting services to make any
changes or improve their results.

The consulting companies themselves are dinosaurs, which is one of the reasons
there is a discrete number of startups that are attempting to create new ways
of performing consulting.

------
akkartik
I just read this and realized I've been misusing snippets for the eighteen
months I've been at Google. There's a lesson there..

~~~
irollboozers
What have you been using them for then...

~~~
akkartik
I've been saying what I did rather than reflecting on what is important and
what to do next.

Doesn't matter because I don't think anybody's been reading them either. Most
of my team doesn't use them at all.

~~~
unreal37
Kinda undermines the article then.

~~~
ssskai
Not necessarily... snippets can be usefull for the simple fact of organizing
one's mind and week. Whether or not a manager keeps track of them, they allow
the employee to personally be accountable.

------
marcusf
It seems that this could be misused for politics in the worst possible way
since ones measure of ones performance is inherently subjective (even writing
a simple 'I did X' you might omit or forget collaborations with colleagues
etc).

It could be that I'm Swedish but I'm not sure I'd enjoy this at all. At our
shop we do weekly retrospectives. A session about 30 minutes to end fridays
with where each team sits down (about 4 ppl/team) and talk through the week
and their efforts and measurable ways to improve next week and long term. This
then gets logged. Fairly standard scrum/agile stuff.

Of course this shifts the focus from individual to team, but I'm not sure
that's necessarily a bad thing?

------
SystemOut
I really like this idea. Does anyone know of a project that implements this? I
did an initial search but nothing turned up but it'd probably be easy to miss
it. In a way it reminds me of Rands' trickle concept of keeping track of work
done so that one's status/log is easily generated. It'd be pretty easy to link
this into other sources to add details automagically as well(e.g. GitHub
check-ins come to mind).

~~~
loschorts
Hey, actually you can try our implementation at <http://iDoneThis.com> (author
of the post here). We have a team thing we're rolling out and this post was in
part to gauge interest.

~~~
ericabiz
Love the concept but hate the name. "iDoneThis" isn't even proper grammar...

This is a case where a few hundred dollars on a good domain name would go a
long way.

~~~
codyrobbins
It’s an excellent name. It’s not supposed to be proper grammar—that’s part of
the playfulness of it. It’s not a sentence, it’s a name. What you’re saying is
like saying ‘Flickr’ isn’t a word.

~~~
gergles
It's a stupid name, because it also parses as a sentence, and a wrong sentence
at that.

The product seems fine, but the name is irreparably bad.

------
keeptrying
Doing reports like this make me feel like I'm another cog in the system.

At my previous company, where we had to give a report for the 8 hours of every
day, my reports were one word in length and usually the same word:

"working"

If everyone in your company has to do this what ends up happening is no one
reads these so people just stop putting useful info in these "work notes".

Whats needed is communication and FEEDBACK... thats wehere most companies get
it wrong.

------
ajays
I would be hard-pressed to believe that if some company in some backwaters
place just implemented snippets, then they would be as productive as engineers
in Silicon Valley.

What makes Silicon Valley is the whole package. There's a critical mass of
technical talent. You run into techies everywhere; a techie here feels _at
home_. You (the techie) are the "in crowd". This is your bastion; your
playground. You are no longer a misfit, being picked on by jocks; here, _you_
are the mainstream. This is why techies love being here, and because they're
happy, they are more productive.

That's the conclusion I've come to, after 6 years here.

------
jes5199
I work at one of the companies he mentioned. We don't actually use Snippets.

------
altxwally
Interesting, sending daily/weekly reports is default behavior at Japanese
companies (where doing busywork is actually a good thing sometimes, since it
seems that there are many zombie companies that get funding just for the sake
of having people employed), so I'm surprised to see this practice considered
so highly in the context of the Valley. Though I'm suspicious that this
practice would be a secret itself, it seems so basic that it must be written
on a textbook somewhere. e.g. "give importance to communication", "it's a
ritual", etc...

------
richcollins
I've always found this (daily update w/ tomorrow's plans) to be a great way to
work as a contractor as well. You demonstrate that you're productive (usually
much more so than employees) and future planning helps you uncover additional
work to pitch to your client.

------
dorian-graph
It's done elsewhere too, at least quite similarly. Where I experienced this
heavily is quite far away from technology—I was a missionary for the LDS
church in the Philippines.

Every day we have a daily planning session (30mins) at night where we set
goals and make plans for the next day. Once a week we have a weekly planning
session (2-3hours) where we set goals and make plans for the next 7 days.

The main thing that is similar to this story is that every week we would write
a letter to the mission president (Basically, someone who is in charge of all
the missionaries in one area, mine being three islands in the Philippines)
where we wrote down how the week went, good things, challenges, if we achieved
our goals, questions and what we planned to do next week.

The planning/organisation/goal setting/GTD I learnt have stuck with me since
and I still do daily/weekly planning and goal setting for work, university
study, personal projects, etc.

------
kylemaxwell
I remember Raph Koster (MMORPG designer) blogging years ago about something
like this, where once a week - Sunday evenings, maybe? - he sat down with his
child and made plans for what he wanted to accomplish this week. While it
didn't go so far as to inform his team, it did encompass the idea of sharing
it with someone else who'll help to keep you accountable.

That has even more value, perhaps, than the meta-cognition of thinking about
what you need to think about.

------
adamfeber
<http://Assembla.com> offers this in the form of a StandUp report which
provides a simple web-based form that you fill our for what you did last
day/week, what you will do today/this week, any questions or road blocks that
need to be addressed.

We use them daily to ensure that everyone is working on the correct priorities
and to see if anyone has any roadblocks or questions that someone on the team
can help with. Some companies do them once or twice a week. Either way, its a
great way to simply know who is working on what and who needs help. These
standup reports are part of the Assembla workspaces but they also offer them
as a free standalone tool at <http://offers.assembla.com/standup>

------
tedmiston
The process of self-reflection multiplies my own motivation.

I noticed a big change in the way I work and how successful I feel after I
started keeping a daily journal. My focus was not directly on productivity,
but I wanted to see where my time had been going on the days where I have
multi-hour lapses which seem to produce nothing.

On a typical day, I type 500 words to describe the 2 or 3 most significant
moments / insights which happened that day. I also note ideas, people I meet,
and more mundane things (ex. how much sleep I got) in less detail.

I write mine in the iPhone Notes app since it's already with me all the time.
(I'm now designing an app which will extend the concept a step further to
aggregate some of this info in more useful ways without sacrificing the
convenience of one big text area for input.)

------
packetslave
At previous jobs, I've always kept a journal.txt record of what I worked on
from day to day, so translating that to snippets at Google wasn't really
anything new or annoying (disclaimer: I've been here about 6 months).

Personally, I think it's great to get the automated email every week with what
the rest of the team has been doing, and you can setup snippet reports for
other teams you collaborate with as well.

These days, I'm using DayOne (<http://dayoneapp.com>) which make it trivial to
type F5 + "met with Bob about new <mumble> for the <mumble>. He said it'll be
ready on Friday". Then, at the end of the week (usually on the Friday
afternoon shuttle), I just read through and cherry-pick the larger items for
my snippets.

------
chrisbennet
So _that's_ what the "S" in TPS report stands for!

------
ZephyrP
In all seriousness, I think if anyone took a large, systematic look at the
nature of productivity gains in the Valley, they would see that the same
patterns underlie their gains just like everyone else's -- Very smart people
in an extremely competitive environment where many people are connected to
other important thoughts and thinkers and of course using high powered
ergogenic stimulants ranging from the popular and relatively innocuous coding
sessions aids Adderall and Modafinil all the way to finishing months worth of
a normal man's work in days with Methamphetamine (or solving deep problems in
virtually every branch of mathematics and finishing it off with a Wolf Prize
:)

------
HPBEggo
Reflection on work is an important step in getting work done efficiently, and
this process forces it quite well. On top of that, it requires little action
on the part of the managers.

Well done, people, well done.

------
jonathanberger
See also <http://www.ididwork.com> that was a YC company in 2008 I believe.

~~~
aymeric
I am getting some server error when I tried to go beyond the landing page.

------
Shenglong
I'd also like to point out that the valley has some of the best weather I've
ever seen in my life. I was only down there for a few days, but every day, I
felt like I needed to do something. That's a 180 from east coast weather, when
it's gloomy and raining every day.

------
trimbo
OKRs started at Intel, not Google.

~~~
michaelochurch
Google shat the bed by hiring a bunch of incompetent execs from culturally
defective companies like Oracle and not telling them to wipe their fucking
feet off at the door. So they tracked a bunch of shit into the place.

The rank-and-file engineers at Google are a really amazing crop of people, and
the founders and early architects were (and still are) brilliant, but the
middle-managers and execs hired from without are so incompetent that they are
flying a plane into the company (the three-word "mission statements", that
idiotic stack-ranking, the idiocy that was downslotting).

------
jfarmer
I've done this at every startup I've worked at, including the ones I co-
founded! Didn't realize it was a novelty.

------
yurylifshits
Yahoo! Labs is using it too.

At the beginning I disliked it. Now at my own project I promote this technique
and enjoy using it.

~~~
nikatwork
As a Yahoo contractor, I did this daily. Filled in a wiki page which was
emailed to the project manager at a set time. I loved it, basically a public
TODO list that makes your workload clearly visible.

The manager could see you were keeping productive, and you could push back on
extra work if you were already 100% busy.

------
squarecat
Well-played: <http://i.imgur.com/qaPhp.png>

------
pnathan
emacs org-mode really makes this work seamlessly.

I've spent various mechanisms in the last few years trying to journal. org-
mode made it work in a fairly sustainable model.

------
georgieporgie
I mentioned that, at my last company, we sent weekly status reports with items
completed and expected upcoming tasks. I was promptly told that status reports
were a sign of a broken company. Apparently, if I'd called them _snippets_
instead, I'd have been applauded for mentioning an innovative business tool?

The thing which is always overlooked in articles like this is guidance and
feedback. Sending "snippets" or status reports into a black hole leads to
engineers feeling isolated and disinterested (on all but the most core
projects). Failing to manage engineers and set clear goals is simply poor
communication.

~~~
snprbob86
Status reports aren't a sign of a broken company. Micro-management, over
communication, and unnecessary process are.

Turns out that many broken businesses utilize status reports as a weapon of
oppression. However some small tweaks, like reminders, team-level sharing,
company-wide search index, and a sane managerial attitude make Snippets
popular with many teams at Google.

Just like any tool, status reports can be misused. However, many non-broken
businesses are fueled by them. You just might not always call it a status
report.

The abstraction over these various tools is that they represent a (1)
communication medium, (2) audience, (3) cadence, and (4) similar content
structure.

Snippets are (1) emails, sent to (2) everyone on your team, (3) weekly, and
contain (4) last week's accomplishments and this week's goals.

Standups are (1) in person meetings, (2) with the whole team, (3) daily, (4)
discussing yesterday's accomplishments, today's goals, and identifying
opportunities for offline collaboration.

Managerial status reports are (1) emails, (2) to your boss, sent at (3) some
frequency, (4) discussing accomplishments, goals, blockers, etc.

You shouldn't do snippets because Google does them. You should figure out a
communication medium, cadence, and agenda/template, which works for you and
your team.

Disclaimer: I'm a co-founder of <http://www.thinkfuse.com>

Our project was in part inspired by Google's snippets (which some teams love
and some teams hate; we loved them) and also inspired in part by the various
enterprise-consumerization startups that are popping up left and right.

Shameless plug: We've got a much grander vision. The most common phrase we
hear in meetings is "How the hell did you get me excited about status
reports?" We've got top-tier investors and real traction. If you're a talented
engineer in Seattle: We're hiring and would love to buy you a beer and get you
excited too.

~~~
ams6110
Standups don't scale though. The company I was with got to the point where
morning standup took nearly an hour as each person talked about what they did
yesterday, what they had planned for today, and any blockers. Worse, the only
person who really needed to hear all of this was the manager. Sometimes you
had interest in what another person was doing because it might impact your
work, but for 90% of the standup you were just standing there, bored, waiting
for your turn or waiting for it to end. Terribly unproductive.

~~~
wahnfrieden
You should have been split up into smaller teams then. 6-7 people with a max
of a couple minutes per will only take 15mins.

~~~
yxhuvud
15 minutes? Perhaps if the shit has hit the fan and there are big problems.
Our meetings take 5 normally.

~~~
wahnfrieden
Yea, it's the upper bound. We usually take about 30s each.

------
michaelochurch
OP totally misses the point about Snippet systems.

The original reason for Snippets was quite a progressive one: to remove the
manager-as-SPOF anti-pattern by allowing employees to market their less-
visible accomplishments internally.

That's said without comment about the _actual_ managerial environment at
Google, where manager-as-SPOF is very much in force (because managers can
abuse the process limitlessly to block transfers).

~~~
dpritchett

        > managers can abuse the process limitlessly to block transfers
    

There was some eye-opening stuff about Google's promotion system here on HN
yesterday:

 _Google New York is pretty 9-to-5 these days, except for people who are
gunning for promotion... and it's pretty hard to build up the rolodex (due to
the "2-up rule", which is that promotion from level N to N+1 will be decided
by a panel of N+2's) to gun for promo every year. So most people work 9-to-5
(actually, more like 10-6:30, because of the dinner) except before a launch if
they believe it will lead to promo._ [1]

I can't imagine how this works well in conjunction with the "choose your own
team and product" ethos we've heard attributed to Google in the past. Maybe
Google's historic growth and profitability has been masking serious issues in
its talent management process.

[1] <http://news.ycombinator.com/item?id=3526263>

~~~
michaelochurch
It was me who wrote that. My observation of Google is that, while it's not as
blandly bureaucratic as a typical big company, and there isn't the mean-
spirited greed of investment banks, the place is extremely _careerist_. People
are laser-focused on the promotion process and the political campaigning it
entails, because the ranks really matter, and not just in terms of
compensation, but how much respect you get within the organization and how
much say you have in what you work on. You aren't a Real Googler until a
certain point on the promotion ladder, and the Real Googler Line keeps rising:
it used to be Senior, but it's shifting over to Staff (the level above
Senior). You can be a Real Googler at Senior, but only if you have it "locked
in" be Staff in a year or two. If there's a sense that you may have plateaued
at Senior, you're not a Real Googler.

 _I can't imagine how this works well in conjunction with the "choose your own
team and product" ethos_

Yeah, that's not true anymore. Google has a lot of icky maintenance work that
has to be delegated somehow. Not only do you not get to choose your project
for the first 18 months, but you don't know what it is coming in the door.
This is one area where Google plays the diva card hard: you have to accept the
job without knowing your project. You might get something interesting. You
might not. More likely, it's the latter.

You can transfer after 18 months, but there's also a "permission paradox"
effect; if you haven't worked on good projects, you have a really hard time
moving to a good project because you're competing (for transfers) against
people who've worked on more exciting and more visible stuff than you have.

A couple other marketing pitches that don't hold up: 20% time is dead. People
get fucked over in "Perf" if they're perceived as actually caring about a
20%-time project. Finally, Google markets itself as a "C++, Java, and Python
shop" when Python is pretty close to deprecated in production so it's mostly
C++ (yes, C++; I am absolutely not making this shit up) and Java. Python gets
a lot of use by managers who still want to code and need a real language
because they can only commit 1/3 of their time to software, but almost all of
the important projects get rewritten in C++.

The other thing I'd say about Google is that the company is extremely good at
collecting talent (they have it down to a science, and their recruiters are
some of the best in the business) and very bad at managing it, as you alluded.
There used to be a morale-destroying process called "slotting": you'd start
out at a "mezzanine" between two levels on the engineer ladder. You'd be given
a job offer (and paid) as an N+1 but actually be "between levels" and you'd
have about a 70% chance of dropping to N when you were slotted a year later.
(Some people got double-downslotted, which was the kiss of death.) The result
was a system that pissed everyone off. If you worked hard, beat the odds, and
got upslotted, you didn't get a bonus-- you just got the job title you were
promised. If you were downslotted, you now had a crappy job title compared to
what you were promised in your job offer letter, and you wouldn't get raises
for a long time on account of being "overpaid" for your level. It was a morale
disaster, and thankfully they got rid of that idiocy, but a process like that
makes you wonder how such an obviously shitty idea got in the door in the
first place.

Career progress at Google is also ungodly slow. The promo rate is something
like 10-20%/year (i.e. each "level" represents about 5-10 years of average-
case work). The slow progress actually makes sense when you look at what
Google is. Most of the work is legacy maintenance in C++, so unless you kill
the lottery and get the best projects, you're likely to end up on things where
you don't learn much and don't really _deserve_ faster promotions.

~~~
mjwalshe
Ah so everyone spends all the time gaming the system sounds just like the PRP
process at BT - Though I suspect its more from Google's blindness to reality
and social skills than HR capturing the system for their own ends to the
detriment of the other stakeholders.

Though 10-20% was heaven compared to BT there used to be 20 or 25 promotions
every 18 months in systems engineering (and that Division had more far more
developers than Google has staff)

Even getting on the short list for a board was a major achivement.

