A Leading Cause of Engineering Burnout, and How to Outsmart it
Work, like life, is cyclical. The four seasons (2 if you’re in Seattle, 1 if you’re in California, 4 per day if you’re in Colorado) fade and slide into one another year after year. We have periods of intense creation, periods of celebration, periods of getting things in order, and periods of rest. These may not follow a 12 month calendar, but the pattern’s there nonetheless.
We run into trouble when this natural rhythm gets interrupted. You’re a few weeks away from tooling release or board fab, and the client realizes they have a budget problem and you need to go back to the drawing board on the architecture. Absolutely you need to use your creative problem solving skills to come up with a path forward. AND. If you’re not careful, you’ve just walked into a total burnout trap.
You see, tooling release (or board release, or code deployment) is a chaotic and magical moment in the engineering process. It’s when you say “this is good enough, based on our best judgement and constraints, to really draw a line in the sand.”
And it’s a bear to get there.
Long days of coding, testing, prototyping, and debugging. This effort is justified because you know that on the other side of that release you get some time to celebrate, to breathe, to relax and recharge. Or at least, you’re expecting to get this time. It’s in the program’s best interest for you to get it.
I like to think of the process as a sine wave. At times you’re giving it your all (the upslope) on your way to a big release (the crest). At times you’re cleaning up documentation and getting your thoughts straight (the downslope) on your way to a period of rest while tooling is being cut (the trough). You’re moving towards the crest, or you’re moving towards the trough. There’s nowhere else to be.
Burnout happens when you’re on the upslope and the crest gets moved, or sometimes it gets removed altogether — the special case of a cancelled project.
You’re close to finishing a design and you get a requirements change. You find out the resin you shot the Alpha parts in doesn’t meet the hazardous materials requirement. You get word that the microcontroller you spec’d is going EOL before production ramp. Or if you’re savvy — the microcontroller you spec’d isn’t in production yet and the chip manufacturer has fallen behind on providing samples for you to prototype with.
These are all standard and normal parts of the engineering journey, I’m sure you’ve been there before. Engineers thrive on this opportunity to turn challenges into solutions. Scary moments into wins. But we’re still human (I swear), and we still operate in cycles. The sine wave doesn’t need to be symmetric, it doesn’t need to have a consistent period. It just needs to be completed.
If you’re a project manager reading this, 1) thank you! and 2) you’ll thank yourself for giving your team a chance to collect, process, celebrate, and move on before you start them on the next cycle or project. Otherwise they’ll carry the incompleteness of this project or design forward to the next one.
So if the key thing is to allow the cycle to finish, what does that look like? And how do I do that if I don’t have a bunch of time to finish something that is outdated?
You can start by asking yourself “what’s the smallest action I can take to feel complete in this cycle?”
Completing the cycle might be doing a code review, even though you’re not launching. You document feedback and push the code and notes to GIT as is without implementing the changes.
Or hosting a CAD review and checking your files into the vault with detailed revision notes that include the feedback, knowing that this design isn’t getting made. It might be putting all the prototypes in a clearly inventoried box and putting the box in storage.
Or you can do something more symbolic, like “launching” a (biodegradable) paper boat down a stream. Play around with different ideas and see what sticks.
As a project manager, it might be taking each person on the team out to (virtual) lunch and listening to them talk through their greatest wins and biggest frustrations. Sometimes we just need to verbally process the frustration of change in order to finish the cycle.
As you get better at noticing when a change that’ll upset the cycle is about to happen, you can “make a smaller circle” out of this process of completing. In the past you may have felt frustrated and dejected for a few weeks or months after the unexpected end of a long program. But you now know that if you take the afternoon off to walk and process, and spend the next day writing closing notes and tying up loose ends, you'll be ready to get started on the next thing 100% come Monday morning.
There’s not really a limit to how fast you can complete the cycle. There are cycles in my life that used to take me six months, that I can now complete in an afternoon.
Does this only apply during exceptions or big changes to the program? Absolutely not. An ounce of prevention is worth a pound of cure. You can be mindful of this dynamic during the regular ups and downs of the engineering process, and make sure to take time to celebrate, acknowledge, and complete every cycle.
If you’ve recently had a major change to your program, I’d love to hear what you’re going to do to complete the cycle in the comments below!