Building and Leading a Salesforce Dev Team

Part 100: Building and Leading a Salesforce Dev Team

You can design the most elegant architecture in the world. Governor limits accounted for. Separation of concerns pristine. Trigger framework bulletproof. None of it matters if the people building it can’t execute — or worse, if they can execute but hate working with you.

I’ve seen technically brilliant architects fail because they treated their team like code executors. I’ve also seen average architects produce outstanding results because they built a team that trusted them, challenged them, and genuinely wanted to ship great work together.

This post is about the human side of Salesforce architecture. How to find the right developers, how to lead them without being a tyrant, how to train them so they outgrow you, and why your entire purpose as an architect or tech lead is to serve your team — not the other way around.

How to Find the Right Devs for Your Team

What to Actually Look For

Here’s an unpopular opinion: certifications are the least important thing on a Salesforce developer’s resume. I’ve interviewed developers with six certifications who couldn’t write a basic trigger handler, and I’ve hired developers with zero certifications who understood separation of concerns intuitively because they came from a strong software engineering background.

What you should actually evaluate:

Problem-solving ability over platform knowledge. Salesforce-specific skills can be taught. The ability to decompose a business requirement into a technical solution cannot. Give candidates a real scenario: “A client wants to automatically assign cases based on product line, region, and customer tier. Walk me through how you’d approach this.” You’re listening for how they think, not whether they name-drop the right feature.
Understanding of fundamentals. Do they understand bulkification? Can they explain why a SOQL query inside a for loop is a problem without just saying “governor limits”? Do they know when to use a Flow versus Apex, and can they articulate why? These fundamentals separate developers who copy-paste from Stack Overflow from developers who build maintainable systems.
Communication skills. This one gets overlooked constantly. A developer who can’t explain their technical decisions to a non-technical stakeholder is a liability in the Salesforce ecosystem. Salesforce projects involve admins, business analysts, project managers, and end users. Your developers need to translate between all of them.
Curiosity and learning orientation. Salesforce ships three major releases per year. The platform changes constantly. You want developers who get excited about new features, not developers who complain every time something changes.

Hiring Tips That Actually Work

Stop writing job descriptions that list 47 required skills. You’re not going to find someone who’s an expert in Apex, LWC, Flows, Experience Cloud, OmniStudio, Data Cloud, integration patterns, CI/CD, and also has “excellent communication skills.” Write job descriptions that describe the problems your team solves, not a laundry list of technologies.

Use practical assessments instead of trivia questions. I don’t care if someone can recite the order of execution from memory. I care if they can look at a failing test class and figure out why it’s failing. Give candidates a small take-home exercise or a live debugging session. You’ll learn more in 30 minutes of watching someone debug than in an hour of behavioral interview questions.

Hire for the team you have, not the team you wish you had. If your current team is three senior developers, hiring another senior developer doesn’t help. You probably need a mid-level developer who can handle the day-to-day work while your seniors focus on architecture and mentoring. Think about team composition, not just individual skill level.

Look beyond the Salesforce ecosystem. Some of the best Salesforce developers I’ve worked with came from Java, .NET, or full-stack JavaScript backgrounds. Apex is Java-like enough that experienced Java developers pick it up fast, and they often bring better software engineering practices with them — things like dependency injection, design patterns, and automated testing that the Salesforce ecosystem has historically been weak at.

The Only Correct Way to Lead a Team: Servant Leadership

I’m going to be blunt. If you became an architect or tech lead because you wanted authority, you’re in it for the wrong reasons. The moment you start thinking of leadership as a position of power, you’ve already lost your team.

What Servant Leadership Actually Means

Servant leadership is not some corporate buzzword you put in your LinkedIn headline. It’s a daily practice. It means your primary function is to remove obstacles for your team, not to assign tasks and check status.

Here’s what this looks like in practice:

Your developer is stuck on a complex integration? You don’t send them a link to the documentation and say “figure it out.” You sit down with them, understand the problem, and either help them solve it or find someone who can.
Your team is getting pulled into meetings that waste their time? You attend those meetings instead, shield your team from the noise, and bring back only what’s relevant.
A business stakeholder is pressuring your developer to cut corners? You step in and have that conversation yourself. You’re the buffer between business pressure and technical integrity.
Your junior developer made a mistake in production? You don’t throw them under the bus in the post-mortem. You take responsibility publicly and coach them privately.

The Practical Difference

I once worked with a tech lead who would review pull requests by leaving comments like “This is wrong. Fix it.” No explanation of why it was wrong, no suggestion for how to fix it, no context about the pattern they wanted to see instead. That team had 60% turnover in a year.

Compare that with a lead who wrote PR comments like: “This approach works, but it’ll hit governor limits when we process more than 200 records. Here’s a pattern that handles bulk operations — want to pair on refactoring this?” Same feedback. Completely different outcome. The second team had developers who actively sought out code reviews because they learned something every time.

Servant leadership is not about being soft. You still hold people accountable. You still enforce coding standards. You still say “no” when someone proposes a bad architectural decision. The difference is in how you do it — with respect, with explanation, and with a genuine desire to help people grow.

Three Questions to Ask Yourself Every Week

What obstacle did I remove for my team this week? If you can’t answer this, you’re not leading — you’re administrating.
Did every person on my team have what they needed to do their best work? Tools, access, clarity on requirements, uninterrupted focus time.
Did I make someone on my team better at their job this week? Through coaching, feedback, pairing, or just pointing them to a resource they didn’t know about.

How to Train a Team That Outgrows You

The goal of training isn’t to create developers who depend on you. It’s to create developers who could replace you. If that scares you, you’re not ready to lead.

Code Reviews as a Teaching Tool

Code reviews are the single most effective training mechanism you have, and most teams do them wrong. They treat code reviews as a gate — a checkbox to merge code. Instead, treat them as a conversation.

What good code review training looks like:

Explain the “why” behind every comment. Don’t just say “use a map here.” Say “A map gives us O(1) lookups instead of O(n) with a list, and since this runs in a trigger context with potentially thousands of records, that performance difference matters.”
Ask questions instead of making demands. “What happens to this code if the list is empty?” teaches more than “Add a null check.”
Praise good patterns, not just flag bad ones. When a developer uses a clean separation of concerns or writes a particularly clear test, call it out. Positive reinforcement shapes behavior faster than criticism.

Pair Programming

Pair programming gets a bad reputation because people do it wrong. It’s not two people staring at one screen while the more senior person dictates code. Effective pair programming looks like this:

Navigator/driver rotation. Switch roles every 20-30 minutes. The junior developer should drive (type) more than the senior. Typing forces you to think through every line.
Think-aloud protocol. Both people verbalize their thought process. “I’m thinking we need a service class here because…” This exposes reasoning that would normally stay invisible.
Use it strategically. Don’t pair on everything. Pair on complex problems, unfamiliar areas of the codebase, or when onboarding someone new. Routine work should be done solo — pairing on simple tasks is a waste of two people’s time.

Set up a recurring weekly session — 30 to 45 minutes — where team members take turns presenting something they learned. It doesn’t have to be formal. Some of the best sessions I’ve seen:

A developer demoing a tricky Flow they built and explaining the design decisions
A walkthrough of a production bug — what happened, why, and how it was fixed
A review of a new Salesforce release feature with a live demo in a scratch org
An “I tried this thing and it didn’t work” session — failures teach more than successes

Make attendance optional but make the content valuable enough that people choose to attend. The moment you mandate knowledge sharing, it becomes a chore.

Mentoring Beyond Technical Skills

The developers on your team need more than Apex coaching. They need guidance on:

How to estimate work. Junior developers consistently underestimate complexity. Teach them to break work into tasks, identify unknowns, and add buffer for testing and code review.
How to communicate with stakeholders. Role-play a scenario where a PM asks “Is it done yet?” and coach them on how to give a useful status update instead of just “almost.”
How to manage their own career. Which certifications actually matter for their goals? Should they specialize in a specific cloud or stay generalist? What does the next role look like for them?

Why You Are There to Serve Your Team, Not Be Their Boss

Let me tell you what happens when architects act like bosses instead of servants.

They make every technical decision themselves and hand down mandates. Their team stops thinking critically because every decision gets overridden anyway. The architect becomes a bottleneck — nothing moves without their approval. Developers stop growing because they never get to make mistakes and learn from them. The best developers leave because they feel micromanaged. You’re left with a team of order-takers who can’t function without you, and you wonder why you’re working 60-hour weeks.

Now here’s what happens when architects serve their team.

They set architectural guardrails — the non-negotiable standards — and then trust their team to make decisions within those guardrails. They ask “What do you think we should do?” before offering their own opinion. They celebrate when a developer proposes a solution they hadn’t considered. They actively work to make themselves less essential, not more. The team becomes resilient. People stay. Velocity increases. And the architect can actually focus on architecture instead of firefighting.

Your value as an architect is not in the decisions you make. It’s in the quality of decisions your team makes when you’re not in the room.

If your team falls apart without you, you haven’t built a team. You’ve built a dependency.

Section Notes

Hiring for problem-solving ability and fundamentals matters more than certifications or platform-specific trivia.
Servant leadership is not a management style you put on your resume — it’s a daily practice of removing obstacles, shielding your team, and taking responsibility.
Code reviews, pair programming, and knowledge sharing sessions are your primary training tools. Use them intentionally, not as checkboxes.
Mentoring goes beyond technical skills — help your developers with estimation, communication, and career planning.
The ultimate measure of your leadership is whether your team can function — and thrive — without you.
If you want loyalty, earn it through service. If you want great work, create the conditions for it. If you want a team that ships, get out of their way and clear the path.