Comments Off on Defining roles and responsibility [Recruiting & Employment]

Defining roles and responsibility [Recruiting & Employment]

Posted August 6th, 2011 in Uncategorized by John Coppedge

I regularly talk with all sorts about employment opportunities on the Salesforce platform.  It is clear to me now that it can be very challenging to define exactly what you’re looking for as a prospective employer.


Three common roles I encounter are as follows (but not always labeled as such):


1. Administrator

A good administrator in my mind is someone that keeps the existing Salesforce instance(s) running smoothly.  This includes functions such as:

  • Reports and dashboards
  • List views
  • User administration
  • Addition of picklist values
  • Modification of page layouts
  • Lead & case routing rules
  • Email templates

The key here is that an administrator is not responsible for configuration of new functionality and generally speaking does not need to have a strong knowledge of integrations and other downstream impacts.


2. Architect

An architect is someone who performs business and technical analysis, and develops a solution.  They are responsible for delivering new functionality and must have an intricate knowledge of integrations and other downstream impacts.  This would include:

  • Custom fields
  • Custom objects
  • Analytic snapshots
  • Record types
  • Appexchange packages
  • Workflow rules
  • Approval processes
  • Designation of apex/visualforce (determination of where code must be written, not actually writing the code)
  • Data flow and integration mechanics (not an ETL developer, but may configure an integration if it is GUI-based)

An architect has to understand the basics of administration at a minimum.  I often think of solutions architecture as a progression from an administration, but that could be because it was my own.  Smile


3. Developer

In my mind a developer is someone who writes code.  On the Salesforce platform this necessarily includes Apex and Visualforce with custom controllers.  This designation can get confusing for a few reasons:

a) The term “click-to-configure developer” – it really is great marketing, but does confuse titles.  This confusion is exacerbated by certifications: certified developer and certified advanced developer are starkly contrast in expertise required.   A certified developer is someone who understand the basics of code and can write a vf page with a standard controller, while a certified advanced developer can necessarily write apex/vf custom controllers.  A certified developer is more akin to a certified administrator than to a certified advanced developer.

b) Generalist developers.  There are a ton of folks out there that understand code and have written bits of code on the Salesforce platform.  There is huge distinction between someone who has actively learned the Salesforce platform (including administration, apex, vf, limits, bulk apex, best practices, etc.) versus a generalist developer who has learned just enough combined with their prior OOP experience to code a trigger.  For lack of better terms I’ll call the first a Platform Developer and the latter a General Developer.


Cheers @chrisodavies for the conversation last night that sparked this post.


Do you agree with my classifications?  Would you refer to these roles as anything different?





Note: there are other roles (QA, deployment experts, etc.) that I have not included in this conversation but are quite valuable as well.