home
navigate_next
Market insights
navigate_next
Salesforce

Quick Look at MongoDB's Salesforce Engineering Team

August 9, 2023
Primary Topic
Relevant Growth Stage
Recent Team Analysis
A Full Breakdown of the Salesforce Orgs
Related Teams
No items found.
Have a Question?
Thoughts on this topic or want to discuss your Salesforce team?
Navigation Arrow
schedule intro
arrow_forward

MongoDB's Salesforce Engineering Team

The team at FoundHQ has spent the better part of the last 15 years focused entirely on helping companies build out their internal Salesforce capabilities.

And we can tell you one thing with absolute certainty - the majority of companies prefer to hire Salesforce talent with recent experience working on other, internal Salesforce teams.

The alternative would be hiring individuals from a Consulting Partner. Typically, that is the fallback plan if you struggle to hire the talent you want or you find an exceptional person that happens to come from Partner.

But 65% of MongoDB's Salesforce Engineering org was at a Consulting Partner directly prior to joining the team - it's clearly a conscious hiring strategy for them.

19 Salesforce Engineers in total, including individuals from:

  • Deloitte (4)
  • Accenture (2)
  • Capgemini
  • Huron
  • Apps Associates
  • Cognizant


Additionally, 11 out of 19 Developers at MongoDB are based in India.

In our opinion, both of these approaches make a ton of sense if you have the internal team to support it.

Let's quickly dig into why companies typically shy away from this approach and why it seems to be working for MongoDB.

Why Don't Customers Hire from a Salesforce Partner?

The #1 stated reason why Salesforce Customers prefer not to hire talent from a Salesforce Consulting Partner is a fear that they lack the ability to execute on a long-term, strategic roadmap.

By definition, the job of a Consulting Partner is to help you implement Salesforce and then skip town - turning the ongoing strategy over to your internal team. The challenge then becomes that Salesforce Consultants only see the initial implementation (phase 1) and they don't understand what it takes to incrementally build out the platform on a longer time horizon.

Why Don't Customers Hire Offshore Engineers?

The biggest drawback to hiring Salesforce Engineers in India is time zone differences.

You are operating on virtually opposite schedules, which can pose a challenge for collaboration and coordination of a smooth release management process. It makes sense to keep Development onshore if you don't have the organizational capabilities to keep everyone in sync.

But there are relatively easy solutions to put in place that allow for you to build a global Engineering org:

  1. Onshore Development Leads serve as an intermediary between US-based Leadership, US-based stakeholders, and offshore Development teams.
  2. Structured Dev Ops &ReleaseManagement allows you to have an Engineering team that literally works around the clock because when your US team ends their day, the India team is just beginning. This allows for massive productivity gains assuming the work is being properly tested and pushed into production.


Benefits of Hiring from a Salesforce Partner

A counterargument we've heard over the years is that nobody will have the breadth of exposure quite like a Salesforce Consultant.

After all, someone working for a Customer only gets a glimpse of a single Salesforce instance throughout their tenure, while you may work on 3-5+ separate orgs in a year working for a Consulting Firm. The breadth of that exposure can be an advantage but the concerns outlined here are real - you need to have clear strategy and guidance from above in order to build a cohesive, long-term roadmap.

Benefits of Hiring Offshore Engineers

There are immense benefits to building an offshore Salesforce Development team. In addition to having access to a much larger talent pool and saving roughly 50% when hiring in lower cost of living regions, a global Salesforce team allows for continuous development and releases.

You effectively pick up another 12 hours each day where code is being written and pushed into production - all assuming, you have the QA, Dev Ops, and release management process to maintain quality standards.