My colleague and I joined on the same day and were employees #25 & #26 of Walkabout. As we walked out of the meeting room I asked if we would be the last, thinking this was a sizeable number for any startup let alone an early-stage one. I was met with a somewhat incredulous “No, no. Not at all!” That was a red flag I ignored wilfully.

Fast-forward six months and Google was in a lavish, new office with Walkabout fully underway and around 35 strong. The trouble, I am sure, began a lot earlier but this is when I started to really feel it. First, there was the dreaded endless meeting–they lasted for hours with very little being decided. Then, you started having to push people to provide APIs or code changes that you desperately needed for your feature but that they had little to no interest in beyond the academic.

My style is to ask politely and then when I realize nothing is going to be done, to do it myself. This is a prized hacker ethic, but it does NOT work in large teams. There is simply too much system complexity for this to scale as a solution. Instead of shaving one Yak, you’re shaving the entire Yak pen at the Zoo, and pretty soon traveling to Tibet to shave foreign Yaks you’ve never seen before and whose barbering you know little about.

What happened with me was that my pride made me take on all this and I ended up simply failing at it. It is irreconcilably demoralizing to think that you can complete a feature in 2 weeks and find yourself three months in, stuck at work at 3am and neck deep in mounting backlog work.

I’ll admit I considered resigning, defeated.

On Agility

Some of you are reading this and thinking “if only they used an Agile process like Scrum!” Or, “if only you or someone had prior experience with an Agile team.” Well, the sentiment is right but also entirely naive. Before Google, I worked at a company called ThoughtWorks. They are a religiously Agile shop and whose Chief Scientist is Martin Fowler, one of the original signatories of the Agile manifesto. So I knew a thing or two about Agile going in. As did several of my colleagues. Furthermore, this was a team with plenty of very senior ex-Search Quality, Gmail, Maps and Infrastructure people.

To say we should have been better prepared or organized is to miss the point–large teams starting on a new project are inherently dysfunctional. One common consequence of all this chaos is that experienced engineers seclude themselves to their area of expertise. At a company like Google, this generally means infrastructure or backend architecture. A major externality of this is that fresh grads, and junior engineers are shunted to the UI layer. I have seen this happen time and again in a number of organizations, and it is a critical, unrecognized problem.

UI is hard.

You need the same mix of experienced talent working in the UI as you do with traditional “serious” stuff. This is where Apple is simply ahead of everyone else–taking design seriously is not about having a dictator fuss over seams and pixels. It’s about giving it the same consideration that you give any other critical part of the system.

Now, I don’t mean to imply that Wave did not have some very smart engineers working on the UI, we certainly did. But talent is different from experience. The latter is a guard against 3.5MB of compressed, minified, inlined Javascript. Against 6 minute compiles to see CSS changes in browser. Against giving up on IE support (at the time, over 60% of browser market share) because it was simply too difficult. Against Safari running out of memory as soon as Wave was opened on an iPad.

At the end we were close to 60 engineers, with nearly 20 working on the browser client alone.