A model I return to a lot when talking about engineering processes is Push and Pull. Often when we design a new process or system we struggle to get buy-in. That lack of buy-in can often be traced to having forgotten the Push, the Pull, or both.

We’re all familiar with processes like “write a weekly status update” that start strong and eventually fade out to low participation, engineers automating their updates, and gibberish. When you ask people why participation faded you hear the same thing over and over, “It didn’t feel like anyone was reading it”. In this scenario, we’ve Pushed. We’ve told people they must do something, on a schedule, in a certain format. But we haven’t Pulled, we haven’t created a sense that the work is valuable, that there is a need it is filling. A low grade Pull is something like a practice of reading status updates at the weekly meeting. (It doesn’t create much Pull, unless there is regular meaningful discussion, but it’s something)

Most teams have Push and Pull locked in for submitting PRs. Push: this is how we submit PRs, here is a template for doing it, this is our expectation of how engineering happens. Pull: you can’t make any forward progress on getting your work deployed unless you do it. Interestingly most teams only have the Push figured out for reviewing PRs. You should review PRs, you should review them in a timely fashion. You should, you should, you should. That’s all Push. Any wonder that so many teams struggling with PR dwell time?

If we want a culture of dashboards and data we can make data part of the definition of done by asking people for that data at key points. You can’t launch a feature until you can tell us how you’re going to measure success. You need to be able to tell us about usage for this feature at regular review. We expect you to be the first person to know if something radically changes with the features you’ve built. That’s Pull. We have a standard approach to dashboards including the tools and how to configure them, we have this regularly scheduled training on how to create a good dashboard, etc, that’s the Push.

Sometimes you see systems working where there isn’t an explicit Push or Pull. Usually this means we’ve created an inherent value out of one of them. It’s just part of being a good engineer at our company that you: review PRs, or make dashboards, or write status updates. There’s still a Push and Pull there, it’s just a moral and implicit one. Like any other time you’re trying to create or change a cultural value of your team it can both be highly effective and often slow and challenging.

So if you’re thinking about rolling out a new system, process, tool, etc. I’d strongly suggest that you think about both what the Push and what the Pull is.