Google VP Michael Bachman on Engineering Productivity – Part 2 Summary and Q&A

This article documents the second part of the record of Google VP Michael Bachman's talk on engineering productivity.

Background: The term “Engineering Excellence” originated at Microsoft, while “Engineering Productivity” (EP) was first formally introduced by Google, which renamed its QA/Testing team to the Engineering Productivity team in March 2016.

Michael Bachman, now Engineering VP at Google and a 16‑year veteran of the company, shared his insights during an April 2018 community session.

Q&A Highlights (Part 2):

1. Rollback frequency: Depends on service maturity and business scale; small startups may accept frequent rollbacks, while large‑scale services avoid them.

2. Role of the EP team on production issues: SRE handles on‑call pager alerts; EP teams focus on closing gaps and eliminating recurring problems.

3. Handling diverse languages, OSes, build and test pipelines: Google standardises metrics with a unified model and storage, abstracting data across languages (e.g., JavaScript services) into a common pipeline representation.

4. Internal data model: Google has built a proprietary model long before the industry caught up; details are not publicly disclosed yet.

5. Visualising data for teams: Google defines common metrics such as deployment speed, frequency, rollback count, and pager issue volume, and uses a multi‑level health bar to set clear targets for teams.

6. Encouraging tool adoption: Forced adoption is avoided; tools are introduced bottom‑up, building consensus by addressing real productivity pain points.

7. Test selection: Tests are evaluated by ROI and stability; unstable tests are isolated from the main test suite.

8. Static scanning: Google performs static code analysis as part of its quality process.

9. Future focus of the EP team: Prioritisation of work is driven by limited engineering resources; some tools are deprioritised as needs evolve, with mobile development (e.g., iOS) noted as a challenging area.

10. Custom vs. unified tools: While a horizontal team strives for tool standardisation, Google’s culture encourages engineers to build bespoke tools when needed, creating tension between innovation and consistency.

11. Experimentation and rollout: EP tools are released to a small percentage (≈1 %) of engineers for experimentation before wider adoption, mirroring Google’s broader A/B and canary release practices.

For the full PPT, readers are invited to follow the public account “持续交付2.0” and comment “EP‑PPT”.

Promotional material: The article also advertises the book “持续交付2.0: 业务引领的 DevOps 精要”, offering a QR‑code and purchase information.