In Silicon Valley, tech moves at the speed of light. Here's what it takes to keep product launches on schedule and successful.
Engineering Program Management
In a nutshell, EXECUTE. Get shit done. You're the one filling in often giant gaps between teams to launch a product. You pull in engineering, legal, marketing, executives, product managers, PR, customer support, at the appropriate level of engagement at the right time to take a product from paper to consumer launch.
Program Management isn't as black-and-white as to create a schedule, email it out, and occasionally check in on progress. There's an interpersonal skill set to divining when things aren't going right and righting them before they become issues. Ideally, you make things run so smoothly that people don't notice bumps (or even notice you!), and eventually you want to build your team to be so self-sufficient that you scale yourself out of a job.
Communication. So much of what you do is based on human interaction. You've got to read between the lines of people's emails and short replies on bugs, you've got to get up and talk to people face-to-face, you've got to be clear in documents.
Writing. You don't need to be a literary genius, but writing is at the heart of your job. You're writing documents that intersect product vision documents and engineering architecture documents. You first talk to your team about XYZ that needs to get done, then you follow up in email or document because most will misinterpret a detail or forget.
All engineers will benefit from proper grammar and document organization. Who takes someone seriously who doesn't have decent mastery of English and can't spell? And how is anyone going to follow your 7-tab-indent that makes your document start in the middle of the page? It's my biggest nit-pick about engineers: writing matters. You'll get so much more done and reduce everyone else's work second-guessing you. That's one fewer meeting on everyone's plate.
Empathy. Interpersonal connections are gigantic and underappreciated. Talk with your extended team and get to know them--what are their hobbies? Do they have kids? You need to know that Amy's taking a vacation in 2 weeks and rejigger the engineering schedule or make sure she has a backup. Knowing that Tom, a reliable engineer, has more in his personal life in the next month will go lengths toward understanding his output and building trust with him.
Lead without authority. Program Managers don't have anyone reporting directly to them--product managers, engineers, marketing, legal report through their respective chains. If you're not leading by direct authority, you need to lead through respect and trust--you'll get a lot more done than if people follow you just because they should listen to you.
Engineering. You've got to have enough engineering knowledge to understand the architecture of the project and coordinate appropriately.
Prioritization as nonpartisan mediator. You lean on your engineering lead and product lead for data on what's important, but at the end of the day, you call the shots between a cool feature that may have a 10% uptick for 5% of users or a backend engineering change affecting the platform stability that's hard to quantify, but "getting riskier" every day.
You're also responsible for prioritization cross-team--it's almost never that each team you integrate with has the same priorities as your direct team, and fitting them together to a single launch is like a constantly-shifting jigsaw puzzle. You need to communicate well, navigate, and negotiate.
My Specialty: Partner Management
I specialize in program management with external partners, that is, companies outside yours (i.e. Google) that you need to integrate with to launch a product. These companies often don't move at the speed of light like Google does, as they're not even in the tech industry. Keeping priorities and schedules aligned inter-company is a non-trivial task. I've worked on Google AdSense, TV ads (no longer around), Toolbar (remember pre-Chrome?), Chrome distribution, mobile HTML 5 apps, Android, and Maps.
On Android, I was a program manager for Android partner relationships. Android itself is the mobile operating system software, but Google fosters an ecosystem between hardware OEMs like LG and Asus, global carriers like AT&T and Docomo, and app developers on the Google Play store. I managed projects from bill-to-my-carrier-account on Google Play, managed the partner implications of the Android-Market-to-Google-Play rebrand, and managed a couple Google Nexus hardware devices. Device launches included working with the hardware OEM day-to-day to get the in-development, unreleased Android version working on new phone hardware (literally, get a phone to boot Android and do all the "phone" things you expect like take photos) and organizing legal, marketing, etc. to launch the device.
The Day to Day
Morning email triage. I got through the important updates and questions, starred my to-do list, and saved interesting emails for later. Thank god for GMail Priority Inbox.
Prep for morning engineering standup. The bug burndown rate looks pretty good; after last night, down to 6 P2-or-above bugs. Chat with engineers to see if we can get a release candidate by end of week. My head won't be on the chopping block this morning!
Meeting with product manager about v2 since we're getting close to launching v1. My engineering lead and I ask questions to clarify the v2 features. Mental note to sync with the engineering lead in a couple days after we both have a chance to digest.
Someone filed a P0 bug. Better look before my QA lead and release manager barge down my door after I promised we were ready for release candidate. Bug looks suspicious, I downgrade to P1 and talk to engineer to get it prioritized on his plate for the day.
While in the kitchen, I heard a rumor about a new awesome project at Google. Sounds like it'll need deep integration with internal team X that we're integrating with as well, and they're on the critical path. I set up a lunch catch-up with team X's engineering lead to see if this new project will affect our schedule. I've got a good relationship with him, so he'll be upfront.
May as well walk to marketing and see if anything's new--I like to see their mockups anyways. I find out that they want to use eco materials for packaging the product. I better chat with the packaging engineers to make sure the colors marketing wants to use on the box will work on the eco material. I cross-check the budget we gave to packaging in the build-of-materials (BOM) and it's 3x.
Email head of marketing and exec lead to figure out the budget and BOM cost with the new packaging.
Weekly 1:1 with engineering lead. Quick check to see that we're on schedule, I express concern about any engineers' progress, we go over the initial plan headcount and schedule for v2.
Weekly meeting with my team in Japan, Korea, and Singapore, to see how the rollout is going. Business development is excited to sign a new potential partner, but they want custom terms that will significantly affect the engineering schedule (silently curse). We really have to stop custom technical deal terms. I'll have to raise this concern to the program exec...again.
I'd better spend some time thinking about the migration plan from v1 to v2 for partners. It's more concerns and questions than answers now. I add collaborators to the document to help--we'll see how far we get by end of week, and I set up a meeting next week if we can't get it done via document.
Nighttime, time to watch shows with Jeremy. Damn, that elusive bug that was filed today just happened! No one else was able to reproduce it today with a bug report. Sorry, Jeremy, I pause to take a bug report and file it.
10:30pm. I know I promised myself no email after 10:30, but we'll lose 1 less day turnaround if I answer questions from my team in Asia, plus I know they really appreciate it. God I hope I don't dream about work again.
Morning, weekly sync with team in Europe, same exercise, go over the deal pipeline, integration status with their partners, and any bugs or feature requests that need prioritization.
QA lead files a new bug--how does he find so many? I guess that's why he's QA lead. We're now growing bugs and decreasing days. My head's on the chopping block in this morning's standup.
Silently curse the dogfood (testing) group hasn't filed any bugs on this issue when I know more people must have encountered it--it happens with the most popular video streaming app, and it can't be broken at launch. I put together the release notes for the dogfood group, pleading them to take a bug report if it happens. I also set up a meeting between the the 3rd party app developer and our hardware OEM since it looks like a security credential issue between the hardware and the app.
Shoot, haven't double-checked that the OEM and the app developer have signed a non-disclosure agreement (NDA) yet. I double-check with each of them and with my legal team.
While I'm on the subject of testing, I need to put together a dogfood plan for v2. Is v2's release stable enough? How many people should I add to the dogfood? I'll be responsible for triaging all the bugs that come through, so I don't want to expand too rapidly, but we need time to discover and fix bugs.
Someone emailed the template for the quarterly exec program review. I need to add my slides today about program status, schedule, risks, and mitigations. I'll review the whole deck later to make sure other team leads tell the same story--people have a tendency to paint a rosier picture of their own team.
Time to put together the weekly program update. It always feels like a pain, but everyone likes seeing stats and rollout numbers, and there's no greater motivation for the team.
I stop by the Business Intelligence team to see if I can get a dimension added to our metrics. I doubt the metrics I'm hearing for a new feature from the product team and want to double-check it. I love working with the BI team--they're so not entwined in the day-to-day. And I think they like working with me, since I'm not screaming down their necks for data the night before an exec presentation like others.
Finally! Time to start the launch process. I've kept everyone in the loop so each team's lead should flip their launch bit easily. QA's happy now, too!
It's been long enough post-launch that I think I can scale myself out of the day-to-day. I spend time writing a document for a new, more efficient process. Then I'll be able to spend more time on v2.
Rinse and repeat.