Recently, I participated in Healthify’s lightning talk series. I chose to speak on one of my pet topics: the concept of engineering versus development. Given that it was still a talk I was presenting, it of course had a goofy title and bright-pink color scheme:

As the bright pink slides go on to clarify, I’m Emily; my title is “sales engineer”; I have never been a salesperson; and I don’t write production code. (The code I do write is instead used for the very noble goal of making Python play improv games, or generating Lana del Rey themed lorem ipsum.)

So: why is sales engineer an appropriate job title for someone who has neither a quota nor access to our production servers?

To answer that, it’s useful to clarify what I do do all day. With the giant caveat that of course my day would look very different at a different company—Salesforce’s sales engineers have very different lives than Healthify’s and both of them are different than Atlassian’s—I describe the core of my job function as being a technical point of contact in the pre-sales process. I’m a voice of technical authority on demo calls, there to answer questions about our application architecture and security practices tossed out by IT teams evaluating the tool. Where my colleagues on the sales team are there to help argue that our product solves a client-identified need, I’m there to let the IT team know that we’re not going to stick their patient data in a public S3 bucket.

I do a fair amount of work outside of client meetings, as well. I answer vendor security surveys (specifying the ways in which we’re not going to put patient data in a public S3 bucket), help our sales team brainstorm integration pathways that they can propose to clients, surface technical requests from our client base to our integration and product teams, and generally help connect our sales, product support, account management, and integration teams through the pre-sales and post-sales client lifecycle.

I write copy for one-pagers (the marketing team makes them look good) and edit the internal documentation written by our developers—I’m a rubber duck who asks questions back. Recently, I made sure all the request parameters in our API documentation were appropriately formatted as code (the kind of tedious reduction of entropy that I live for).

People who do that subset of tasks go by lots of different titles, because at the end of the day titles are mostly a signaling mechanism. This goes double when you’re in a client-facing role. My title has “engineer” in it in part so that IT teams respect me. But I could have been a solutions engineer, a solutions architect, a technical account manager (my last title), or a technical sales exec.

Engineering (IM heavily-caveated O) is a systems-driven approach to solving problems; in that sense, I am an engineer who focuses on my company’s sales process. I apply a systems-based approach to talking about integration design with clients and talking about our sales process with our internal teams. Where the individual sales executives are there to think about the sales process as a pipeline of individual clients, I’m there to talk about recurring patterns and systems that interact with each other. I apply a particular mental tool (an engineering framework) to a particular knowledge domain (the sales pipeline). Much like how a software engineer will write tools to help them when they find themselves doing the same task more than once, I put together documentation and training when I find myself having the same client conversation multiple times.

At my company, like many others, people often use “engineer” as shorthand for “software developer.” Software developers are engineers in the sense that they use systems-driven thinking to solve problems. In their case, the problems they’re solving are around code and how it is structured, and they use writing (and hopefully refactoring) of code as their main tool to help address those needs. In the same fashion, a civil engineer focuses their systems-based thinking on infrastructure, a mechanical engineer on physical structures, and an industrial engineer on industrial processes.

Unlike other engineering professions, software engineering does not have a professional licensing requirement or shared code of ethics. In some ways, this is good (you can be a software engineer without having ever set foot in a college). But, it means that “engineers” can have all kinds of knowledge within the tech industry, leading to a kind of title ambiguity that is sometimes freeing, and sometimes frustrating for those of us who fall out of the default of what a “real” engineer is in the technical space.

Not all engineers are software developers. Not all people with technical knowledge are software developers. Your average developer advocate, community engineer, site reliability engineer, support engineer, or software architect may have a deep knowledge of your product without ever writing a line of production code. Treating “engineer” as entirely synonymous with “software developer” does a disservice to the kinds of technical knowledge that can exist within an organization, and to the paths towards technical knowledge that exist outside of a traditional software development career.

If you’re interested in seeing the full pink glory of the original slides, you can download them here.