Growing up in Colombia, spending nearly five years in the UK for my MSc and early career, and then coming back to build engineering operations in Bogotá and Medellín for US companies—I’ve worked across cultures that approach management very differently. And through all of it, I’ve learned something that might sound obvious but often gets lost in quarterly targets and sprint deadlines: people aren’t resources to be optimized—they’re the entire foundation of what we build. This realization has completely changed how I approach leadership.
When I started my career, I was that engineer who thought good code and smart decisions were enough. But somewhere between deploying a critical iOS feature at 2 AM and watching talented team members burn out, I realized that the best technical decisions mean nothing if the people making them are exhausted, disconnected, or don’t feel safe to speak up. My time in the UK taught me a lot about structured processes and professional development frameworks. Coming home to Colombia reminded me that relationships, loyalty, and personal connection are equally powerful leadership tools. Today, I’m convinced that people-centric management isn’t just the right thing to do—it’s the competitive advantage that separates exceptional engineering teams from the rest.
Why People-First Management Matters More Than Ever
Let me be direct: we’re in a talent crisis that no amount of ping-pong tables will solve. In 2025-2026, leadership trends show us that 71% of leaders are experiencing increased stress, with 40% considering leaving their jobs altogether. The irony? This stress is often triggered by how they’re managed. As AI starts handling more technical tasks, human skills become even more valuable—but only if we’ve created environments where humans can actually think, grow, and flourish.
People-centric management recognizes workers as whole people with lives, challenges, and aspirations beyond their professional roles. It prioritizes well-being and growth while enhancing performance. In technical teams especially, this approach isn’t just humane—it’s mathematically superior. Teams with high psychological safety innovate faster, make better decisions, and experience lower turnover.
From my experience managing distributed teams across Colombia, the US, and beyond, the companies winning the talent game aren’t necessarily offering the most money. They’re offering clarity, connection, and genuine investment in people. Google, Netflix, Apple, Microsoft, and Amazon dominate retention rankings not because they have unlimited budgets, but because they’ve mastered the art of making engineers feel valued, progressing, and challenged in the right ways.
Building Cross-Cultural Remote Teams That Actually Work
LATAM to US collaboration is something I navigate daily—building engineering teams here in Medellín that operate as extensions of US-based product organizations. It’s beautiful, complex, and requires intentional design. The 3-5 hour overlap between Colombian and US time zones is a gift, but I’ve seen it squandered when leaders treat it as a constraint rather than an opportunity.
Here’s what I’ve learned: successful distributed teams don’t happen by accident. They require clear async rhythms, outcome-based ownership, strong documentation habits, and predictable alignment rituals. In 2025, 72% of engineering teams operate in fully distributed models, and 68% of technical leaders cite building remote culture as their top priority. This isn’t a temporary trend—it’s the default now.
The shift in leadership mindset is crucial. I’m no longer the central authority figure managing workflow from an office. Instead, I’m a connector, enabler, and cultural architect who brings together people, processes, and purpose across virtual landscapes. Authority isn’t exercised through presence anymore—it’s exercised through influence, clarity, and follow-through.
In practice, this means:
Asynchronous collaboration first. My team doesn’t need me online at the same time to do great work. We use written updates, recorded videos, and documented decisions. Our synchronous time is reserved for decisions, problem-solving, and connection—the things that actually require real-time conversation.
Radical transparency around decisions. I share the “why” behind every call—sometimes this means explaining budget constraints or product direction in ways that aren’t glamorous. But engineers working across time zones in different countries need to understand the full context. They’re not here just to execute; they’re here to think.
Celebrating time zone diversity, not fighting it. A team member in Bogotá can progress work while San Francisco sleeps. This is efficiency. But it’s also a gift that lets us operate more like a 24-hour product operation. I try to distribute exciting work, leadership opportunities, and visibility across all time zones.
Psychological Safety: The Foundation Everything Else Rests On
I remember a retrospective where a junior engineer finally admitted they’d been silently fixing bugs in production for weeks rather than asking for help. When I asked why, they said, “I wasn’t sure if questions were okay.” That conversation haunted me. I thought I was approachable. I thought my team felt safe. I was wrong.
Psychological safety is the ability to bring up genuine opinions, ask questions, and own up to mistakes without risking ostracism or punishment. In technical teams, it’s the hidden engine behind innovation. Teams with high psychological safety are measurably better at problem-solving, decision-making, and adaptation. Yet it’s also the most fragile thing to build and the easiest thing to destroy.
The challenge with distributed teams is that psychological safety becomes harder to create. You lose the organic connection-building that happens in physical spaces. People might feel more alone, experience more self-doubt, and question whether their contributions matter. Remote work magnifies insecurity if you’re not intentional about addressing it.
What actually builds psychological safety? Not trust falls or mandatory fun. It’s consistent leadership behavior:
Frame challenges as learning opportunities. When something goes wrong, my instinct used to be blame-finding. Now I lead with curiosity. “What happened?” before “Why didn’t you prevent this?” This signals that learning matters more than perfection.
Explicitly invite different perspectives. I ask “Who has a different perspective?” and actually pause for answers. This sounds simple, but it trains the team that disagreement is expected and valued. Conformity is the death of good engineering.
Model vulnerability. When I’ve made mistakes, I talk about them. When I don’t know something, I say so. This demolishes the illusion that leaders have all the answers and makes it safe for others to be equally honest.
Respond to feedback with genuine appreciation. Thank people specifically. Tell them how their input changed your thinking. Make it clear that the cost of speaking up is low and the value is high.
Retention Strategies That Actually Stick
The numbers are stark: 82% of employees prioritize work-life balance over traditional benefits. Employees who receive high-quality recognition are 45% less likely to leave after two years. And 82% of People and Reward Leaders cite lack of clarity around career progression as their top challenge. These aren’t nice-to-haves—they’re existential for keeping talented engineers.
In my experience, retention failures usually follow a pattern: we hire talented people, we throw them into the work, and then we forget to explicitly invest in their growth. We assume they know they’re valued. We assume they can see their career path. We’re usually wrong.
What I do differently now:
Career conversations aren’t annual events. I talk with my direct reports monthly about where they want to go, what skills they’re building, and how we can create opportunities. This conversation is the most important meeting on my calendar. I write down their goals. I check in on progress. I actively create space for growth—sometimes that means finding work that stretches them, sometimes it means getting them into leadership roles, sometimes it’s a course or certification.
Recognition is specific, frequent, and public. Not the generic “great work on the sprint” stuff. “I noticed how you mentored the new team member on the React architecture—that’s exactly the kind of knowledge-sharing we need. It made a real difference.” The more specific and the more often, the better.
Flexibility is non-negotiable. LATAM culture values family time. US culture values schedule flexibility. Our remote structure lets us honor both. Some team members work early to pick up kids. Some work late. Some take Fridays to handle personal stuff. The work gets done, the deadlines are met, and people feel respected.
Compensation is fair and transparent. I know this isn’t always possible, but I try to be clear about how people are paid, how raises work, and what the path looks like. Ambiguity breeds resentment.
Managing the Balance Between Delivery and Wellbeing
This is where I used to get it really wrong. I’d push hard during crunch time, justify it as temporary, and then be shocked when people burned out or left. The hard truth: you can’t sustain high performance while destroying people. That’s not a sprint—that’s a death march. And it’s not leadership; it’s extraction.
But here’s the thing—shipping matters. We have customers, deadlines, and commitments. The balance isn’t about working less; it’s about working smart and protecting capacity for the human parts of engineering leadership.
In 2025-2026, the winning companies are those balancing technical challenges with sustainability. This means:
Protecting focus time. My engineers need uninterrupted blocks for deep work. I reduce meetings, consolidate async decisions, and guard against the constant Slack interrupt culture that destroys engineering velocity.
Being honest about capacity. When we’re hitting limits, I say so. To my team. To leadership. I’d rather miss a deadline than burn people out. Usually, the solution is simplifying scope, not working harder.
Rotating intense work. Some months are intense—product launches, critical infrastructure work, hard problems. But I balance these with slower months where the focus is learning, technical debt, and recovery. No one gets sustained 60-hour weeks.
Measuring wellbeing alongside delivery. I track velocity and ship rate, yes. But I also track one-on-one satisfaction, promotion readiness, burnout signals, and attrition risk. If wellbeing metrics are red, shipping metrics don’t matter because that’s not sustainable.