Quality Gate

I was thrown into a project drowning in quality problems. On my first day as quality PM, I greeted the manager sitting next to me. He ignored me.

Every release triggered incidents. Rollbacks kept happening. New features fell behind schedule. The business was feeling it.

What needed to be done was textbook clear. Set up code reviews, introduce linting, create changelogs for each release. Write automated tests, organize manual pre-release testing, run rehearsals and load tests as needed. All correct. But being correct alone doesn't move a team.

It was a big project. Separate dev teams per microservice, over fifty people total. Everyone wore t-shirts and jeans. I showed up in a suit every day. Harvey's advice — first impressions last. Lazy as I am, I ended up with a reputation for being dead serious. An outsider is a foreign body. Especially one who interferes with development in the name of quality. That looks like the enemy.

Next thing I did was lunch.

I chatted with every team lead and invited them out. We talked tech, but what mattered more was putting a face to the role. Showing I wasn't the enemy. Quality gates can be built as systems. Getting people to accept them is a human problem.

I kept greeting the manager next to me every morning. No response. Never once. I kept at it anyway.

It took time, but quality metrics gradually improved. Release-by-release quality gates took shape. Practical documentation and automated tests fell into place. Release incidents dropped. Rollbacks stopped.

At some point, the manager next to me and I started trading jokes. We went to lunch. That was my greatest victory on this project.