Be an Engineering Hero & Meet Your Commitments by Making Changes That Stick

My Operations manager wants us to create deployment blackouts before weekends so she and her team can spend time with their families on Friday evenings instead of chasing down deployment issues.

This sounds fair and my Operations team is depending on me to follow through so I spend a few minutes to think through how to make this change stick before I make a commitment.

Almost every change requires a process modification.

In this case we’re going need to change the timing of our sprints and demos so work can be completed and reviewed in time to deploy on Thursdays.

Use your tools to reinforce change.

I want to make sure blackout window deployments are thought through carefully, so we’ll restrict permissions in our CI system to require a +1 from an engineering manager during blackout windows.

I also want these deployments to be highly visible so we’ll need to configure an engineering wide slack notification.

Communicate the change to stakeholders.

It’s very important that my engineers are not given mixed signals so I’ll need to sit down with my development managers, founders, and product managers to discuss the rationale and get commitments from all of them to support the change.

Converge on Conflict

I’ll create a weekly reminder to look for any conflict over the next few weeks. Is the change too restrictive? Are stakeholders still asking for deployments on Fridays? Did this actually resolve the issues Ops was dealing with?

The next time you decide to make a change, even a simple one, I hope you find this framing helpful to make the change stick.

This post was created with Typeshare