Tis the season for a technical sprint

12/22/2024 - Kyle McVeigh

Go back to all articles

During the last few weeks of December my employer allows the engineers to lead sprint planning and assign themselves work they believe is the top technical priority. This is very common, most serious engineering shops will allow the engineers to have a technical sprint when the business is exceptionally slow. I push hard for this and believe it is a good practice. I'll take the first half of this blog to discuss why I think having a technical sprint is a good idea around the holidays, and what I'm working on professionally for this year's technical sprint.

Why it is OK to have a technical sprint around the holidays

There are two hesitations around having technical sprints, and both of them are valid. First, is this is taking away time from doing product work and second, is the need for a technical sprint a sign that the engineering environment is not healthy. I want to overcome both of these items and tell you why it is nice to have a technical sprint around the holidays:

  1. It is a gift to the engineers. Let me lead with this item because engineering happiness matters. Engineers like working on technical items and they like making their own responsibilities. It is a gift to give a technical sprint at the end of the year and when you have that mindset, the other items on this list seem to matter a little less.
  1. Allows engineers to catch up on work that is not product work. A sizable portion of my coding responsibilities is not product work and instead relates to technical work. Having a technical sprint allows me to catch up on this work and pays off dividends in the future by the elimination of technical debt.
  1. Supports other cross efforts teams, like information securities and compliance. Sometimes there are other departments that have trouble getting on my board in front of product work. It is nice to be able to devote sometime at the end of the year to ensure their technical needs are being met.
  1. Taking time off for technical work is synonymous with lots of other industries. Restaurants have a deep cleaning day, manufacturing has planned shutoff periods, aviation has overhaul days. Software engineering is not unique in their creation, so it only makes sense to have a similar process.
  1. Gives product an opportunity to catch up. Product can use the time during the technical sprint to work on their long term playbook and work on other non-immediate tasks.
  1. The business is taking the time off so their expectations of product output are extremely low. This makes the opportunity cost of technical work extremely low and we should take advantage of that.

What I am working on

To add a bit more substance, I will share what a technical sprint looks like for me. One my chief responsibilities at work is be the technical lead of many of the frontend repos. This year, the technical sprint revolves around some of the below items:

  1. Trying to upgrade Node to 22. For most of my work, I like to stay on the even node releases, so I've been working in Node 20 for quiet sometime. I want to try to move towards 22, which recently became the active version. Also, if a repo can't easily upgrade, I want to know about that and work towards removing that blocker.
  1. Fully deprecating create-react-app in favor of vite. This is more repo specific, but we have a number of react repos that are built using create-react-app, and I'd like to move off of that and towards Vite. Create-react-app is no longer maintained and offers some security risk and Vite is a superior product.
  1. Working towards getting the React repos to 18.3. React 19 just came out and I want to stay within a stones throw of the most recent version, so I'm trying to get everything up to 18.3.
  1. Every frontend repo should have a singular CSS strategy. This is more abstract, but throughout my career I've seen many frontend repos that seem to have multiple CSS strategies or no CSS strategy. The repo may have SCSS, Tailwind, Bootstrap, Material, and Ant Design all installed. When I review Repos, I tend to ask what is the CSS strategy we'd like to move towards, and how can we get there. I realize there are very strong opinions on the different CSS strategies, and I don't want to have the discussion on which is best, but I do want there to be a single strategy per repo.

When the engineers ask for a technical sprint around the new year, give it to them! But don't let them get greedy and have a technical sprint once-a-quarter. For the most part, technical work should be done constantly and not take away from the product, but sometimes it is nice to take some dedicated time and we shouldn't be afraid of that.