Code is frozen. What now?

Increased social time

Something that I’d like to explore a lot more on this blog in the future is the immeasurable value of building social time into the work calendar. This is especially important at times of low morale, including code freezes.

Examples of social (in the broadest sense) activities that can even be run in a hybrid or virtual office include:

• A power hour (sometimes called body doubling although this term is appropriated from the ADHD community) where people work together in a space where they can witness each other working.
• A games hour: favourite social games that are easy to teach include Just One, Skribbl and Geoguessr.
• A Monday morning “what have you been watching / reading / been to see” etc. meeting.
• A Friday playlist - people vote on a theme and add songs to a collaborative playlist for everyone to listen to.
• Tiny quiz - have someone set a 15-minute 5-question quiz each week to round off the week.

But the most important thing when talking about social time is that social is not optional for managers. Managers are often the first people to drop out of social activities because they’re “too busy”, but it sends completely the wrong message to the team. If managers are too busy to go to the social, then how can the rest of the team justify attending without seeming like they’re not working as hard as their managers?

Just keep working!

If you’re doing devops well, it should be relatively easy for your engineers to carry on working on their immediate problems even if they’re prevented from deploying them to production.

People will have their own development environments where they’re working on separate branches. You might have a staging environment or (even better) preview builds that allow the work to be demoed and acceptance tested even if it cannot be merged into the main branch until the new year.

But there are some pitfalls to this way of working:

• One is the “long-lived branch” - having work that isn’t merged back for an extended period can result in a branch that has diverged too far to be easily comprehensible by a future engineer in a future debugging session, amongst other concerns.
• Another is that strategic decisions are harder to make when more people are out of the office: maybe letting a mid-level developer run loose on a complex implementation without tech lead oversight will come back to bite you in the future, or maybe guessing what a stakeholder will think will result in a rabbit hole that has to be undone when the stakeholder returns from holiday.

I’m not saying don’t keep working while code is frozen. Often it’s the right decision. But it’s worth thinking about the risks and also what manifestation of those risks might do to morale in your team.

Deep dive demos

If you’re not releasing anything to production, there’s no need to have your fortnightly stakeholder demo, right? No one will show up anyway!

I think this is a slightly flawed way of thinking because it makes two assumptions I would challenge:

• Is the demo only for showing things that have been completed and released already?
• Is showing progress to stakeholders the only reason to have a stakeholder demo?

Of course, I think the answer to both these questions is no. You absolutely can use a demo to show off a piece of work that is still in progress, or even still in the design phase. And demos are as much for your own team’s morale (and teamwork/presentation experience) as they are for the stakeholders you’re presenting to. They’re an opportunity for people to see the real effects of the work they’ve been doing for the last 2 weeks.

One of the things I love to do when a team doesn’t have a lot of tangible outputs to demonstrate is to do a deep dive into something really technical. Maybe it’s time to talk about how a complex ETL process works, or to talk about something like database indexing or an algorithm design.

This sort of talk helps engineers to understand that they are not magicians - that they can tell stories about the most technical aspects of their work. And it helps managers to understand that stakeholders are not idiots: I’ve never seen one of these deep dives that hasn’t included numerous stakeholders who were totally captivated by the actual underlying brilliance of your team’s work! (And with tons of questions!)

Firebreaks and unconferences

These two are related so I’ll recommend them together. This is all about letting your team decide the direction of travel for a short while.

Team members who aren’t in leadership positions aren’t often given the opportunity to suggest the next big piece of work or even the topic of a meeting, but most teams have lots of ideas generated that would otherwise go unheard. (With the right psychological safety and a good retro culture, maybe they will surface regularly, but still not often be prioritised.)

A firebreak is a single iteration - maybe shorter than your usual one but best if it’s a normal length, like two weeks - where everyone works on something different from the critical priorities, for a change of scenery and an opportunity to unlock parts of their brain they might have put on pause.

An unconference is a day (or more) where the topics of conversation are decided on the day, usually through an open pool of suggestions followed by either (a) splitting people off into the conversations they’re most interested in or (b) a vote to decide which conversations to have.

You can also combine these two ideas to make a firebreak where all work is decided by the team. The way I like to do this is:

1. Solicit ideas for work from the team. The ideas should meet the following criteria:
   1. They should not be on the immediate roadmap for the next two iterations.
   2. They should provide some benefit to the organisation, but not necessarily your product. This benefit could be very minor.
   3. There is a brief summary of what outcomes or requirements are expected from the work, so people know what they’re signing up for.
2. Every team member can submit as many ideas as they like (even zero; don’t worry, you’ll get plenty!)
3. Every team member joins 1 (or maybe 2) of these projects based on their own interests. If projects have zero people, they are discarded.
4. People spend the whole firebreak working solely on this project and not on any of their “normal” deliverables.
5. Every project is required to demonstrate where they got to at the end.
6. Then the team leadership can decide if any of the projects might be worth taking forward, but it can be normal to shelve or archive all of them.

Firebreaks have all kinds of benefits. The main one is morale (they are extremely fun - being paid to work on something that’s your own idea is amazing) but they also help the team to surface their ideas and demonstrate what they think are important areas to focus on, as well as giving them all kinds of practice in things like initiative, creativity and presentation.

Developer experience (DX) project

This last one could be a firebreak project but I’m putting it here on its own, because I think every single tech team with a sufficiently complex product can benefit from this one at all times.

As projects grow, the actual experience of working on them in a development environment typically gets more and more crusty. Examples of crust that builds up in dev environments are things like:

• Warning messages that everyone knows to ignore because their cause is known
• Dev environments are hard to spin up from scratch or “reset” to a known good state
• It’s hard to pore over the logs because they’re inconsistent or not connected to each other
• Booting a dev environment requires some arcane knowledge like a .env file copied from another team member or some magic script to adjust local networking
• The README is massively out of date
• The test/seed data is rubbish and doesn’t reflect reality any more

Engineers are resilient and they will usually work around these issues without complaining, but they are issues and they do slow your team down, especially when new people join and need to be set up with the crusty dev infrastructure.

A great activity for two weeks of quiet time is to put everyone on the task of improving the developer experience (often shortened to DX) for their future selves and their future colleagues.

Because everyone is working in the same area, it’s important to keep constant communication open - a daily meeting won’t be enough. This can also help with the social aspects of the dark time!

I might be in a minority here, but I absolutely love the experience of making the creation of a dev environment as painless and enjoyable as possible!