Why Are There No Technicians in Software Engineering?

In this Article

1. Key Takeaways: Software Has a Role-Shape Problem
2. The Thesis: Software Confuses Status With Responsibility
3. Hardware Makes the Missing Layer Obvious
4. Software Flattened the Ladder and Called It Meritocracy
5. What a Software Technician Role Could Actually Own
6. The Objections Are Predictable, and Mostly Weak
7. Scope: This Is a Role Argument, Not a Universal Org Chart

Key Takeaways: Software Has a Role-Shape Problem

Summary: Software overuses the title “engineer” and under-defines the skilled work beneath it. That creates confusion, not prestige.

• The missing layer is operational, not remedial. A software technician should own repeatable execution, tooling discipline, and delivery reliability.
• This is not a proposal to rename junior developers. It is a proposal to stop pretending every kind of technical work has the same responsibility shape.
• Good software delivery depends on clean ownership boundaries: who designs systems, who operates known workflows, who maintains the release machinery, and who catches drift before it becomes outage bait.

Let’s cut through the ceremonial nonsense. A team can call every technical employee an engineer and still have no idea who owns the release checklist, the broken local setup, the dependency mess, or the CI pipeline that fails every second Tuesday.

Titles do not deploy software. People executing named responsibilities do.

The Thesis: Software Confuses Status With Responsibility

The software industry flattened too many distinct jobs into “software engineer” because the title became a status marker. It signals intelligence, autonomy, and compensation. Fine. It also now hides a lot of work that has nothing to do with engineering judgment in the strict sense.

The practical damage

Ask a team who owns implementation, maintenance, release operations, debugging, environment setup, dependency hygiene, and production babysitting. You will often hear the same answer: “engineering.” That answer sounds efficient until you ask which engineer, with what authority, under what priority model.

Then the fog rolls in.

One group will assume the feature owner cleans up deployment scripts. Another will assume platform owns it. A third will quietly wait for the senior person who understands the ancient build job to return from vacation. Meanwhile, the calendar fills with work that looks like engineering but behaves like operations: repeatable, procedural, fragile when undocumented, and extremely expensive when handled ad hoc.

In one delivery review, I watched a team burn 40 to 60 hours per month on environment drift and dependency resolution instead of system design. Nobody lacked skill. The organization simply refused to name the work.

Note: The problem is not that developers are lazy, precious, or too good for maintenance. The problem is that companies blur different kinds of skilled work, then act surprised when accountability turns into vapor.

There is dignity in execution. There is also risk in pretending execution and design are interchangeable merely because both happen near a repository.

Hardware Makes the Missing Layer Obvious

Electronics does not have this confusion to the same degree because the physical world punishes sloppy role design faster.

A beginner can wire an Arduino to a sensor on a breadboard and make something blink. That prototype is temporary and forgiving. You can move a jumper wire, swap a resistor, or rebuild the whole thing after lunch. Nobody should confuse that with a fabricated PCB, meaning a Printed Circuit Board. A PCB is committed, manufactured, and expensive to revise.

The workflow also has tooling layers. ECAD, or Electronic Computer-Aided Design, is not just “drawing the circuit nicely.” It captures schematics, board layout, constraints, footprints, routing rules, and manufacturing files. When a layout requires trace impedance constraints maintained at 50 ohms, that is not a vibes-based activity. It is disciplined execution inside a known technical system.

Now add fabrication lead times. A PCB fabrication cycle in the range of 6-to-8 weeks changes behavior. Reviews become sharper. Checklists matter. Tool discipline matters. The person preparing manufacturing outputs may not be the same person making the top-level product architecture call, and no sane hardware organization treats that distinction as an insult.

Software lacks the forcing function

Software can patch, redeploy, rollback, and pretend the lesson was learned. That flexibility is useful. It also lets teams avoid naming operational skill until the cost shows up as release anxiety, undocumented tribal knowledge, and a senior engineer spending Friday night nursing a deployment that should have been boring.

The hardware comparison is not perfect. Good. Comparisons do not need to be identical to be useful. They need to expose a hidden assumption.

Software Flattened the Ladder and Called It Meritocracy

Software culture tends to treat every hands-on role as either “engineer” or “not technical.” That binary leaves little room for respected execution specialists.

The incentives are not mysterious. Higher compensation bands attach to engineering titles. Recruiting teams like shiny titles. Startups inflate roles because it is cheaper than maturity. Managers fear that “technician” sounds like a demotion, especially in companies where career ladders worship system design and treat operational excellence as housekeeping.

In practice, one team attempted to rotate senior engineers through a “release manager” sprint role to absorb the operational burden. They abandoned it after just about 3 cycles because feature velocity degraded. The lesson was not that releases do not need ownership. The lesson was that borrowing design capacity for procedural delivery work is a costly way to avoid creating the right role.

That same flattening hurts junior developers from the other direction. When early-career engineers are shoved into architectural decisions before they have enough context, the organization confuses exposure with support. In some teams, average tenure for juniors forced into architectural roles prematurely lands approximately around 12-to-18 months. That is not a rite of passage. It is avoidable churn with a motivational poster stapled to it.

The delivery consequence

Senior engineers get pulled into repetitive operational work. Junior developers get asked to make calls they are not yet equipped to make. Mid-level engineers become the unofficial glue. Everyone insists the org is flat and meritocratic.

It is not flat. It is just poorly drawn.

Quick Tip: If a senior engineer is the only person who can safely run a release, you do not have a release process. You have a dependency with a laptop.

What a Software Technician Role Could Actually Own

A software technician is a skilled operator of known systems, workflows, and tooling. Not a second-class programmer. Not a cheaper architect. Not a place to dump tickets that product engineering does not want to think about.

The role should own work where repeatability, precision, and situational awareness matter more than novel system design.

Plausible ownership areas

• CI/CD maintenance, including brittle job definitions and recurring pipeline failures.
• Dependency upgrades, lockfile hygiene, and compatibility checks.
• Environment reproducibility for local development, staging, and test systems.
• Scripted deployments and release preparation.
• Test fixture upkeep and test data reset routines.
• Log triage before escalation reaches product engineers.
• Release checklists, smoke testing, and rollback rehearsal.
• Data migration rehearsals with documented verification steps.
• Runbook execution during known operational events.

This is concrete work. A technician might execute 30-to-40 step manual release checklists until the team can safely automate more of them. They might triage daily CI pipeline warnings across 15 to 20 microservices and separate noise from real risk. They might keep the staging environment honest enough that “works on my machine” stops being a personality trait.

Treating CI/CD pipeline maintenance as a “growth opportunity” for junior developers often results in fragile, copy-pasted YAML configurations rather than solid infrastructure. The problem is not YAML. The problem is assigning procedural systems work to people without giving them either the mandate or the craft path to do it well.

What the role should not become

Technicians should not receive vague product tickets with unclear acceptance criteria. Nor should they replace engineers who need to make architectural trade-offs. They also should not become a shadow support desk for every developer who refuses to read the runbook.

A technician track works only if the organization respects the work enough to define inputs, outputs, escalation paths, and compensation. Otherwise it becomes another euphemism, and software already has enough of those.

The Objections Are Predictable, and Mostly Weak

The strongest counterargument is simple: software changes too quickly for technician roles to remain useful.

That sounds plausible until you look at the work. Fast-changing environments create more need for repeatable execution, not less. If dependencies shift weekly, environments drift, pipelines mutate, and release procedures change under pressure, then someone needs to keep the operating surface legible.

Speed does not eliminate procedure. It punishes bad procedure.

Will technicians create silos?

They can, if managed lazily. So can platform teams, architecture boards, product managers, and every other organizational invention humans have managed to ruin.

The answer is not to avoid specialization. The answer is to design the interface. Technician work should include documentation updates, escalation rules, pairing windows with engineers, and periodic rotation through new tooling. Engineers should still understand the delivery system. They simply should not be the only people permitted to keep it functioning.

Another objection is handoff bureaucracy. That risk is real. A technician role should not introduce a ticket wall between code and production. It should reduce the number of invisible handoffs already happening in Slack, calendar scraps, and tribal memory.

Onboarding exposes the cost. When undocumented tribal knowledge stretches onboarding from 3 weeks to nearly 4 months, the organization is already paying for a technician function. It is paying through confusion, interruption, and repeated rediscovery.

Note: A role boundary is not bureaucracy by default. A bad boundary is bureaucracy. A good boundary turns recurring chaos into named work.

Scope: This Is a Role Argument, Not a Universal Org Chart

This is not a demand that every company add a formal “software technician” title by Monday.

Small teams may not need the title at all. Engineering teams smaller than 8-to-10 members may only need technician responsibilities made explicit: who owns release checklists, who keeps environments reproducible, who triages pipeline noise, who maintains runbooks, and when that work outranks new feature development.

The argument also does not apply equally across every domain, company size, or regulatory environment. In highly regulated environments, the absence of a dedicated technician role often forces lead architects to spend weeks gathering compliance artifacts instead of designing the next iteration. In a tiny product team shipping a low-risk web app, a formal track may add more ceremony than value.

The compensation trap

Here is the caveat that tends to get ignored: introducing a technician track in organizations that strictly tie compensation bands to system design output will immediately fail, because the role will be financially penalized for doing its actual job.

If the ladder says only architecture counts, do not act surprised when everyone tries to look like an architect. People read incentives more carefully than mission statements.

The fix is not to romanticize technicians. The fix is to respect operational skill enough to name it, pay it, and stop hiding it behind the overloaded word “engineer.” Software delivery needs designers of systems. It also needs disciplined operators of known systems.

Calling both the same thing has not made us more mature. It has just made the mess harder to see.