Going from one deploy a quarter to once a week at Reciprocity

The jump from deploying every three months or so to deploying once a week is huge. At Atlassian we had it where we were deploying service side software every three months and then we started deploying to cloud eventually every week, and that was seen as just crazy, crazy speed.

It was similar when I started as a chief architect at a company called Reciprocity, where they were deploying every quarter or so, every three months. And when I got there, I saw how slow they were deploying and I said, well, if we want to be a top tier company that's able to deliver top tier value, then we need to deploy more frequently. And so, I put them on a process of taking the releases every three months to releasing event eventually every week, and actually sometimes every day depending on the size of the change. That whole process took, oh, I don't know, probably six months or eight months or so.

Probably the big thing that I learned out of that when you're going to that level of change is that it's not really a technical problem. Yes, there's parts of the deployment that need to be automated that previously weren't, you need to simplify things, you need to improve your monitoring so that you know when things are going wrong because now you're changing things more frequently. You need to train more people on how to do deployments, you can't just have that one person that always does it. There's technical aspects to this, but a lot of what's happening is actually cultural and communication based.

For example, our sales team was used to dealing with change once every three months and now potentially they're having changes every week. That was huge to them because they were used to producing the script based on the capabilities and then having to revise it every three months, now they needed to look at revise that script potentially every week. So, that was very disruptive. The marketing team was used to marketing features every three months, now they need to think about marketing quicker, marketing smaller instead of trying to do big splashes every three months. Project management or product management, where they're trying to create future timelines, they were used to thinking about what are we delivering on this one release in three months and the next release in the next three months. But now releasing every week they had to think what's coming out this week and next week and next week, how do they take big projects and break them down? So they had to really rethink how they did things.

That was the big lesson I learned when you're going from releasing every three months to every week is how you have to rethink so much of the company, not just the technical part, not even just the engineering parts, but all the processes. Many of the processes inside a company, particularly at a software company that are just not used to releasing that quickly.