The Title Trap asks: what are we actually paying for? This essay answers it by defining three substantively different practices in knowledge work. The problem is not that people use “engineer,” “technologist,” and “technician” interchangeably—it is that we have made it impossible to call anyone anything else.

I. The Profession That Lost Its Names

In medicine, the distinction is clear and enforced by law. An MD and a Nurse Practitioner are both valuable. Both are trained professionals. They are not interchangeable. They have different training, different scopes of practice, different liabilities. The system is designed so you cannot confuse them.

In software and data, this distinction has evaporated. Everyone is a “Data Scientist.” Everyone is a “Data Engineer.” Everyone is a “Software Engineer.” The terms have become pure noise—a title rack where anyone can grab whatever sounds most impressive.

The result: companies hire a “Data Engineer” to do data technician work: loading CSVs, writing ETL pipelines from a spec. They pay the premium for someone who can design data systems, but assign them to execution. The person either wastes their capacity or leaves. Or worse: they accept the title and the work, and slowly stop trying to solve novel problems. They become a technician collecting a technologist’s paycheck, and everyone pretends this is normal.

The honest version of most “software engineering” positions: they are programming work. Programming is technician work—implementing from specification, solving defined problems with known tools. It is valuable work. It is not engineering. But there is shame in saying “I am a programmer” or “I am a technician,” so we call it “software engineering” and pretend the distinction does not matter.

II. The Technician

A technician is someone who applies known solutions to defined problems. They work from specifications, blueprints, or standards. Their job is execution with precision. They are accountable for doing the thing correctly, not for deciding what the thing should be.

Technicians follow the manual. They implement the spec. They execute the procedure. The problem is already scoped. The solution already exists. They optimize within that boundary. Their accountability is quality and correctness of execution—speed and reliability within scope.

Think of a surgeon following a protocol, or a network administrator deploying a standard configuration, or a developer implementing a detailed ticket. Technicians are invaluable. Modern civilization runs on technicians. A bridge does not collapse because there are too many technicians on the build; it collapses because there were not enough, or the technicians were given a bad spec.

Most working programmers are technicians. Most working data people are technicians. Most working people in technology are technicians. This is not a failure. It is what the work is. If you are implementing tickets from a specification, if you are writing code that solves a defined problem, if you are running scripts to extract, transform, and load data, if you are following established patterns and best practices to build what someone else designed—you are a technician. That is honest. It is necessary.

III. The Technologist

A technologist is someone who adapts, integrates, or invents solutions to novel problems. They work from principles and creativity. Their job is problem-solving under uncertainty. They are accountable for finding the path when the path is not obvious.

Technologists ask “why this way?” They propose alternatives. They integrate disparate systems. They invent new approaches when the textbook does not cover it. The problem is clear, but the solution is not. They define the how when the what is known. Their accountability is choosing the right approach, evaluating trade-offs, making solutions work in new contexts.

Think of an architect designing a bridge for a challenging site, or a developer designing a system that does not yet exist, or a researcher engineering a new approach to an old problem. Technologists are the connective tissue. They take existing knowledge and make it work in new contexts where the old answers no longer apply.

IV. The Engineer

An engineer is someone who designs systems with ethical, legal, or existential accountability. They work from first principles and responsibility. Their job is ensuring that what is built will not fail in ways that matter. They are accountable for the long-term viability of what they create.

Engineers ensure safety. They prevent systemic failure. They take responsibility for the whole system, not just one part. They must consider not just “does this work?” but “will this fail? What happens when it does? Who pays the cost?” Their accountability is the integrity of the system, the safety of users, the sustainability of what they build.

A civil engineer signs blueprints knowing liability follows. A surgeon-researcher develops a new technique and must test it safely. A software architect designs infrastructure that, if it fails, breaks the entire business. These people carry different weight.

V. The Hierarchy is Backwards

The tech industry treats this as a ladder: Technician → Technologist → Engineer. It is not a ladder. It is a shift in kind of work, not a progression in seniority or intelligence.

Some of the most valuable people in the world are technicians. A great surgeon is a technician executing a protocol with such precision that the patient lives. A great network engineer applying established patterns is a technician, and without that precision, the internet does not work. The confusion comes from mixing three different axes: accountability level, seniority, and pay. You can have a junior technologist and a senior technician. You can have a well-paid technician and a struggling engineer. The three are independent.

A company hiring a “Senior Technologist” to do technician work is not saving money—it is wasting the person’s expensive problem-solving capacity on execution. A company that needs an engineer but hires a technologist is not saving money—it is building a system that will fail in ways that matter, and the cleanup cost will be ruinous.

The honest version: hire the right type of practitioner for the problem you have, and pay them for the kind of accountability they carry, not for the title you are afraid to explain.

VI. The Honest Reflection

The person calling themselves a “Software Engineer” while writing code to spec is being honest about their value to the company. They are not being honest about their role. They are a programmer. Calling it “engineering” does not change the work; it just inflates the title to match the salary band.

This is not shameful. Shameful is pretending the distinction does not exist. A well-paid, skilled technician is the backbone of every functioning system. The problem is not that people are technicians. The problem is that we lie about it, then act surprised when a technician burns out because they accepted the title of “engineer” and the implicit promise that they would solve novel problems—and instead they implement tickets for their entire career.

Call yourself what you are. If you are a programmer, say so. If you are a technician, say so. If you sometimes solve novel problems, you are also a technologist. If you design systems with existential accountability, you are an engineer. Most people are in the first category. That is fine. It is necessary. But it requires honesty.

In some countries, the joke is explicit. In Colombia, everyone is a “doctor”—the title has lost all meaning. When the inflation becomes absurd enough, people just call everyone an “HP” (or in English, an “SOB”)—a cynical shorthand that says: we are all just people claiming importance. The software industry is approaching this saturation point. Soon, everyone will be a “Senior Principal Staff Engineer,” and the distinction will have collapsed entirely. The word will mean nothing because we refused to distinguish what things actually are. At that point, the only honest language left is the cynical one.

And yet: as LLMs begin generating repositories of a hundred thousand lines in an afternoon, a new problem emerges. No one understands the whole thing. No one can. It is too large. Someone has to navigate it, debug it, find the rot, steer it when it breaks. The technician cannot—the spec is gone, buried under layers of generated code that no one wrote on purpose. The technologist can patch problems but cannot see the forest. So what do we call the person who comes in when the system is failing, who reads code they did not write, who speaks both the machine’s language and the business’s intent, and fixes what no one else can diagnose? Our sidekick? Our translator? Our search-and-rescue team?

The naming will matter soon.

Further reading