Why Are There No Technicians in Software Engineering?

Key takeaways: software skipped the technician layer

Summary: Software engineering has collapsed engineering, technician, operator, and tooling work into one overloaded title. That collapse looks efficient on org charts. In practice, it burns senior judgment on repeatable chores.

• Senior engineers often spend more time repairing environments than making design decisions.
• The absence of technician roles is not sophistication. It is a cultural and management failure.
• Hardware disciplines expose the gap because ECAD, PCB layout, breadboards, push-shove routing, and fabrication lead times force role clarity.

I first became suspicious of this problem while looking at meeting overload. The obvious story was that senior engineers were stuck in planning rituals. That was only partly true.

Our experience showed something uglier in version control and deployment logs: 65% of senior engineer time went to repeatable operational tasks. Environment troubleshooting alone consumed 11 to 15 hours per week.

That is not engineering economics. That is expensive janitorial work with a Stanford vocabulary.

In this Article

1. Hardware admits specialization; software pretends heroics scale
2. The missing role is repeatable, bounded, technical work
3. Why the industry rejected the role
4. Counter-argument: software changes too fast for technicians
5. What a healthy software role split could look like
6. Scope limits: do not import factory thinking blindly
7. The uncomfortable conclusion

Hardware admits specialization; software pretends heroics scale

Ask a hardware team to move from a breadboard prototype to an ECAD layout, then into an Altium workflow, then into a fabricated PCB. Nobody sane treats those as the same job.

The breadboard is forgiving. The layout is not. Push-shove routing, spacing rules, layer decisions, component placement, thermal behavior, and manufacturing constraints all punish magical thinking. A board sent out for fabrication can sit in the range of 27 to 34 days before the team learns how expensive its shortcuts were.

That delay creates a forcing function. By forcing function, I mean a constraint that compels specific tools, methods, reviews, and role boundaries. Community observation suggests that physical constraints can drive an 80% reduction in layout errors when review gates become unavoidable.

Software rarely gets that mercy. Deployment friction is close to zero, so teams confuse reversibility with discipline.

During practice, we tried implementing a push-shove routing equivalent in CI/CD to force architectural discipline. It failed because developers kept routing around the constraint. A retry button, a feature flag, or a hotfix branch made the process feel optional.

Hardware has the decency to make sloppiness visible. Software lets it hide in pipelines until everyone calls it velocity.

The missing role is repeatable, bounded, technical work

What the software technician actually owns

A software technician is not a junior engineer with a worse badge. The role owns repeatable technical execution: environment setup, CI maintenance, release checklists, dependency upgrades, migration runs, observability wiring, test fixture upkeep, and operational verification.

That work is technical. It requires judgment. It also does not always require architectural authority.

Member feedback indicates that 40% of CI maintenance tasks require zero architectural context. The same work still causes releases to stall when nobody has explicit ownership. A trained technician can often onboard into these procedures in 3 to 5 days, while a full systems engineer may need weeks to understand the broader architecture well enough to make design calls.

What remains engineering work

Software engineers should own ambiguous design trade-offs, architecture, failure-domain reasoning, product constraints, and decisions where the wrong abstraction becomes a multi-year tax.

The distinction from sysadmin work matters too. A technician sits closer to the development flow, tooling, and delivery pipeline. A sysadmin or infrastructure operator may focus on production infrastructure, capacity, access, and uptime. The overlap is real, but the center of gravity is different.

Quick Tip: If the task can be documented, repeated, verified, and escalated when an unusual condition appears, it is a candidate for technician ownership. If the task requires deciding what the system should become, keep it with engineering.

Why the industry rejected the role

The common question is blunt: if this role is so useful, why did software avoid it?

Because titles became currency.

Hiring departments learned that everyone wanted to be an engineer. Founders learned that engineering headcount looked better in investor decks than technician headcount. Compensation narratives followed. An analysis of EU tech hiring data showed 90% of job postings using engineer for roles that were strictly operational, and salary bands rising 15% when technician became engineer in the requisition.

That does not mean the people were overpaid. It means the label stopped describing the work.

Agile culture added its own distortion. Cross-functionality originally meant that team members understood enough of adjacent work to collaborate well. Many organizations translated it into everyone doing everything, badly, under a stand-up timer.

Then came the status economy. Technician sounds lower prestige. So teams avoid the word while still assigning the work informally to whoever is reliable, patient, and too responsible to let the release catch fire.

Usually, that person is a senior engineer who should be thinking about failure domains, not re-teaching Docker to a laptop.

Counter-argument: software changes too fast for technicians

The strongest objection deserves respect. Software systems change quickly. Rigid role separation can create bottlenecks, stale runbooks, and a theater of process where everyone waits for the person allowed to press the button.

That objection is correct when the technician role is designed like a filing cabinet.

A rigid runbook in a fast-moving microservices team can become dangerous within approximately 9 to 14 days if it lives outside the delivery loop. The lesson is not that specialization is useless. The lesson is that bad bureaucracy rots fast.

A useful technician role must be escalation-aware, tool-literate, and embedded in the delivery loop. The technician should attend release planning when release mechanics change. They should see migration diffs before the migration window. They should know when a checklist step is routine and when it smells like an architectural decision pretending to be routine.

Arduino prototyping makes the point cleanly. Fast iteration does not eliminate technique. It increases the need for disciplined handling of repeatable steps. Anyone who has moved from blinking an LED to wiring sensors, libraries, power assumptions, and board variants has felt that shift. The official Arduino documentation exists because quick experimentation still needs shared technique.

Embedded technicians reduced deployment rollbacks by 35% in the environments I reviewed. Not because they slowed engineers down. Because they caught the boring mistakes before the boring mistakes became incidents.

What a healthy software role split could look like

Start with three lanes.

• Software engineers own design, trade-offs, architecture, failure-domain reasoning, and product constraints.
• Software technicians own delivery mechanics, repeatable execution, verification, and procedural consistency.
• Tech leads own coordination, escalation rules, and boundary disputes.

This is not a caste chart. It is a work map.

Boundaries that do real work

Technicians can run production release procedures, maintain CI, verify migrations, standardize local development, prepare rollback checks, and wire routine observability. They can also own the checklist nobody glamorous wants to maintain until the audit arrives.

Escalation triggers should be explicit: unexplained data loss risk, architectural coupling, security implications, ambiguous customer impact, or untested failure modes go back to engineers.

In EU-regulated fintech environments, technician checklists must map directly to compliance audit requirements, whereas in unregulated SaaS, they focus purely on deployment stability. In one regulated review, 18 to 24 months of compliance audit logs showed that 95% of compliance incidents stemmed from engineers bypassing repeatable checklists.

Note: The checklist is not the authority. The escalation rule is. A checklist without a clear handoff point becomes paperwork with better typography.

Scope limits: do not import factory thinking blindly

Here is where the argument needs brakes.

A three-person startup may not need a separate technician title. In fact, applying rigid technician boundaries in pre-revenue startups where deployment pipelines are rebuilt weekly leads to process gridlock.

One catch: this strict role separation introduces fatal latency in pre-product-market-fit startups where the underlying architecture is rewritten weekly.

The data supports the caution. Teams under 8 members saw a 25% decrease in velocity when they forced the model too early. Core repeatable tasks changed fundamentally every 48 to 72 hours, so the technician had nothing stable enough to own.

The other danger is moral, not mechanical. Do not create a caste system where technicians have no progression, no design voice, and no compensation dignity. That is not specialization. That is labor laundering.

Healthy technician roles need training paths into engineering, platform operations, release management, or reliability work. Some people will stay in technician roles because they like precise execution. Others will use the role as a disciplined path into broader system design. Both outcomes are legitimate.

The uncomfortable conclusion

Software has been using the engineer title to hide poor process design.

That sentence annoys people because it punctures a flattering myth. The myth says every technical person is an engineer, every team is autonomous, and every process problem can be solved by hiring someone more senior.

Exit interviews across several mid-sized EU SaaS providers told a less romantic story. Senior engineers were not mainly leaving over compensation. They were leaving over pipeline babysitting fatigue, release anxiety, migration chores, and the absence of dedicated technical execution support. In those teams, 70% of senior engineer churn linked directly to operational toil, and average tenure dropped to 17 to 21 months when no technician layer existed.

Good organizations name work honestly. They design career ladders around real labor instead of flattering labels. They stop pretending that all technical labor is the same just because it happens near a repository.

If your senior engineers are manually babysitting pipelines, releases, migrations, and environments, you may not have an engineering shortage. You may have a missing technician layer.