A Tech Asks for a Raise: Which Lever Do You Actually Pull

Why this matters

Once you have decided a raise is warranted, a second, easy-to-skip decision follows immediately: what actually changes in the pay structure. A flat increase to the hourly rate, a move up a certification tier, a richer bonus formula, and a one-time payment are four different mechanisms that all look like "giving a raise" from the outside, and they carry very different long-term costs and signals. Pick the wrong lever and you can permanently commit to a cost you did not mean to lock in, or hand out a bump that evaporates without changing how the tech is actually paid going forward. This is the mechanics decision, separate from how you handle the conversation itself.

Start here: is this a permanent change or a one-time event

Sort the request before you touch any number.

  • If the tech's role, output, or skill level has durably changed (they now handle harder jobs solo, closed out a certification, run a crew), you are looking at a structural change, something that should hold going forward, not a single payment.
  • If the tech had one exceptional stretch, a hard season covered without complaint, a single job that saved the shop real trouble, but the role itself has not changed, a one-time bonus fits better than a permanent rate change. Confusing the two is how a shop ends up with a base rate inflated to reward a single event that will not repeat.

If it is a structural change: which lever fits the cause

If the change is a straightforward increase in skill or reliability within the same role, a flat rate increase to the base hourly or flat-rate figure is the simplest and most transparent lever. It is easy to explain, easy for the tech to verify, and it compounds cleanly into every future raise conversation from a known baseline.

If your shop already runs tiered pay bands gated by certification or demonstrated competency, and the tech has actually cleared the next tier's requirements, move them to that tier rather than negotiating a custom number. This keeps the raise objective, tied to a standard everyone can see, instead of looking like a one-off favor. If the tech has not yet cleared the tier's requirements, a partial raise "in advance" undermines the whole point of having tiers, since it teaches the crew the bands are negotiable rather than earned.

If the added value is tied to revenue or output rather than a skill level (they are closing more work, generating more repeat business, taking on more jobs per week), consider whether the actual fix is restructuring part of their pay toward a bonus or commission component rather than only raising the flat base. A bigger base rewards them for showing up; a bonus component rewards them for the specific output that justified the raise conversation in the first place, and scales with them if the trend continues.

If the tech has taken on supervisory or training responsibility (mentoring newer hires, running point on a crew, being the fallback when you are out), the lever is often a role change with its own pay structure, not a bump within their existing tier. Blending supervisory pay into the existing hourly rate obscures what you are actually paying for and makes the next comparison, "why does the newer supervisor make less than the old senior tech," harder to defend later.

If it is a one-time event: keep it separate from the base

If a single bonus is the right tool, pay it as a clearly labeled one-time amount, not folded into a paycheck as if it were ordinary earnings. This matters for two reasons: it keeps the base rate honest for the next raise conversation, and depending on how it is structured, it may be treated differently for overtime and tax purposes than regular wages, so confirm the correct handling with your payroll provider or an accountant before running it through.

If you are tempted to make the one-time bonus a repeating "informal" thing every year because it worked well once, recognize what is actually happening: you are building an unwritten structural raise without the discipline of an actual tier or rate change. Either formalize it as a real annual bonus with a stated basis, or keep it genuinely one-time and be prepared to say so if the tech expects it to repeat.

Quick reference: matching the cause to the lever

What actually changed Lever to pull
Skill or reliability grew within the same role Flat rate increase to base pay
Cleared a defined certification or competency tier Move to the next tiered pay band
Output or revenue generated increased Add or grow a bonus or commission component
Took on supervisory or training responsibility A distinct role change with its own pay structure
One exceptional stretch, role otherwise unchanged A labeled one-time bonus, not a base rate change

The trap that undoes all of this: inconsistency across the crew

Whichever lever you pull, the fastest way to lose trust with the rest of the team is applying a different lever to the same underlying cause for different people. If one tech's certification earned them a tier move and another tech's identical certification earns them an informal negotiated bump instead, the crew will eventually compare notes, and the inconsistency reads as favoritism even when it was not intended that way. Document which lever you pulled and why, so the next raise conversation, for this tech or any other, starts from a consistent standard.

Before you commit

  1. Confirm whether the change is durable (lever: rate, tier, or role) or a single event (lever: one-time bonus).
  2. Check that the lever you are about to pull matches what actually changed, not just what is easiest to approve in the moment.
  3. Run the new structural cost forward across a full year, not just this pay period, since a permanent rate change compounds every week going forward.
  4. Write down the reasoning so the same cause gets the same lever the next time it comes up, for this tech or anyone else.

References

  • U.S. Department of Labor, Wage and Hour Division, guidance on regular rate calculation and bonus treatment
  • Society for Human Resource Management (SHRM), pay-structure and merit-increase design
  • See related: The Tech Who Wants a Raise: Decision Tree, Tiered Pay Levels by Certification: Decision Tree