Engineering leaders are being asked to navigate something genuinely new. Not just a technology upgrade, and not just another platform shift. Instead, we face a fundamental change in how software gets built, who builds it, and what it means to lead a technical team. AI is not a feature you can bolt onto your existing organization. It reshapes teams from the inside, changes what your best engineers should be focused on, and demands a kind of leadership that many organizations have never had to develop before.
I recently spent a week in Mexico City for the Scaling Tech Podcast, sitting down with engineers, founders, and researchers who are on the front lines of this shift. Across those conversations, a coherent set of leadership themes emerged: themes that are practical, urgent, and largely absent from the standard leadership advice you’ll find in most management books.
Here’s what the people building real AI systems in the real world told me about what it takes to lead well in the age of AI.
1. Ambiguity Tolerance Is Now a Core Leadership Competency
Traditional engineering leadership rewards precision: clear requirements, predictable timelines, measurable outcomes. AI-driven development disrupts every one of those assumptions. Models behave non-deterministically. Accuracy rates fluctuate. What works in testing sometimes fails in production for reasons that aren’t immediately obvious. The ground shifts under you constantly because the underlying technology and competitive landscape are evolving at a pace that is genuinely unprecedented.
Dr. Francisco Javier Novoa, an organizational consultant and agile coach who spoke at the IA Expo in Mexico City, was direct about what this demands from leaders:
“Leaders today have to learn to work in that ambiguous environment in order to operate under conditions that are not necessarily predictable and where you have to improvise, always supported by different scenarios. So, when you learn to think systemically and in uncertain environments, you can become very powerful in organizations where things change rapidly.”
He also drew an important distinction between transformational leaders and maintenance leaders. Both are valuable. But knowing which one you need to be and when, is itself a leadership skill. AI initiatives require transformational leadership: the willingness to experiment, to accept that early results will be imperfect, and to navigate your organization through a period of change without waiting for certainty that isn’t coming.
If you’re leading an AI initiative, the first question to ask yourself is not “do I have the right tools?” It’s “am I comfortable operating in an environment where the rules keep changing?”
2. Leaders Need to Be Deeply Involved, Not Just Supportive
There’s a version of AI leadership that looks like this: the executive announces the AI initiative, sets a budget, assigns a team, and asks for quarterly updates. That model will fail.
Andrés del Cos, founder of the digital transformation consultancy EscalaMiNegocio, has worked with many companies on AI adoption and was unambiguous about what distinguishes successful transformations from failed ones:
“Leadership has to have the ambition to actually move forward with digital transformations. And this ambition is not only about ‘let’s do a digital transformation, let’s add AI,’ but be deeply involved in the initiatives and be deeply involved in the follow-up of all these initiatives. Because when employees see that their own director, their founder is really involved in these projects, they also feel more sure that this is going to be a success.”
Deep involvement doesn’t mean micromanagement. It means leaders understand what their teams are building, can speak to why it matters, and are actively unblocking obstacles rather than receiving reports from a distance. It means attending demos, asking hard questions about accuracy and reliability, and understanding enough about how LLMs work to participate meaningfully in architectural decisions.
This also applies to data strategy. Andrés made a second point that is easy to underestimate: the entire AI stack depends on data, and many organizations’ leadership teams are not yet data-obsessed in the way that AI demands. “Imagine having an organization of 50, 100 people, but nobody is data-centric or data-obsessed. You really need to have these people know and understand that data is kind of like the central nervous system of the company in the future.”
If your organization hasn’t already made data quality, governance, and accessibility a leadership priority, that needs to happen in parallel with your AI initiatives. Not after.
3. The Engineers You Need Are Architects, Not Just Coders
One of the most consistent themes in my Mexico City conversations was about how the role of the software engineer is evolving, and what that means for how engineering leaders should be hiring and developing their teams. Pablo Fajer, Founder of Codifin put it well:
“The value of the software engineering community right now is how they’re able to create systems, how they’re able to create models that ensure that the code that used to be provided by humans, and now AI provides a lot of it, is good code… A lot of the talent that I’ve seen is shifting towards those types of parameters. They’re becoming more architects and they’re becoming more data-led developers.”
This shift has real implications for your hiring criteria and your internal development programs. Engineers who thrive in an AI-augmented environment aren’t the ones who are the fastest typists or who can recall syntax from memory. They’re the ones who can design systems, orchestrate tools and data sources, reason about failure modes, evaluate AI outputs critically, and translate complex technical decisions into business impact.
Global AI Professor Osvaldo Ramirez Hurtado from the Panamerican Business School added another dimension to this: he cautioned against writing job descriptions for AI roles that are essentially wish lists of technical credentials, when what you actually need is someone who can translate business requirements into an AI architecture. As he put it, in this disruption moment, job descriptions are often written from the wrong starting point. Start with the business problem, then design the role around the person who can solve it.
His third piece of advice was perhaps the most human: “You have to reduce your own ego. You have to work more on the soft skills rather than the hard skills, because otherwise you will always be at the top of the ego perspective and not … translating the needs of the business.” This applies as much to the leaders staffing AI teams as to the individual engineers themselves.
4. Empower Your Whole Team to Use AI Tools but Maintain Accountability
There’s sometimes a fear among engineering leaders that broadly enabling AI coding tools will lead to lower-quality code, or that developers will stop learning fundamentals. The evidence from the teams I spoke with tells a different story.
Pablo Fajer was clear: his position is that all developers should be enabled to use AI tools like Cursor and whatever else is available to them. The catch is that accountability stays with the engineer: “They have to be solely responsible for the product that they give.”
This framing, of broad enablement and full accountability, resolves a lot of the anxiety about AI coding tools. You’re not lowering the bar for what ships. You’re raising the ceiling on how fast your team can ship and iterate. The teams that benefit most from this acceleration are the ones that use the time saved to iterate on quality, not to reduce headcount.
There’s an important corollary here for leadership: if you’re enabling your engineers to move faster, make sure you’ve also built the evaluation and review infrastructure to match that speed. Code reviews, automated testing, and human-in-the-loop validation at key decision points all need to scale with the pace of AI-assisted development.
5. Choose the Right Partners (And Know What Kind of Help You Actually Need)
No engineering organization should be trying to navigate an AI transformation entirely on its own. The pace of change is simply too fast. Andrés del Cos described two distinct types of partners that companies typically need:
- A consulting or advisory partner who can guide the organization through strategy, help identify high-value use cases, and provide a road map for implementation. This model works well for larger organizations that have the internal capacity to execute once they have direction.
- An implementation partner (like our team at AgilityFeat) that will actually build things for you, applying current best practices in LLM integration, AI-driven development, and system architecture. This model fits companies that don’t have the internal AI expertise yet, or that want to get a prototype built quickly while their own team develops the skills to take it forward.
For many companies, the answer is both: a trusted advisor to help shape the strategy and a capable engineering team to execute it. The critical thing, as Andrés emphasized, is that leaders stay involved in both relationships. Outsourcing strategy to a consultant while remaining disengaged is just as risky as outsourcing execution.
6. Don’t Wait Until You Feel Ready
One of the most practically important things I heard during my week in Mexico City came from Andrés del Cos. It applies directly to engineering leaders who are still deciding when to start moving more aggressively on AI:
“Everybody’s ready for AI. Everybody’s ready for AI, but they’re in different parts of implementing AI… Everybody’s ready for AI, but it’s kind of human nature to be scared of something new and something different. So, don’t be scared. You are ready to implement AI.”
The readiness you’re waiting for isn’t coming. There will always be a new model release, a new tool, a better framework just around the corner. The teams that are building real AI capability today are not the ones who waited until everything was clear. They’re the ones who started experimenting early, accepted that they would learn through failure, and built up institutional knowledge through doing.
Dr. Novoa closed my second episode with a reflection that captures this spirit as well as anything I’ve heard: “Creativity has to find you working and producing… Change has to find you producing, experimenting, questioning, opening yourself to possibilities. The moment you open yourself to possibilities, then new things can arrive.”
That’s not a statement about AI specifically. It’s a statement about how organizations learn. And for engineering leaders right now, it’s the most important leadership principle of all.
Building the Team Behind the Vision
The leadership principles above only work if you have the right team to execute them. Building AI-capable engineering teams is one of the most significant talent challenges companies face today. The demand far outpaces supply in most North American markets and the cost of that talent is rising fast.
Latin America represents a meaningful answer to this challenge. It has a large pool of senior engineering talent with the skills and mindset to excel in AI-driven development environments. These engineers are already building sophisticated AI applications. The examples I’ve cited in this post are proof of that. What they often lack is visibility to North American companies who are looking for exactly what they offer.
AgilityFeat specializes in bridging that gap. Whether you’re looking to embed experienced AI engineers in your existing team through staff augmentation, build a full capability center in LatAm through our Build-Operate-Transfer model, or engage our team to build your first AI-driven prototype using our new Builder Pods, we have the experience and the network to help you build well. Contact us today to start that conversation!
Author’s note: Arin Sime is the Founder of AgilityFeat and host of the where he interviews engineering leaders about scaling teams and building great products. The Mexico City episode series referenced in this post is available on Spotify, Apple Podcasts, and YouTube. For more details on the guests, see the show notes for the first and second episodes at ScalingTechPod.com
