Morale waves | Fish Percolator

Why does "we just have to write the tests" or paying down technical debt always take so long?

Have you ever noticed this? Your engineering team go from being really enthusiastic — churning out features at a rate of knots — to being sluggish and bored, almost overnight?

You might be experiencing what I call a morale wave.

When engineers are happiest

Engineers want to be creating. Seeing our keystrokes translated into actual practical results is the thrill of the job.

There is no happier time than when we’re writing code that works. Seeing new features or bugfixes happen as a consequence of our work? Magical.

Part of the reason this part of the job is so morale-boosting is that it’s what we’re celebrated for. Doing a demo of new stuff. Non-engineers are always ready to cheer for this, because they can see it too.

But engineering is about way more than implementing the next feature. It’s about technical designs. It’s about automated tests. It’s about database optimization. It’s about documentation. It’s about observability, and it’s about keeping technical debt paid off.

It’s hard to show these other things, and yet they’re considerably more than half of the job. So when we have to do them, it feels like we’re not accomplishing anything and hardly anyone celebrates them.

Frankly, for most of us, if there was a way for us to be shipping new features all the time without all that other stuff we’d be over the moon.

Why morale waves happen

Morale waves happen for two main reasons, in my experience.

The first is balance. If an engineer’s average week involves, say, 40% delivering new exciting demoable stuff, and 60% all the other important parts of the job, then maybe morale will stay at the middling point constantly.

But if engineers have one week of doing amazing, exciting stuff, and then two weeks of the less cool stuff that no one outside the engineering team celebrates, it’s going to be hard to maintain morale. The waves are even worse if they’re bigger. If it’s a month of fun followed by two months of boredom… that’s a long time to not be doing anything fun at work!

When there are no big features needing implementing, it’s easy to think you can set your engineering team off on some longstanding tasks like observability or code coverage or paying down technical debt. But this will wear thin after a while — it’ll be very hard to keep up morale if the only thing your engineers are working on for several weeks in a row is something they can’t really show off in a demo.

The second reason is fun, or the lack of it. When you’re working on the implementation part of a new feature, the excitement is innate — every engineer enjoys creating. But sometimes the other things can be the exact opposite of fun. No one cares about them except your tech lead, they take a really long time (a self-fulfilling prophecy where morale is concerned!) and you know they need doing but you just really want to be working on the next thing.

Morale coming in waves isn’t great for anyone. It’s not great for the engineers who resent coming to work during the low times, and probably have poor productivity too, and it’s not great for anyone planning or doing risk management or workforce planning, because work slows down during low periods and becomes hard to estimate properly.

What you can do about it

I’ve found that to avoid morale waves, there are quite a few things you can do when deciding on how and in what order work will be done. Ideally, you’d do all of these things, but even just adding a few into the mix will likely make a big difference:

Plan work in the tiniest cycles

Perhaps the most important thing to do is ensure that work is planned in tiny cycles. I don’t mean two-week sprints — two weeks is an eternity! — I mean each individual work package, each story within your sprint, should include all the “exciting” and all the “boring” in the same deliverable.

If you change your definition of done to include testing, to include devops/productionising, to include observability, to include refactoring… if people do these as part of implementation, they won’t seem nearly so tedious. They might even become commonplace and start to feel like part of the “exciting” bit of the job.

The worst thing you can do is let people work super-fast towards the demoable part of the implementation and then ask them to do all these other things after that’s done. Engineers, especially less experienced ones, will always argue for this because if you front-load the fun, you get to “excited stakeholder” quicker, and you maybe can engage in some wishful thinking that the other stuff will just go away.

Take an interest in NFRs

I know I bang on about NFRs a lot but they’re a huge part of the job of an engineer. They can be really enjoyable, but they’re not going to be that if the engineers are the only part of the team that are even talking about them or interested in them.

Watch my video maybe or talk to your engineering team about why these things are important and learn to get excited about them too. Your team will thank you the first time you show up to a meeting excited to hear about how they’re planning to add instrumentation to some API call to a third party service.

And make the NFRs part of your demo cycle. Make low-level algorithms part of your demo cycle. Make devops and deployment part of your demo cycle. I’ve lost count of the number of times engineers have said to me “oh but that’s operational or backend and no one will want to see that”. But then when they do demo it, the audience is captivated. Seeing how the sausage is made is extremely exciting, even to non-technical stakeholders, because they can finally feel part of a world they aren’t usually “allowed” to touch.

Make it fun

Sometimes you’ve just got to have one of those sprints which are about refactoring, test coverage or something like cleaning up log messages.

These aren’t fun tasks by themselves, but they can be made fun:

Maybe turn it into a group exercise where the log messages are divided up and everyone has to announce whenever they’ve cleaned one up.
Use something like Datadog to demonstrate the impact of the changes and have daily calls where you celebrate the improvements.
Have people narrate their work - at the end of the day people share what they’ve done, in as plain English as they can.
Use frameworks that are enjoyable and get people excited. Who doesn’t love to see an actual animated playback of a browser test and where it failed in Playwright?

Make sure there is work for engineers during design phases

When a team is being strategic and doing design and planning for the future, it’s easy for the engineering team to feel left behind. “Oh, get on with paying off all that technical debt,” you’ll say.

That strategy can only work for probably a maximum of 2 sprints or 4 weeks. After that, you’re going to have to give engineers something exciting to do or they’re going to quit on you.

Here are two ideas:

Just make work for the engineers. Even if you’re not sure of the next specific direction, you’ll know your overall direction or your North Star. There will be all kinds of foundational work there - maybe there are components or infrastructure that you know needs building, you just don’t have a use for it yet. Give it to the team anyway - where’s the harm of getting ahead of yourselves? (Just be careful of “bit rot” - you don’t want a component that’s not being used at all because it will gradually become incompatible with your main system, so sometimes you have to create a fun side project to incorporate that component.)
Shift your engineers left; by which I mean: bring them into the design discussions. Bring them into your strategic leadership meetings. Rarely do strategic conversations cover topics that are so sensitive that lower-level team members can’t hear them. And I bet even the first time you invite them to one of these meetings, one of them will have a genius insight you completely missed.

Got morale issues in your team?

It’s time for me to blow my own trumpet a bit. Morale is kind of a special skill of mine. I’ve been into numerous deflated and demoralised teams and made some (often very tiny) nudges that have got them excited and moving at pace again.

If your team is demoralised and you want a little help getting them excited about the job again, let’s talk! Maybe I can even give you something in that first, free call that makes a big difference!

Fish Percolator is a technical leadership consultancy based in Yorkshire.

If your team is not running as smoothly as you'd like, you have long gaps between releases or bugs in production, or your people are not excited about coming to work every day... we can help!