Pros
Strong technical learning environment. Some architects were excellent and invested in teaching solid development and integration patterns. I grew a lot technically. Certifications were supported, making it a strong launchpad for someone entering the Salesforce ecosystem. Talented, kind colleagues from diverse backgrounds. I built meaningful professional relationships and lasting friendships here. Exposure to U.S.-based clients and complex implementations early in my Salesforce career. Clear internal messaging around expanding opportunity in underdeveloped locations, which many employees genuinely believed in and cared about.
Cons
Promotions were officially tied to Salesforce certifications and performance evaluations. The certifications required and the evaluation criteria for each role was documented in a shared spreadsheet. In practice, those criteria were not applied consistently across teams. Some employees advanced without meeting stated thresholds, while others were held strictly to them. Advancement often depended on the line of business and how the delivery director interpreted or applied those criteria. Although a formal career path was outlined, advancement decisions did not always consistently reflect tenure, scope of responsibilities, or accumulated experience. Criteria for internal transfers were not always transparent. “Business need” was frequently cited, but the decision framework behind that determination was not clearly communicated. Greater clarity around what constitutes a business need would improve trust and retention. Annual raises were modest and often did not reflect increased responsibility, quality of work, or strong peer feedback received during evaluations. While the company offered unlimited PTO, extended time off was informally discouraged in practice. Flexibility appeared to vary depending on individual circumstances, which at times created perceptions of imbalance within teams. But more importantly there seemed to be a disconnect between sales, scoping, and delivery. Projects were scoped, assigned fixed hours, and then handed to delivery. In many cases, the individuals who scoped the project were not the same ones executing it, which created a disconnect between estimation and implementation. Scoping was usually made by architects on top of their daily responsibilities, signaling they might had limited time available for deeper technical analysis before commitments were made. As a result, allocated hours did not always reflect the true technical complexity involved. Delivery timelines were sometimes driven more by calendar targets than by realistic effort. When risks were communicated but deadlines slipped, accountability tended to fall on delivery rather than on initial scoping assumptions. Then, situations that could have been handled as routine project adjustments were sometimes treated as critical failures, contributing to stress within certain teams. Corrective Action Plans (CAPs) were used frequently in some teams, sometimes in response to relatively minor issues such as communication or soft-skills concerns. Combined with delivery pressure, this created a demanding and high-scrutiny environment, contributing to stress and higher turnover in certain teams. Again, experiences could vary a lot depending on the team you were in. About the mission, the company often emphasized that “Talent is everywhere, opportunity is not.” A powerful idea, and one many employees believed in. However, during my tenure I did not see Guatemalan employees advancing into senior management roles. Leadership remained concentrated among U.S.-based individuals or long-standing internal networks. For many of us, that contrast between the mission and the leadership structure was hard not to notice.
