You send an email or start a conversation with your favorite SaaS company. Quite often, you will talk to someone with a position of “Support engineer”.

For a small minority, they certainly deserve to be called “engineers” – they can talk about GraphQL for hours, look at your code, and even throw some programming joke.

However, for the largest majority, “engineer” is just a marketing slang.

It helps employees feel temporarily better and included, especially if you have a culture dominated by engineers. But it may be short-lived- their title quickly fades away when they start asking simple and basic questions that someone technical should know.

It might also impress business executives in a Powerpoint, but if developers are the ones actually using and paying for your service, this will soon upset some of them. As I wrote in a previous post, if developers send you a question, they want a straightforward solution.

So what makes a real “support engineer”?

They are engineers

Of course this is a very broad statement. You don’t call someone a scientist, but a physicist, biologist, etc.

However, in the large set of “engineers” there are a few characteristics that are fundamental to its essence, just like “scientists”, “managers”, etc.

It’s the word itself, deriving from ingeniare that stands for generating/creating.

Taking it to a more contemporary understanding, this is a definition from the 1961 Conference of Engineering Societies of Western Europe and the USA:

A professional engineer is competent by virtue of his/her fundamental education and training to apply the scientific method and outlook to the analysis and solution of engineering problems. He/she is able to assume personal responsibility for the development and application of engineering science and knowledge, notably in research, design, construction, manufacturing, superintending, managing and in the education of the engineer. His/her work is predominantly intellectual and varied and not of a routine mental or physical character. It requires the exercise of original thought and judgement and the ability to supervise the technical and administrative work of others. His/her education will have been such as to make him/her capable of closely and continuously following progress in his/her branch of engineering science by consulting newly published works on a worldwide basis, assimilating such information and applying it independently. He/she is thus placed in a position to make contributions to the development of engineering science or its applications. His/her education and training will have been such that he/she will have acquired a broad and general appreciation of the engineering sciences as well as thorough insight into the special features of his/her own branch. In due time he/she will be able to give authoritative technical advice and to assume responsibility for the direction of important tasks in his/her branch.

It’s a comprehensive and magnificent statement for what’s behind the title.

Surely, it make sense to take not take this to the extreme. Nowadays, there are several alternative learning resources that empowers one to be an autodidact and an engineer is doesn’t necessarily need a 5-year degree.

But it’s not something you learn in a few days, or even weeks. It’s a practice that requires several months of training and enhancement of one’s skills.

Most “support engineers” lack any significant technical background or training that would enable them to perform any of the activities of an engineer.

If someone don’t have a clue of what a string is, how exactly would they be able to “give authoritative technical advice and to assume responsibility” for a simple API? How long would it realistically take for them to understand the apparently simple concepts behind RESTful APIs, JSON syntax, data structures, databases, etc.

It’s not so hard to see the issue.

That’s why there so much confusion and disappointment of customer support of certain software companies.

Support engineers always create

Although they don’t develop applications directly, support engineers should constantly create workarounds, suggestions and ultimately solutions.

It’s not about copy-and-pasting the same answer, using a macro, or referencing to the documentation You have to understand, even if minimially, the core concepts behind the product that you’re supporting.

It’s impossible to do these if you have a yet narrow understanding of your field. 

Insofar as support engineers in software companies are concerned, if you don’t a clue of how to debug code, how can you really be in the front-line coming up with solutions for developers? 

Hierarchies are not always bad

Both for the company and the employees, a fair hierarchy is fundamental for growth.

You send an email or start a conversation with your favorite SaaS company. Quite often, you will talk to someone with a position of “Support engineer”.

For a small minority, they certainly deserve to be called “engineers” – they can talk about GraphQL for hours, look at your code, and even throw some programming joke.

However, for the largest majority, “engineer” is just a marketing slang.

It helps employees feel temporarily better and included, especially if you have a culture dominated by engineers. But it may be short-lived- their title quickly fades away when they start asking simple and basic questions that someone technical should know.

It might also impress business executives in a Powerpoint, but if developers are the ones actually using and paying for your service, this will soon upset some of them. As I wrote in a previous post, if developers send you a question, they want a straightforward solution.

So what makes a real “support engineer”?

They are engineers

Of course this is a very broad statement. You don’t call someone a scientist, but a physicist, biologist, etc.

However, in the large set of “engineers” there are a few characteristics that are fundamental to its essence, just like “scientists”, “managers”, etc.

It’s the word itself, deriving from ingeniare that stands for generating/creating.

Taking it to a more contemporary understanding, this is a definition from the 1961 Conference of Engineering Societies of Western Europe and the USA:

A professional engineer is competent by virtue of his/her fundamental education and training to apply the scientific method and outlook to the analysis and solution of engineering problems. He/she is able to assume personal responsibility for the development and application of engineering science and knowledge, notably in research, design, construction, manufacturing, superintending, managing and in the education of the engineer. His/her work is predominantly intellectual and varied and not of a routine mental or physical character. It requires the exercise of original thought and judgement and the ability to supervise the technical and administrative work of others. His/her education will have been such as to make him/her capable of closely and continuously following progress in his/her branch of engineering science by consulting newly published works on a worldwide basis, assimilating such information and applying it independently. He/she is thus placed in a position to make contributions to the development of engineering science or its applications. His/her education and training will have been such that he/she will have acquired a broad and general appreciation of the engineering sciences as well as thorough insight into the special features of his/her own branch. In due time he/she will be able to give authoritative technical advice and to assume responsibility for the direction of important tasks in his/her branch.

It’s a comprehensive and magnificent statement for what’s behind the title.

Surely, it make sense to take not take this to the extreme. Nowadays, there are several alternative learning resources that empowers one to be an autodidact and an engineer is doesn’t necessarily need a 5-year degree.

But it’s not something you learn in a few days, or even weeks. It’s a practice that requires several months of training and enhancement of one’s skills.

Most “support engineers” lack any significant technical background or training that would enable them to perform any of the activities of an engineer.

If someone don’t have a clue of what a string is, how exactly would they be able to “give authoritative technical advice and to assume responsibility” for a simple API? How long would it realistically take for them to understand the apparently simple concepts behind RESTful APIs, JSON syntax, data structures, databases, etc.

It’s not so hard to see the issue.

That’s why there so much confusion and disappointment of customer support of certain software companies.

Support engineers always create

Although they don’t develop applications directly, support engineers should constantly create workarounds, suggestions and ultimately solutions.

It’s not about copy-and-pasting the same answer, using a macro, or referencing to the documentation You have to understand, even if minimially, the core concepts behind the product that you’re supporting.

It’s impossible to do these if you have a yet narrow understanding of your field. 

Insofar as support engineers in software companies are concerned, if you don’t a clue of how to debug code, how can you really be in the front-line coming up with solutions for developers? 

Hierarchies are not always bad

Both for the company and the employees, a fair hierarchy is fundamental for growth.