google

The teams I manage at work pride themselves on moving quickly. We release features, adjust UI, and run experiments at a rate where it is difficult to follow everything which is going on. I see one of my responsibilities as a manager to keep up this pace of execution, but in a way which holds a high bar for quality and allows for feedback from stakeholders who aren’t following every design discussion or code review.

We had a problem of the sort where an engineer would make some kind of change and then later on get asked “why did you turn this on?”, “why didn’t you tell X?”, “did you consider A, B, C?”. This was adding uncertainty to the development process - engineers would be uneasy about rolling changes and felt pressure to get buy-in from every stakeholder before shipping even small modifications to the software.

I wanted my team to feel safe following a product development process where they wouldn’t get second guessed or called out if they did things the agreed-upon way. Using my favorite productivity tool prototyping platform (Google Apps), I created a form which would handle collecting the details of planned changes, format things nicely, and notify all appropriate stakeholders. We have an agreement with the team now that engineers are “covered” making changes as long as they fill out the form as soon as possible during the development process. If an engineer uses the form, ships a change, and then someone has a problem with how the feature was shipped or communicated, then I intervene and walk the stakeholder through our tracking process. This has been a great step toward making engineers feel more empowered to ship changes, giving stakeholders a concise summary of upcoming changes, and has the side effect of creating a clear log of everything our teams are contributing.

I’ve gotten some interest in this internally from other teams, and I think it’s a generally useful tool for any team of software engineers. I’m going to walk through how it works and was built, with the hopes that you may find something like this useful in your development process.

Way back in late 2010 I was lucky enough to visit the remote Google office containing the office of Vint Cerf. He wasn’t there, and apparently spends much of his time traveling, but I still felt honored to be able to see his workspace, knowing that I had the privilege of working in the same company at one time, the same cheaply printed nametag on his office wall as the one which used to mark my own cube in Mountain View.

…was August 25th, 2011. On September 6th, 2011 (four years and two days after I started my first Silicon Valley job at Google) I will be starting a position as Developer Advocate at Twitter.

I’m at Moscone Center in San Francisco this week, as a speaker in this year’s Google I/O conference. My session is tomorrow (May 11th) and as a first, I’ll be livestreamed over the internet. If you’re interested in viewing the session, you should be able to see it here, starting at 10:45am PDT. We’re bringing a lot of great content, and will try to bring the funny as well.