October 20th, 2011 by adam

Steve Yegge’s Google Platforms Rant is not so much a rant as a sign of someone fighting an inappropriate culture. We saw stuff like this a lot at NCsoft when people were trying to turn around the $100 million clusterf*ck that created hundreds of redundancies all the way to director level.

It’s a great article, but a couple of the key points resonated with my own experience of Google UK’s hiring practices a couple of years ago. There was clearly a lot wrong with the internal culture, but as an outsider I couldn’t quite put my finger on it. Here’s the crux of Steve’s post (but seriously – read the whole thing, it’s rich and meaty):

That one last thing that Google doesn’t do well is Platforms. We don’t understand platforms. We don’t “get” platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.

But no. No, it’s like our tenth or eleventh priority. Or fifteenth, I don’t know. It’s pretty low. There are a few teams who treat the idea very seriously, but most teams either don’t think about it all, ever, or only a small percentage of them think about it in a very small way.

It’s a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they’re building products. And a stubby service is a pretty pathetic service. Go back and look at that partial list of learnings from Amazon, and tell me which ones Stubby gives you out of the box. As far as I’m concerned, it’s none of them. Stubby’s great, but it’s like parts when you need a car.

…and finally, reading that, it clicked for me what I saw that was so wrong:

Google has forgotten what a Product is

“It’s a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they’re building products.”

That pair of sentences, back to back, is the problem: people outside Google would put the word “except” in between. Googlers put the word “because” in between. Google’s cultural definition of Product has got lost and perverted somewhere along the way, and now looks and smells like the real thing but is – to the rest of the world – a fake. Except Google – internally – can’t see this.

Every Googler I talked to worshipped at the altar of Product-as-King; three quarters of them would then – even in the same sentence – admit that they hated Product, didn’t believe in it, and felt it was a waste of time — “get out of my face with your product BS, and let me write beautiful code in my Ivory Towers, and leave me alone”.

They were smart people; they never said this explicitly (although one came very close – and you could see the moment when he had the thought: “oh crap; if anyone else hears I said that…”, then backtracked very hastily) – instead they frequently said mutually conflicting things, and dressed them up in enough abstractions that you could pretend that they weren’t conflicting. They were very good at it – I could tell there was a crack, but I couldn’t work out where the fault-line lay.

Google’s illusions of Product

As Steve puts it later on:

Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don’t get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: “So is it the Stalker API?” She got all glum and said “Yeah.” I mean, I was joking, but no… the only API call we offer is to get someone’s stream. So I guess the joke was on me.

Product. Platform. Since when have those been mutually exclusive? Not in this Millennium, I believe…

And even when Google gets over their hatred of Platform, even with something as simple as the pixels that their apps put on screen, they’ve jumped the shark:

You know how people are always saying Google is arrogant? I’m a Googler, so I get as irritated as you do when people say that. We’re not arrogant, by and large.

But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we’re being fools. You can attribute it to arrogance, or naivete, or whatever — it doesn’t matter in the end, because it’s foolishness. There IS no perfect product for everyone.

And so we wind up with a browser that doesn’t let you set the default font size. Talk about an affront to Accessibility. I mean, as I get older I’m actually going blind. For real. I’ve been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they’re quite brazen about it, and Fuck You if you’re blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.

It’s not just them. It’s everyone.

Any genuine Product person would run screaming from that situation – there’s nothing salvageable. It’s like someone coming to you with their design for a chocolate teapot: “Once you’ve had your tea, you can have a tasty chocolate treat too!”, leaving you wondering: where do I even start with trying to explain to this person what they’re missing?

October 10th, 2011 by adam

With Scrum, you’re constantly focussing on:

How does the application look / work for the user *right now*?

…to the extent that you care more about “does this feature work for the user?” than “is the code/art/architecture for this feature ideal?”.

“It’s not done” … “but it looks done!”

We regularly get situations where a feature *appears* to work, to a casual observer – but on deeper inspection, it’s clearly broken in one or more significant ways. Sometimes, the “broken” parts are so obscure that you’d need help to even find them. Other times, they’re obvious if you try to to use the feature more than just once or twice.

In Scrum terms, it’s pretty clear what’s gone wrong: the Product Owner didn’t describe the feature clearly enough (they implicitly included functionality they didn’t really care about, … or they described it too vaguely to be implemented well).

Scrum’s in-built check/balance against that is the Team. The developer who adopted the task should have rejected it during the Planning meeting, should have insisted on a clearer User Story (or a more explicit feature description).

But in the real world, this stuff happens. Leaving the issue: What do you do next?

One technique: Divide and Conquer

Here’s an approach I’ve been experimenting with recently.

When it happens, you split the feature description in half, re-defining one half as the part which is done + working, and the other half as the part which isn’t working. Or into 3, 4, etc – if there’s multiple “player visible” ways in which it’s not working.

This seems to work pretty well – it lets us independently prioritise “the bit we’ve already got (hence: zero extra dev cost)” and “the hard stuff that’s not working”. And quite often, we end up redesigning some other part in a way that makes the broken edge-cases no longer exist – so we never need to fix them.

…but I’m still experimenting with it. I’m sure we could do our Planning meetings better – both from the PO side (more detailed descriptions, more PO planning) and/or from the developer side (more questioning, demands for more detail).

August 10th, 2011 by adam

I’ve encountered many managers who are in love with the IDEA of supporting their team, but not the REALITY.

Typical examples:

  1. “My team are great. I push them hard and they deliver great stuff on time” (in reality: the team resents the bullying, self-aggrandizing jerk)
  2. “I’d do anything for my team. When they’re working til midnight for me, I stay late too – I even buy them pizzas!” (subtext: they’re worth $6.99 for 4 hours of overtime, and no sleep. Also: they should be grateful I even stayed around, playing minesweeper while they worked)
  3. “I like to think of myself as a sh*t-umbrella: I take the sh*t for my team from my boss” (easy to say when “sh*t” is nothing more than a few vague fears about quality; but what about when the REAL sh*t arrives; is that swishing sound you hear the sound of your manager covering their own ass? Or just of them throwing you into the path of danger, a human-shield to protect them?)

So, here’s a refreshing (if somewhat old) counter-example:

How Pixar Bosses Saved Their Employees from Layoffs

June 6th, 2011 by adam

I’ve been working on a new Scrum client for ScrumManagers, Scrum Teams, and Product Owners.

We’re ready for Alpha testing now – it’s simple, fast, and a bit ugly … but we’re using it for very simple projects already.

If your team uses Scrum, and you’d be interested in trying this, please send us a quick email via the application form here (at minimum, need your email address and some info about the projects you’d be trying this on and how soon):

Alpha application form for ScrumBurner