My Own Pirate Radio

I’ve often wondered how well Google’s management structure works, particularly the high engineer-to-manager ratio. I’d always heard it was about 50:1, but this blog post I came across yesterday suggests ratios of 100 to 1 are not uncommon. Now that’s flat. Superflat. If you have the urge to peer into the murky depths of Google or Microsoft, give the post a read. (Yes, it might be a hoax, but personally I think it’s legit. Besides, hoaxes are people too.)

Management structure differences aside, Google really is a great deal like Microsoft was in its earlier days. It’s as if the same parents decided to have another baby 15 years after their first one. Same DNA.

As usual, the comments provide some of the most compelling nuggets. There is a bunch of good meaty stuff once you get past the initial chorus of “why we oughta fire that two-timin- free-breakfast-eatin’- NDA-violatin’- internal-email-leakin’- big-fat-secret-sharin’- son-of-a-!*@# employee!” comments from ’softies. This one particularly resonated with me:

…Many folks at both places seem to harbor a desire to start their own company ‘at some point’, and virtually no one at either place seems to be fully satisfied with the pace of their career growth, but the benefits and continuous train of internal opportunities keep most of those folks happy and entrepreneurially sedated.
…
Both are probably great places to work, especially if you can reconcile yourself to a nice, comfortable, interesting career, and you have the willpower to prioritize family over work and work email. For those who aspire to more, you’ll need to innoculate yourself against the sedating effect of the benefits and ‘industry influence’, get it [sic], build up some experience and a network, and get out.

Amen, brutha!

I subscribe to a discussion group called “TorCamp”, which is a small slice of software people in Toronto. There is an interesting discussion ongoing about Time Magazine’s “Small is Essential” article on 37Signals, the company that makes basecamp and backpack, and one of the chief promoters of Ruby on Rails. The article implies that small companies are The Way to Go, and that we no longer need to big build organizations in order to get big things done.

My take (reposted from the discussion thread):

There is a sort of “magic” about very small groups:
- you know everyone, what they’re doing, and how your work relates to everyone else’s
- very low communication overhead
- only one leader/manager required to handle tiebreaker decisions
- incompetent people and jerks have nowhere to hide :-)
- you stay focused on the core, because there is generally not enough money, time, or skill to take on on low priority objectives

I’ve found you can keep these qualities in a team up to about 60 people in size. But that was really 60 people subdivided into several smaller groups of, say, 5 to 12 people, each with a group leader, rather than one big 60-person team with a completely flat management structure. So at the core it was still a bunch of small groups, banded together into a bigger tribe. (Anomaly: Google apparently has a 50:1 engineer-to-manager ratio, and I’m curious as to how well that works.)

At some point — a 100 person tribe, let’s say — the team members don’t all know each other, or what everyone is doing, or how it all fits together. So you resort to more communication, more managers, more reliance on formal “deliverable agreements” and architecture and tools (like basecamp) guiding the collaboration.

There’s also a correlation with the nature of the product that’s impossible to disentangle. Small groups tend to take on smaller goals, and build smaller products. Big goals and big products require more brains, i.e. tribes. You can’t argue that taking a spaceship to the moon, for instance, could have been done by a lean, mean, 8-person version of NASA. The problem space was simply too big, no matter how you sliced it. So should we not have gone to the moon? Heck no! We need to do big things too. So small teams are not a cure-all. The world needs big tribes too.

That said, if you can chunk tribe-sized work into an architecture that allows a lot of small teams work on it in parallel, with a minimal number of interdependencies, do it. And I agree 100% about the earlier comment on passion: I’d rather work with 5 people who are passionate about what they’re doing than 10 who feel it’s just a job. Life is too short for the latter.

Related: The Dunbar Number as a Limit to Group Sizes

Researcher Elizabeth Van Couvering recently published research results on how search engine employees think and talk about their work.

In the face of rising controversy about search engine results—that they are too restrictive, too comprehensive, lacking in certain areas, over-represented in others—this article presents the results of in-depth interviews with search engine producers, examining their conceptions of search engine quality and the implications of those conceptions.

She interviewed employees of Google, Yahoo!, MSN, Ask Jeeves, AOL, Excite, Lycos, Infoseek, and WebCrawler, and her report is remarkable in terms of the insider verbatim quotes. (The search industry is notoriously secretive, so getting people to reveal their inner thoughts about it is challenging.) Her analysis reveals that search industry insiders consistently portray themselves as fighting a war, that they justify much of their work in scientific terms — even when trying to deal with unquantifiable issues like public good — and that they understand in a deep way how their business is driven by profit motives.

Her work is on target. And not just for search; her observations apply to every technical group I’ve been part of or collaborated with, both within and outside of Microsoft. We all used similar language “schemas”. We talked about marketplace war, about science for science’s sake. We often shrouded ideology — “censorship is inherently bad” — in technical terminology — “I suppose the algorithm decided to demote that result because its relevance dropped during our last crawl. We don’t decide; the algorithm decides.”. Or, “Sorry, we can’t implement that feature, the current architecture doesn’t allow it and it would take way too long.” Frankly, it was often easier to fight such technical arguments than to fight the underlying ideological battles, because the latter approach generally ended in stalemate. So technical language became a tool for keeping non-techies from influencing product design, and it shielded teams from struggling with uncomfortable thoughts like, “Does any of my work have a negative impact on society?”. I believe this shielding pattern reoccurs broadly in many science and technology fields.

Elizabeth’s methodology — analyzing the actual words people speak — reminds me of ‘The Four Horsemen’: Why Marriages Fail, a radio story that aired on NPR in 2005. It’s an interview with a researcher who talks to couples about their relationships, then analyzes their word choice and emotional tone to predict whether they will eventually divorce or not. Apparently there are four strong predictors of divorce: criticism, defensiveness, contempt and stonewalling. And words that convey contempt for a partner are the strongest predictors of all.

The NPR piece is designed for a mass audience. Elizabeth’s piece is written for an academic audience. I recommend both.

This is a post about making smart career choices within a tech company. It’s inspired by email letters I receive — about one every week or two — from colleagues I worked with and hired at Microsoft. They’re reaching crossroads in their careers and looking for advice on how to make their next decision. In a nutshell, “Should I stay or should I go?”

It’s a familiar question. About once a year I pop up from my rabbit-hole and wonder, am I in the right place? Is there something else I should be doing instead? Is this what it’s all about? Then I put on my peril-sensitive sunglasses and go back into my hidey-hole.

Just kidding. To cope with such soul-troubling times I built a handy little checklist of questions. Here it is:

1. Do you find the work intellectually stimulating? You want a job that’s challenging, after all, one in which you’re learning new things at a manageable clip. You need to scratch that intellectual itch. At the same time, your work environment shouldn’t be so diverse or chaotic that you never build true proficiency in an area. So find a job that’s difficult enough to stretch you and keep you engaged, and stick with it at least long enough to master and complete something substantial.

2. Are you valued fairly for your contribution? It’s no fun doing a job that your co-workers perceive to be low-value. As a program manager, for instance, you can all too easily find yourself doing work that is essentially secretarial… writing specs to match already-existing code, for instance. As a tester, you might find yourself testing something that was clearly written without the slightest thought of quality assurance or product support. Not surprisingly, jobs like that are soul-killing, and management values them little when it comes time to hand out performance rewards. These problems were common at Microsoft when I worked there, especially in engineering-dominated groups that preferred “coding for coding’s sake”.

Find a team where you can truly add value and be part of the core, rather than sit on the periphery. For program management, this means looking for teams with a strong desire to understand their customers, and teams that face a high degree of uncertainty and complexity. For test engineers, this means looking for teams where developers and testers work together from start to finish, rather than paying lip service to the quality assurance role. For developers, make sure the software you’re writing is truly essential to the product, and integrates cleanly with what your co-workers — in all job roles — are doing.

The twice-as-good rule applies here: “If you can’t make it at least twice as good as what already exists, choose something different to work on.” The Office team used that rule to help decide what features to put in a new product version, and I think the rule works well for choosing jobs too.

3. Are you passionate about what you do? If you’re working at a company like Microsoft, or Google, or insert-cool-tech-company-name-here, you’re probably a smarty-pants with a techie bent and strong ability to get the right stuff done. Frankly, you can work pretty much anywhere you want, if you put your mind to it. So, here’s a news flash for you, my fine-feathered friend: life is short. So work on something you actually like. This is especially true in positions that require long, intense hours… sooner or later, and probably sooner, there will come a day when your compensation package cannot possibly make up for burning the candle at both ends. At times like these, and indeed on not-so-hectic days as well, it’s passion that fills the gap and makes the work worth doing. If you can’t get excited about your job for, say, more than half of the time you’re putting into it, move on.

4. Are you working with good people? Do they inspire each other, help each other, treat each other with respect? Or do they just drag each other down? Again, life is short, and there are an infinite number of jobs out there, so it’s incumbent on you to find one staffed with people you like. In my experience, great people are often the differentiator between a good job choice and a bad one.

That’s it. Four simple questions. Learn ‘em. Use ‘em.

Parting advice: if you are at a point where it’s time to move on, do so with grace and integrity. Deliver on the goals you signed up for. Complete the promises you made to co-workers and customers. Hand off your responsibilities so they don’t just drop on the floor. And time it right, too… don’t leave just before a performance review, for instance, because weak managers will often use that opportunity to short-shift you. There will never be a perfect time to move on, but some times are certainly better than others.

Pass it on.

A year and a half after launching their new search engine, Microsoft’s US market share in web search has declined from 13% to 9%, while Google and Yahoo! both gained. Microsoft is treading water while the market overall has grown. Here are the share numbers.

Yesterday brought more bad news for the Windows Live Search team: VP Christopher Payne is leaving Microsoft to start his own company.

It’s hard to imagine how to spin this one positively. Christopher was one of the first to pitch Bill and Steve on building a new search service in-house rather than continuing to outsource to Yahoo!. He played a huge role in recruiting key people to the team, creating a vision, and integrating marketing, business and customer focus into what was undoubtedly a pure engineering team. And as you can imagine, his business performance goals were tied in no small part to gains in market share and profitability. So this is not just the departure of the chief cheerleader and visionary; it’s a sign that success in search is not coming nearly as fast as Microsoft had hoped.

Having been on the team myself I have mixed feelings about this changing of the guard, and I imagine many of the people I used to work with are feeling the same way. When a key leader heads for the door you stop and question what keeps you there. Is it your passion for the technology and business challenges? Your allegiance to the company, the leaders, the team you helped build? The paycheck? How does that stack up against the negatives of the job? (Unless things have changed radically, the main down sides were: unattainable performance expectations pushed down from above, grueling hours, and a maddening culture of prima donna behavior that was tolerated and even rewarded.) Most importantly, how does all that measure up against time you could be spending doing something else? It’s worth doing that math once in a while.

Of course, the search battle is not over. In fact, it’s barely begun. But it will continue to be uphill for Microsoft. From the Seattle PI, March 5: “You have to think that, with the heavy lifting behind it, Microsoft has got to be in a good position to execute, and execute well,” Nielsen NetRatings’ Cassar said. “But they’re competing against two of the strongest companies, between Yahoo and Google, and so Microsoft can’t just execute well. Microsoft needs to execute in an extraordinary fashion in order to just keep pace.”

Good luck to all the warriors.

update March 8: Danny Sullivan gives some history on search at Microsoft.

Happy New Year!

I hope 2007 is starting off on a peaceful note for you. You’re probably reading this from your office, I’m guessing, evading work and responsibilities for just a few moments more before everything roars back into full swing around you. I’m doing the same: writing from my home office, and using a flu as my excuse for being a bit of a recluse and attempting to achieve only easy things today. So begins the year.

I hope also that 2007 is both happy and productive for you. So in that spirit, here is some inspiration from The Economist’s Dec 23rd 2006 issue, which focuses on the theme of happiness:

…some fortunate people … found deep satisfaction from losing themselves in their work: “forgetting themselves in a function”, as W.H. Auden put it. … This happy state, which Mr Csikszentmihalyi calls “flow”, arises most often in work that stretches a person without defeating him; work that provides “clear goals”, “unambiguous feedback” and a “sense of control”. Mr Csikszentmihalyi is now one of three scholars behind the “Good Work” project, which aims to make “flow” a more common experience in professional life.

Makes sense to me.

I wish you much good flow in the year ahead, both at work and at play.

Google’s Steve Yegge wrote a lengthy critique on Agile development about a month ago. The piece is ostensibly about agile development, but it’s really more about how Google works and why it doesn’t need capital-A Agile methods.

My favorite bit: “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.”

Sounds like fun. It’s not something every company can do, though, especially not well-established ones. The way I see it, this amazing degree of freedom stems from two particular luxuries.

Luxury #1: Incredibly deep pockets. When you’re flush with cash you can hire the best and brightest, and reward them heavily. Google is so rich that it can spend disproportionately on acquiring and retaining talented people, even when going head to head against its richest competitors. And its business model is so highly profitable — again, compared to competition — that it should be able to continue doing this indefinitely.

Luxury #2: Very few dependencies. Google delivers software straight to the web and millions of largely nameless customers, rather than into the hardware production pipelines of a handful of OEMs or the IT integration pipelines of a few thousand corporate clients. That’s why they can pick and choose what to build, and when to ship it, if ever. That’s why they can label products as “beta” in perpetuity if they wish to: their customers aren’t yet demanding any more than that. And that’s why Google developers can vote with their feet on which projects to work on: at the end of the day, there isn’t a customer on the phone line holding them accountable for a slip in the schedule of Project X.

Lucky ducks.