Federal Reserve Bank of Boston Innovation & Technology Culture

What’s your rule for fast, safe releases — and what KPI proves it works?

Immutability and idempotency. Since our platform supports instant payments for financial institutions, while we do value speed, the safety of our releases is our top priority. To keep our releases as fast, safe and predictable as possible, we package and lock in as much of our application and infrastructure code as possible and do not allow changes as we move through delivery stages. Idempotency comes into play for our infrastructure. With everything managed through code, we can detect upcoming changes before they’re made, and only touch resources that require a change. Our release success rate is a testament to this working. The more we put in code and the less we allow for differences between delivery stages, the more our releases have completed successfully.

Which standard or metric defines “quality” in your stack?

When we were first starting, our process was fairly manual. We made sure to package and automate wherever possible, but there were some growing pains. Our delivery stages were not always consistent. From a platform perspective, I would define quality with consistency by means of abstraction for the teams through infrastructure and automation code standards. By providing paved roads — pre-architected, automated paths — we ensure the “right way” is also the “easy way.” This bakes quality and security standards directly into our workflows, allowing teams to ship in a consistent, reliable manner without the overhead of manual steps. Abstraction allows our teams to focus on their priorities and not need to worry about what happens behind the scenes; it just works for them.

Name one recent AI or automation deployment and its impact on the team or business.

It’s honestly hard to pick just one because our team has intentionally built a culture where automation is a constant, collective effort. We protect that through maintaining a continuous feedback loop with our teams. We don’t just build what we think they need; we actively gather pain points to ensure we’re solving the right problems. For example, engineers made it known that our code review process was inefficient, causing frustration. We listened, then designed and built a service to automate identifying and notifying the right reviewers at the right time, turning a friction point into a streamlined workflow. On the business side, we built an automation engine to handle our unique requirements, and now it’s the backbone of every single deployment, allowing us to consistently deliver faster and safer.