Silicon Valley’s Productivity Secret
blog.idonethis.com
blog.idonethis.com
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
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?".
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).
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.
"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.
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.)
In true "D'oh!" fashion, I didn't find out about this feature until a month before Snippets were discontinued.
As in who still works there? Who is really important? Or who is doing interesting projects? What does 'in' mean in this context?
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.
Doesn't matter because I don't think anybody's been reading them either. Most of my team doesn't use them at all.
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?
This is a case where a few hundred dollars on a good domain name would go a long way.
The product seems fine, but the name is irreparably bad.
Neither was "You've Got Mail."
Is it just the superfluous 'got'?
But, like "idonethis", and like you, we thought our version was just.. stickier. And it stuck.
Downvoter, this was my point: Sticky beats grammar. (See also: Think Different.) Sorry if I was too terse to make it clear.
We later ran across another implementation of snippets here: https://github.com/kushal/snippets
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.
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.
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.
That has even more value, perhaps, than the meta-cognition of thinking about what you need to think about.
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
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.)
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.
Well done, people, well done.
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).
At the beginning I disliked it. Now at my own project I promote this technique and enjoy using it.
The manager could see you were keeping productive, and you could push back on extra work if you were already 100% busy.
I've spent various mechanisms in the last few years trying to journal. org-mode made it work in a fairly sustainable model.
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.
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.
"You shouldn't do [standups] because [agile consultants] [tell you to]. You should figure out a communication medium, cadence, and agenda/template, which works for you and your team."
I regularly spend a full hour a day in standups, and the useful content to me in them could be communicated in 5 minutes or in 2 emails.
So one guy pulled out a timer. You've got one minute. After one minute, if it's so worth saying that you'll keep talking through the "bzzt bzzt bzzt bzzt" of the annoying alarm, you go ahead. But now you're getting direct feedback against talking without need.
Of course, I make no claim this would work for any other group, much less any particular group. But it helped that team get standups done faster and more productively.
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).
> managers can abuse the process limitlessly to block transfers
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.
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.
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.