Three quote requests in the same week, two running projects that cannot slip and a colleague on holiday: for many engineering departments that is not an exception, that is an ordinary peak. Everyone also knows how the story continues: a few evenings of working late, the wave gets cleared, and two weeks later it is remarkably quiet. Until the next wave.
As long as overtime stays a last resort, there is little to worry about. It becomes a problem when every peak is routinely solved with evening hours: at that point overtime has quietly become part of the capacity plan. This article shows that planning for peak load in engineering is less contradictory than it sounds. Not by predicting the market, but by arranging three things: automating routine work so the peak gets smaller, using quiet weeks to pull work forward, and agreeing up front what gets parked when things truly fill up. Tooling mainly helps with the first one; a toolbox like Thundercad takes the dumb work out of the peak. The other two are agreements, and agreements cost no budget.
One boundary before we start: this is about waves in the workload, not about the one customer who needs something by this afternoon. For that scenario, better read how to move fast on rush orders without sacrificing quality.
Why overtime as a standard costs more than it seems
Overtime feels like the cheapest solution: no vacancy, no contractors, just push through for a bit. The first time, that is even true. It goes wrong once it becomes the pattern. An engineer who keeps drawing while tired makes more careless mistakes, and those mistakes return as rework, right in the middle of the next peak. That is how overtime keeps itself alive.
There is a sneakier effect as well: structural overtime hides the real capacity signal. As long as everything "gets done anyway", nobody sees that the department is accepting more work than it has hours. The slack you want to keep for genuine emergencies has already been spent on ordinary orders.
So start with one simple check: does the workload really drop after the peak, or does "just push through" stretch on for months? In the second case you do not have a peak problem but a capacity problem, and you are better off reading how to get more output from your engineering team without an extra hire.
See the wave coming
Peaks feel like force majeure, but most announce themselves weeks ahead: in outstanding quotes, in orders that sales calls near-certain, in release dates clustering around the same week. That information usually exists already; it just never gets laid next to the capacity of engineering.
It does not need to take more than fifteen minutes a week. Walk the list with work preparation and sales: which projects will demand design hours over the next three weeks, which quotes have a realistic chance, and where does it pile up? A simple traffic light per week is enough: green is plannable, orange is full, red is more work than hours. The goal is not a perfect schedule but three weeks of warning time. Whoever sees the wave coming can deploy the measures from the next sections in time.
Make the peak smaller: automate the routine work
A peak never consists of pure engineering alone. Right at the end of a project, when the pressure is highest, the routine work piles up: exporting drawings to PDF and DXF, getting the BOM to purchasing, updating iProperties, printing drawing packages for the shop floor. Work that adds little but eats hours, at exactly the busiest moment.
That routine work is the part of the peak you can automate away. With Batch Publish, one of the export tools in Thundercad, you publish the drawings of a complete assembly in bulk to PDF, DWG, DXF and STEP, instead of one drawing at a time. With Export BOM the bill of materials lands in your own Excel template without manual copying. Run the numbers with an assumption: if delivering a drawing package takes two hours by hand and twenty minutes automated, every delivery frees up well over an hour and a half. In a peak week with three deliveries, that is more than half a working day flowing back into real engineering.
The nice thing about this approach: automation does not care whether the week is busy or quiet, but the gain feels biggest exactly when the pressure peaks.
Curious how much routine work is hiding inside your peaks? Try the export tools and the rest of the toolbox for a month in your own projects.
Try 30 days freePull work forward: the quiet week is tool time
After the peak comes the lull, and it is often spent on catching a breath and on whatever odd jobs happen to pass by. A waste, because the quiet week is the moment to make the next peak smaller. Not with vague intentions, but with a concrete forward-work list that lies ready the moment things calm down.
That list should contain tasks that pay off during the busy weeks:
- updating drawing and model templates, so new projects start out right;
- extending the library of standard parts and frequently used constructions;
- cleaning up models of recurring products and making them robust for variants;
- setting up export profiles and BOM templates properly, once;
- restoring the agreed folder structure and naming where projects drifted from it.
One afternoon of template work in a quiet week prevents search and repair work in every peak that follows. Forward work is not a luxury but the cheapest capacity there is: you pay with hours that were already there.
Agree the scale-down order in advance
Even with automation and forward work, there is sometimes more work than hours. Then something has to give, and without an agreement the mood of the day decides what that is: often the wrong thing, such as the check before release. So agree a scale-down order during a quiet period: what do we park first, what last, and who calls it.
An order that works well in practice:
- pause forward work and improvement jobs: stepping aside is exactly what they are for;
- postpone internal reporting and administration that does not touch production;
- give sales studies and feasibility questions an agreed later date;
- park revisions without a production date, with an agreed moment to pick them up again.
What never belongs on that list: the check before release and tracking changes in released work. Cutting quality during a peak buys time at loan-shark rates; the errors come back as emergency repair. Make the scale-down mode explicit too: the team lead announces it and also withdraws it. That way everyone knows something is deliberately left waiting, instead of it quietly slipping.
Frequently asked questions
How much overtime is still healthy as a last resort?
A workable rule of thumb: overtime is an exception you agree case by case, with an end that falls within the same week or month. If the same exception returns every month, it is no longer a last resort but disguised capacity, and the conversation about structural solutions belongs on the table.
What if the quiet week never arrives?
Then you are not looking at peaks but at a structural shortage, and no planning trick will fix that. Make it visible with the weekly measurement from this article: how many hours does the work demand, how many hours are truly available. With that overview, the capacity conversation becomes arithmetic instead of a feeling.
Where do I start this week?
Pick one routine task that returns in every peak, such as exporting drawing packages, and automate that one first. The free trial month of Thundercad is a practical way in: download the toolbox and test it on a running project, so you see the effect before the next wave rolls in.