Tithe.ly Engineering

As the CTO, I’ve been thinking through a lot of the processes we have here at Tithe.ly. Here is a post I shared with our Engineering team recently.

Cool downs and development cycles aren’t a concept we came up with at Tithe.ly. Shout out to Basecamp’s book Shape Up for helping shape how we do software development.

We are a fast-growing company and building a load of cool software products and features that will ultimately take church technology to a new level. But in the craziness of build mode, we also need to ensure we are building well designed, easy to refactor, and maintain codebases.

Focus + Efficiency + Calm

The goal of our development cycles is to create focus, efficiency, and calm. That’s why we work in cycles of 6 weeks of development with 2 weeks of cool down.

No matter what priorities are, we stick to these cycles to ensure we are delivering fast, quality code.

6 Weeks of Development

We write pitches to get total clarity and then spend 6 weeks focusing on writing, testing, and shipping code.

Notice I included testing and shipping within the 6 weeks? We don’t go over the 6 weeks. That’s why we work in fixed time, variable scope.

Dev teams should be very aware of deadline slippage and adjust the scope to ensure the work is done and shipped within the 6 weeks.

If we’re not shipping within the 6 weeks consistently, it might be because:

• We’re underestimating pitch documents
• We’re losing focus and working on things outside the pitch
• We’re not cutting things out when scope starts to slip
• There’s scope creep that needs to be squashed

Our dev teams are responsible for the outcome of their development cycle.

2 Weeks of cool down

We have a 2 week cool down period after a 6 week development cycle.

This isn’t us sitting on the beach or playing games. It’s here to clean up some messy code, fix bugs, create efficiencies and deal with technical debt. This is a time for the dev team to take ownership of.

Dev teams need to stay on top of technical debt. If you are working on producing great architecture, you will still accrue debt, especially if you’re building fast. If it’s not dealt with, interest builds, and in the coming years, development slows down because there’s a bunch of debt to pay off. We need to continually chip away and refactor debt.

We are in a season where we want to get a lot done. 6 week sprint with 2 week cool down is the golden standard, but it can be flexible. We have a few teams that work outside the golden rule. One of our teams works more Kanban style - one task at a time. Other legacy platforms do 1 week by 1 day cycles to allow for bug smash days once a week.

Dev teams and product managers discuss this and come up with the best solution for their team. The main thing is that ample time for cool down does occur and it shouldn’t be months between them.

Product Manager Role in Development Cycles

Product Managers set the vision for the product. Dev teams execute that vision but also to make sure their product codebase is going to stand the test of time. Product Managers and dev teams serve one another.

Product Managers set the priorities for the 6 weeks. Every once in a while the dev team may need to have their own pitches going through these cycles if they cannot be completed in a cool down. These include things like infrastructure needs, refactoring code and dealing with large amounts of technical debt. These are typically things Product Managers aren’t thinking about. This is a discussion to be had when it comes up and product managers need to listen and strategize with their dev team.

The cool downs are where our dev team can do what’s needed based on the codebase. There is certainly room for Product Managers to make requests for things to be tackled within a cool down, but it should not take up the whole cool down and it should be the exception.

Moving Forward

We are continuing to refine our processes, but they aren’t perfect. We’re growing fast, have a big vision, and building lots of products. It’s crazy exciting!

I tell our engineers to be kind to themselves and most importantly, just communicate if they feel things are not going well. We’re all in this together and we’re here to help each other. This is a marathon, not a sprint. There might be small seasons of “less calm”, which is okay. Let’s not make it the norm.