05 · Project management & nearshore
Salesforce programme management and nearshore teams
Nearshore teams can deliver a lot for a reasonable price, if the setup is right. Most problems have little to do with skills and a lot to do with team size, turnover and culture. I plan and steer Salesforce programmes on the client side, including nearshore teams in Eastern Europe and India.
Book a call (opens Microsoft Bookings in a new tab)Typical situation
- A Salesforce programme needs more delivery capacity than the internal team and the current partners can provide.
- A nearshore team is in place, but velocity stays low and the client spends a lot of time explaining and correcting.
- Developers rotate in and out of the team, and knowledge leaves with every change.
- Several teams and partners deliver in parallel, and nobody plans dependencies and releases across them.
What I do
- Programme plan with streams, dependencies, milestones and release plan
- Team setup for nearshore development, including size, roles and seniority mix
- Selection of nearshore partners and agreement on rules for staffing and rotation
- Onboarding into standards, review process and pipeline
- Regular steering with status, risks and decisions for management
What you get
- Nearshore teams that stay stable and build up knowledge of the org
- Predictable delivery across teams and partners
- Quality that is checked in reviews, not discovered in production
- Management that sees status and risks early and decides on facts
How we work together
- 01
Plan and team setup
I plan the programme with its streams and dependencies and define the team setup: how many developers, which roles and which mix of seniority.
- 02
Partner selection
Together with the client I select nearshore partners and agree on rules for staffing, rotation and communication before the first sprint starts.
- 03
Onboarding
New teams get access to the standards, the review process and the pipeline from day one, so they work the same way as everyone else.
- 04
Steering
During delivery I steer plan, risks and quality, keep dependencies between teams visible and report to management in a format that supports decisions.
Programme management on the client side means planning and steering a Salesforce programme across internal teams, implementation partners and nearshore teams. It covers the plan with its dependencies, the team setup, the steering of risks and quality, and reporting that helps management decide. Nearshore teams are often part of it, because they add delivery capacity at a reasonable price. I have worked with nearshore teams in Eastern Europe and India, and the lessons were the same in both regions.
Why do nearshore teams struggle?
When a nearshore team delivers less than expected, the first reaction is often to blame skills. In my experience the reasons are elsewhere:
- Rotating resources. If developers are moved to other projects every few months, knowledge of the org leaves with them. Each new person needs weeks to become productive.
- High turnover. The effect is the same, and it also creates unrest in the rest of the team.
- Teams that are too senior. A team of experienced developers sounds like a safe choice. In practice, too many people want to design and too few want to build, which slows the team down.
- Missing management buy-in. A nearshore team needs decisions, access and attention from the client. Without that, it waits.
How do I set up nearshore teams?
I keep teams at up to around eight developers. Larger agile teams rarely work well, because coordination takes over. If the programme needs more capacity, it gets several teams with clear responsibilities.
Before the first sprint, the client and the partner agree on rules for staffing and rotation. Culture matters as much as skills: shared values, trust and the will to deliver on both sides. I look for these in partner selection and in the first weeks of every new team.
From day one, a nearshore team works with the same standards, pull request reviews and pipeline as everyone else. Reviews are where quality gets checked and where new team members learn the conventions of the org, as described in why pull request reviews are a must in enterprise projects.
What does steering look like across several teams?
With several teams and partners, the plan only holds if dependencies and releases are coordinated. I keep a programme plan with streams and dependencies, align releases through one shared process and report status, risks and decisions to management. The rules that make several partners work together are described under partner governance, and the shared release process under DevOps and release management.
If you are planning a nearshore setup or want to get an existing team back on track, send me a message or read more about me.
Frequently asked questions
How large should a nearshore Salesforce team be?
Up to around eight developers per team. Beyond that, agile teams rarely work well: coordination takes over, and sprint meetings become long. If a programme needs more capacity, I set up several teams with clear responsibilities instead of one large one.
What makes nearshore teams succeed?
Culture, shared values, trust and the will to deliver, on both sides. Management buy-in is needed as well, because a nearshore team needs time, attention and decisions from the client. Skills matter, but they are rarely the reason a team struggles.
What slows nearshore teams down?
Rotating resources and high turnover, because knowledge of the org leaves with every change. Teams that are too senior can also cause problems: experienced developers who all want to design and nobody who wants to build create unrest and slow the team down.