Silicon Valley’s Productivity Secret(blog.idonethis.com)
blog.idonethis.com
Silicon Valley’s Productivity Secret
http://blog.idonethis.com/post/16736314554/silicon-valleys-productivity-secret
32 comments
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?".
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?".
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).
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 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.
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.
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.
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.
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?
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.
"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.
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.)
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.)
Mondrian has a feature that lets you automatically generate a snippet e-mail based on the CLs you've mailed off, submitted, and reviewed in a given week.
In true "D'oh!" fashion, I didn't find out about this feature until a month before Snippets were discontinued.
In true "D'oh!" fashion, I didn't find out about this feature until a month before Snippets were discontinued.
> 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.
As in who still works there? Who is really important? Or who is doing interesting projects? What does 'in' mean in this context?
As in who still works there? Who is really important? Or who is doing interesting projects? What does 'in' mean in this context?
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.
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.
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..
What have you been using them for then...
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.
Doesn't matter because I don't think anybody's been reading them either. Most of my team doesn't use them at all.
That's exactly what happens to me with my personal idonethis,
at least I'm using Team idonethis: http://idonethis.com/habits/ the right way.
Are the snippets collected into a public area?
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?
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?
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).
An ex-googler friend and I made a similar tool as a weekend project a while back http://www.snptz.com/ (code: https://github.com/tedpower/snptz)
We later ran across another implementation of snippets here: https://github.com/kushal/snippets
We later ran across another implementation of snippets here: https://github.com/kushal/snippets
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.
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.
This is a case where a few hundred dollars on a good domain name would go a long way.
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.
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.
The product seems fine, but the name is irreparably bad.
> "iDoneThis" isn't even proper grammar
Neither was "You've Got Mail."
Neither was "You've Got Mail."
Maybe I can't see it because the phrase is already in my head buy what exactly is incorrect about "You have got mail?".
Is it just the superfluous 'got'?
Is it just the superfluous 'got'?
Yes. We used to get hundreds of letters from English teachers pointing out that the correct phrasing was "You Have Mail". In fact, at one point, the AOL welcome screen said "You Have Mail", even though the voice still said "You've Got Mail".
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.
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.
Will take a look at it. Thanks! I don't always go up to the www version of blog.* domains and missed the sidebar.
idonethis.com provides exactly this service.
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.
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.
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.
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.
I work at one of the companies he mentioned. We don't actually use Snippets.
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...
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.
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.
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.
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.
That has even more value, perhaps, than the meta-cognition of thinking about what you need to think about.
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
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
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.)
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.)
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.
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.
So that's what the "S" in TPS report stands for!
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 :)
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.
Well done, people, well done.
See also http://www.ididwork.com that was a YC company in 2008 I believe.
I am getting some server error when I tried to go beyond the landing page.
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.
OKRs started at Intel, not Google.
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).
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).
I've done this at every startup I've worked at, including the ones I co-founded! Didn't realize it was a novelty.
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.
At the beginning I disliked it. Now at my own project I promote this technique and enjoy using it.
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.
The manager could see you were keeping productive, and you could push back on extra work if you were already 100% busy.
Well-played: http://i.imgur.com/qaPhp.png
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.
I've spent various mechanisms in the last few years trying to journal. org-mode made it work in a fairly sustainable model.
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.
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.
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.
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.
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.
Forgive me for quoting/paraphrasing myself, but...
"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."
"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."
On my previous team, even with 8 people, too much yakking made standups too slow, and indeed you had many people bored just waiting. No one thought eliminating standups was a good idea, though.
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.
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 bigger problem with standups is when you are in a role such as operations, where you are often involved (extremely peripherally) with many development teams, each of which wants you at their "20 minute" standup.
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.
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.
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.
15 minutes? Perhaps if the shit has hit the fan and there are big problems. Our meetings take 5 normally.
Yea, it's the upper bound. We usually take about 30s each.
[deleted]
I agree. I fail to see what is different here.
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).
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.
[1] http://news.ycombinator.com/item?id=3526263
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.
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.
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.
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.
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