Proprietary Systems Developers Explained For Recruiters

Proprietary Systems Developers Explained For Recruiters
Post Author: Aaron Decker | Image by Pexels from Pixabay
Date published: August 16, 2020

I was really struggling with what to call this post, but I think "Proprietary Systems Developers" is the closest description I can come to what this topic is.

In plain english I'm talking about these kind of folks: Salesforce Developers, Tableau Developers, Microsoft Sharepoint Developers, SAP Developers and others like that. These people are programming, but they are programming within some specific commercial system.

These are proprietary systems (meaning owned and controlled by a company, likely not open source) that have their own custom programming languages or subsets of more common open source languages. Often they are so complicated people specialize in just one of these things, and that is all they do.

These jobs often require specific years of experience with a given system. They are not looking for just any programmer that knows Java, or C#. Most of these job listings are looking for somebody to work with one specific technology with great depth.

Examples of salesforce developer job postings

There are a lot of these because Salesforce actually has its own programming language called "Apex".

salesforce devs screenshot

SAP developer job postings:

Most SAP developers are writing code in Java from what I've seen, but need a lot of special domain knowledge and a typical run of the mill Java dev is not what hiring managers are looking for here. You can see they even specify for special experience within SAP.

SAP developer listing

Note: I took these screenshots from Randstad because their website is easy to look up job postings quickly.

The Advantages Of Working on Proprietary Systems

From a career standpoint, there are some advantages. Generally speaking large companies are using technologies like Sharepoint and SAP. This means the jobs you can get doing this work are high paying and stable.

From a consulting/contracting perspective if you have a niche of doing e.g. Salesforce integrations the work is rumored to be extremely lucrative.

Generally speaking from what I have heard most of these kind of positions are harder to fill because programmers actively try to avoid being pidgeonholed and "get stuck" doing one technology. So there would always be plenty of work as long as the tech stays relevant. Which brings me to the disadvantages...

The Disadvantages

The big risk of making a career out of working on e.g. Sharepoint specifically, is that either the field becomes crowded or the tech loses popularity. And as you probably know, the tech world moves fast so your chosen technology can easily die in the course of a couple of years. This famously happened with flash just a few a years ago.

Personally, I try to stick to open source programming languages, frameworks, databases and technologies because I feel that they tend to be better to work on, more popular, and longer lived.

I feel that becoming an "SAP Developer" or something along those lines would kill my career trajectory. Is that true? I'm not so sure, but I know a lot of other developers that feel the same way.

Categories of Proprietary Systems:

There are more, but these are some of the common types.

  • ERP: Enterprise Resource Planning. E.g. helps a manufacturing business manage supply chains and accounting. Often more than just that.
  • CRM: Customer Relationship Management. Used for sales + marketing and customer service operations.
  • CMS: Content Management System. Used to manage content on websites and similar.
  • BI / BA Systems: Business Intelligence or Business Analytics tools. These are reporting tools.

List of Proprietary Systems

  • Microsoft Sharepoint: maybe best explained as a CMS you can build anything in? Sharepoint is used for a lot of things.
  • Salesforce: Primarily a CRM but has a ton of other applications + features.
  • Tableau: data visualization software that can integrate with many systems.
  • SAP: an ERP system (I'll explain a little more below 👇).

Advice For You As A Recruiter

I would treat reading a job description for an SAP role like venturing into an alien land. You are going to need to look up everything because a lot of what is mentioned is only going to be relevant to SAP systems.

SAP is an ERP system. This means it is used to manage many things in a company: the supply chain, the accounting, maybe even the HR records. SAP is the 800lb gorilla in the world of ERP systems.

If you are recruiting an SAP developer, you have a whole other vocabulary to learn in addition to the basic tech stuff you need to understand about application development. Treat each of these proprietary systems as something totally different and exotic, like you are going on vacation to the Galápagos Islands.

Summary

Let me know if I missed anything I should add here. There are a ton of big proprietary systems like these but I tried to list out the most common ones I see come up.

Hope this helps you to understand how to go about thinking about these types of roles as opposed to roles with job titles like "Java Developer" or "Python Engineer".


Want updates?

Want new posts about tech topics emailed to you? Sign up to the list below 👇

Also, if you are interested in learning technical topics through a video course specifically created for recruiters, don't forget to check out the courses I offer.

The main course "How to Speak Software Engineering Jargon for Recruiters" is specifically designed to help tech recruiters get up to speed fast on technical topics.


Written By Aaron Decker

I'm currently a co-founder and head of engineering at a venture backed startup called Bounty. I tend to think of myself as a backend engineer that can work up and down the stack in Typescript. Previously, I have worked as a Tech Lead and hired teams, and as a Senior Software Engineer at multiple fortune 500 companies building large products. I also did a brief stint teaching programming courses as an Adjunct Instructor at a local community college, which taught me a lot about breaking down complex things into understandable chunks.