Google as an example of the new human enterprise?

An old article by net standards (way back in the year 2006), but nonetheless an interesting article on what it’s like to work for Google as a developer. Does this sound much like how your organization works??

I’m going to talk a little about Google’s software development process. It’s not the whole picture, of course, but it should suffice for today…

From a high level, Google’s process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:

– there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

– developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

– Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

– developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it’s not their main project.

– there aren’t very many meetings. I’d say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.

– it’s quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.

– there aren’t Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I’ve ever seen.

– even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don’t work insane hours unless they want to.

These are generalizations, sure. Old-timers will no doubt have a slightly different view, just as my view of Amazon is slightly biased by having been there in 1998 when it was a pretty crazy place. But I think most Googlers would agree that my generalizations here are pretty accurate.

How could this ever work? I get that question a lot …

First, and arguably most importantly, Google drives behavior through incentives. Engineers working on important projects are, on average, rewarded more than those on less-important projects…”
read more: Good Agile, Bad Agile by Stevey

At Firestoker and with the idea of this organizations like Consulting2.0, an idea we talk about what a flatter, more fluid, more individual-empowered workplace could and should be able to look like. It seems that Google, an organization that breathes innovation in so many ways, may not surprisingly already be leaders in this area.

Any Googlers out there able/willing to comment?

Posted in Archive, Business | 2 Comments

Are we really friends? The trouble with buddy lists in social applications.

The trouble with buddy lists is that we end up collecting friends like baseball cards. Because I’m on your buddy list, it could be because we’re really closely connected, it could be because we met once at a conference two years ago, or it could be because we both tacitly just want to make ourselves seem slightly more important or popular by having a large number of friends next to our name.

Letting users browse each other’s buddy lists is a great way to discover other people on the system you might want to add to your list (one valid use case). But in reality, public buddy lists are pretty terrible at what should be their primary purpose – as a way of giving any understanding of who someone really is or their true set of social relationships/connectedness.

Just by virtue of being public, buddy lists get distorted by social pressures for the following reasons:

1. Pressure to accept buddies. It feels impolite to turn down a buddy request even if you are not truly closely acquainted with somebody.

2. Popularity contest. There can be a bias to maintain a big list to impress others.

3. No granularity. Most social networks don’t have much way of indicating what sort of relationship you have with somebody. Facebook for instance is a little better at this, we met randomly, we are part of the same organization, we are dating etc. but for the most part the connections are binary and not granular. We’re either friends or not – but not, are we a close or a weak tie?

4. It’s socially awkward to take people off. People rarely take people off their lists as the more public your list is, the more awkward that might be.

And don’t forget Sampling bias. For many social networks, the breadth of your buddy list may say more about how much time you spend with other computer nerds, rather than saying anything useful about the quality and breadth of your actual connections to people in the “real” world (the 1st life).

By comparison, this is why subscribing to people by rss is great and why I’m in no rush to make my OPML public. Because it means I can read who I want to read as often as I want to read them, without my actual relationships with these people being distorted by social pressures. And if my interests or connections change over time I can quietly unsubscribe from people without it being a big deal or offending anyone.

So, how could social networking applications solve this buddylist problem? Here’s one idea, maybe not applicable for all networks but one that could work well in a say… an Enterprise 2.0 platform

Keep 2 lists.

Sure, keep an explicit buddy list that you control, but make it private.

And then let for the purpose of being able to broadcast an accurate portrayal of a user’s actual “aboutness”, let the system keep track of a user’s public buddy list implicitly.

Imagine a last.fm type system that reports back to you on the actual number of your interactions with people within the system and the extent to which those interactions are reciprocated.

The system could then easily spit back for the benefit of each individual user statistics on the “aboutness” of everyone in the organization (or at least on their current professional connectedness) like little last.fm-style bar charts of who you work with most closely that you could display on your profile page. Weighted by relevance and always up to date (much unlike any official org chart I’ve ever seen on a corporate intranet).

In fact, throw out the old org chart while you’re at it. What you’ve got now is a practical working map for for modeling the new enterprise.

Also implied by this idea is that if you’re going to appear connected to someone, you’ll actually have work at maintaining that relationship.

Are you ready for this new level of social transparency? You can count me in.

Posted in Archive, Business, Uncategorized | 9 Comments

Heading to SanFran March 21-25

Thanks to some friendly suggestion on our behalf, Jevon and I have been offered a spot on the roster at the Under the Radar Conference on the 23rd of March [upcoming.org]. We’ll be showing off the Firestoker project as it currently stands in development (and it’s starting to develop nicely). Secondly, if we can finagle ourselves an invite again, I’m also hoping we’ll make it to the STIRR mixer on the 21st [upcoming]

So I’ll be in the bay area March 21st to 25th, if you are, or will be, down there during that time and would like to meetup, let me know!

UPDATE: Oops! forgot I need to be back on the east coast on the 24th. (thank you Orbitz/AirCanada/United for 24hr ticket cancellation option). I’ll be in the bay area March 21st to the 23rd and a (shall for now be kept secret) East Coast location the 24th and 25th of March.

Posted in Archive, Business, Personal | Leave a comment