work

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.

The first time I remember hearing the term “hackathon” out loud was when I was a couple weeks into my employment on Google’s Developer Relations team. I was trying to figure out what I was going to do to help bootstrap developers for the nascent OpenSocial project. Patrick Chanezon, the Developer Advocate on the project, said something like “we’re going to cold call a bunch of social app authors and hold a hackathon to test out the API” which hadn’t really been done before—we were helping pave a new path for the company at the time. That first event was kind of a mess. I remember stalling for time with a room full of developers since our test server wasn’t booting correctly. An engineer was hurriedly trying to fix things so that the attendees could get to work.

Friday, February 24th, 2017 was my 1999th day of employment at Twitter, and my last.

I’ve been a bit nostalgic about this, so I reread my initial thoughts on joining Twitter in 2011 to laugh at how young and naïve I was five and a half years ago. I know that when I first started I didn’t really have a great idea of what people did in fast growing companies. Did they jump around and try to work on the most critical problem at the time? Did they focus on small areas and grow them into large ones?

… have met and in many cases exceeded the expectations I had when thinking about joining the company. Obviously I’m still in the honeymoon period and things are still moving fast, but the energy and culture of the place have been inspiring. I’ve found a few things particularly worth gushing over:

During my 4 years at Google, I conducted over 70 interviews. While there were definite hiring droughts, there were several months where I would have 2-4 interviews a week. Since most interviews are just 45 minutes, an interviewer has to get a good idea of a person’s abilities in a short time span. Usually this means that one major mistake can make the difference between a candidate getting a passing score or a failing score. I’ve certainly had interviews start off really promising, but go quickly downhill when the candidate made a few key errors.

…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.

After an amazing Google I/O session last week, I’m doing a bit of touring around on the East Coast until June. There’s a ton of GTUGs within driving distance of NJ, so I’m hitting up a few.

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.

Last year between the time that the Chrome web store crazied everything up and the holidays shut everything down, I was invited to give an educational session at Add-on-Con 2010 on the topic of Chrome extensions.