Power of Naming in Tech

~440 Words | ~1.5min Read

Have you ever really considered your job title? Not just accepted it, but thought about what it means and implies? The nouns we use to label ourselves tend to constrain what we think we’re there to do. And right now, with AI automating more mechanical work, those mental constraints matter more than ever.

Consider the difference between “software developer” and “software engineer.” My friend Claudio Lassala called my attention to it. When people say developers will cease to exist, developers of what? Software developers or solution developers? A programmer implies keyboard work under threat from AI. An engineer implies systemic thinking, client discussion, design work, trade-offs, and planning. Same person, different scope of responsibility.

This isn’t new. Computer operators used to be a job title. So did telephone operators. Those roles didn’t disappear because the skills were ‘worth less’. They were absorbed into everyone’s job. Everyone in the office needed to operate computers. And we figured out how to automate switch boards. But here’s the thing: The mechanical parts got automated. The human skills remained valuable. What if the telephone operator saw themselves as “social connectors”? Could he translate those skills to crisis negotiation or 911 dispatch? Or the Computer Operator, who realized that everyone needed to know what she knew?

The question isn’t whether your current job title will survive AI. The question is whether your job title captures the most valuable parts of what you actually do. In [[To Sell is Human]], Daniel Pink describes an “Invisible Pitch”. It’s the one you’re making in every interaction. Just ask people who know you best to describe you or your work in three words. Their answers reveal how you’re actually showing up. It won’t matter what your business card says. It’s a useful test to figure out how you’re carrying yourself. It will reveal how you’re acting even if you think your verbs are something else.

Software engineering requires asking questions that branch beyond “does the software work?” Is it economical? Is it secure? Is it maintainable? Can the team support it? These aren’t new concerns. They’ve always been there. But if you called yourself a developer and think your job is writing code, you’ll miss them. If you call yourself an engineer, it changes how you think. If you think your job is solving problems through systems, you’ll see systems everywhere.

So what name do you give your work? Does it capture what actually makes you valuable? Or does it constrain you to the parts AI can already do?