DEV Community: daniel llach

The Elephant's Magic: A Technical Leadership Story

daniel llach — Wed, 30 Sep 2026 13:14:37 +0000

How my daughter's bedtime story revolutionized our enterprise architecture

"Dad, you said 'five minutes' a long time ago." Amara's voice carries a mix of tiredness and frustration.

My eyes stay fixed on the error logs flooding my screen. The living room clock shows 10 PM. I've been saying "five more minutes" since her bedtime routine should have started at 8.

"I'm really sleepy," she adds, her small hand touching my shoulder. "You promised to help me with my pajamas."

"Just one more minute," I mutter automatically, still scrolling through production issues.

"But you keep saying that." Her voice breaks slightly. "Just like this morning. And yesterday. And…"

My fingers freeze over the keyboard. Each "and" lands like a hammer, nailing down every broken promise.

Sometimes our biggest technical failures and parenting mistakes stem from the same root: the illusion that presence equals attention.

Three critical production issues fill my monitor. Our design system is causing performance bottlenecks across multiple enterprise applications. The VP wants answers at tomorrow's virtual sync.

But in this moment, my five-year-old daughter has caught me doing exactly what's causing these issues in the first place: being physically present while mentally absent.

My Slack shows five urgent threads. Email notifications keep popping up. The CI pipeline is failing.

"You're not listening," Amara says quietly. "Just like in the morning."

Her words hit harder than any code review feedback I've ever received. The truth in them rings through our living room, echoing off walls that have witnessed too many "just one more minute" moments.

She's right. Just like our enterprise architecture is failing because we haven't truly listened to our team's needs.

The Breaking Point

A month of technical debt has exploded into chaos. Our component library's performance has dropped by 60%, crippling every application in our ecosystem.

The morning's architecture review replays in my mind, each memory a fresh wound:

A junior developer's voice cut off mid-sentence as I shared my screen with a solution, their idea forever lost in my rush to fix.

A QA engineer's message in chat missed as I handled three Slack threads, their warning buried under my multitasking.

A UX designer's concerns lost in a "let's take that offline" that never happened, their insight sacrificed to my schedule.

Now, watching Amara's small figure disappear into her room, shoulders slumped in familiar disappointment, the parallel strikes me with crushing clarity: I'm failing at home the same way I'm failing at work.

Our technical blind spots often mirror our personal ones, and both leave scars we can't see until it's almost too late.

That night, sleep evades me. I pull up our architecture diagrams on my second monitor while chat snippets haunt my main screen:

"But what if we…" (call interrupted)
"I noticed that users…" (message unread)
"The metrics show…" (meeting ended)

Just like Amara's bedtime stories, cut short by my distraction. Each one a small death of possibility.

The Unexpected Teacher

Morning comes with the weight of recognition and a chance for redemption. Instead of my usual routine of metrics and coffee, I sit with Amara at breakfast.

"Tell me about your dream," I say, deliberately turning my phone face down and pushing it away.

Her eyes light up with surprise, then cautious excitement. I see her check, just for a moment, if my laptop is nearby. The fact that she has to check breaks something in me.

"Well," she begins, bouncing in her chair, "there was this elephant, but not a normal elephant…"

"Let me guess," I interrupt, falling into my solution-mode habit, "it was pink?"

She gives me that look. The same one our junior developers give when I jump to conclusions, when I minimize their ideas before they can bloom. "Papi, let me tell it."

Something in her tone mirrors every interrupted developer, every silenced insight. "Sorry. Go on."

"It was an elephant that could turn into anything. But only when nobody was trying to make it turn into something."

I blink. That's… unexpectedly profound.

"So what did you want it to turn into?" I ask, already forming assumptions, my product manager brain whirring to life.

"That's not how it works," she sighs with the patience of a zen master. "You can't make it turn into things. You have to wait and see what it wants to be."

The simplicity of her wisdom leaves me speechless. In five years of life, she's grasped what I've missed in fifteen years of technical leadership.

"But what if you need it to be something specific?" I press, my old habits dying hard.

"Then you get a normal elephant," she shrugs, reaching for her cereal. "The magic only works when you let it surprise you."

I start drawing parallels to our component library, but she's not finished.

"Like yesterday," she continues, "I thought it would become a unicorn, because everyone wants unicorns…"

"And did it?"

"No!" she giggles. "It became a library! With books that could swim! Way better than a boring unicorn."

Sometimes the best solutions come when we stop forcing our expectations and start embracing surprises, in code and in life.

The Technical Revelation

That afternoon, I join our virtual architecture review with Amara's lesson humming in my mind. Twenty faces in tiny squares stare back from my screen, each a reminder of conversations cut short, insights interrupted.

"Before we dive into solutions," I say, resisting my urge to share my screen with diagrams, "I want to hear what you're seeing."

The silence in the Zoom call feels eternal. I see faces preparing to unmute, then stopping. Others looking down, probably checking Slack or email. This is usually when I'd jump in to fill the awkward void, to force the elephant to be what I think it should be.

But today, I wait. Just like with Amara's story.

One second.

Two seconds.

Three…

A junior developer's icon finally lights up. "Um, about those event handlers…" he starts tentatively.

My screen fills with faces leaning forward, the virtual equivalent of held breath. In the silence, I hear Amara's voice in my head: "The magic only works when you let it surprise you."

I notice my fingers instinctively moving to unmute and interject. Instead, I lean back and nod encouragingly at my camera.

"Tell me more," I say, channeling my newfound patience.

Other squares begin to light up. Names appear in the participant list waiting to speak. The conversation flows naturally, unforced. Like a magical elephant deciding what it wants to become.

Forty-five minutes later, we've uncovered what months of rushed virtual meetings missed: our component lifecycle isn't just inefficient. It's fundamentally backward.

The solution emerges from the least expected place: our support tickets.

Reading them like bedtime stories rather than bug reports, we see the narrative we've been missing: our enterprise-grade table component was built for data display when teams were using it for data analysis.

Innovation isn't always about writing new code. Sometimes it's about reading the story hidden in the old, and having the patience to let it unfold.

The Transformation

The next weeks bring changes that ripple through our virtual workspace like magic:

Our daily standups transform:

Cameras turn on more often, faces eager to share
Chat becomes alive with "what if" questions
"Quick solutions" give way to collaborative exploration

The technical metrics follow the human transformation:

Memory usage drops 70% after we reimagine our component's purpose
Response time improves 85% when we start thinking in stories instead of just data
Bundle size decreases 45% as we learn to listen to what teams actually need

But the real magic happens in our Zoom interactions:

A QA engineer's hesitant "This might sound strange, but…" leads to a breakthrough in accessibility patterns.

A junior developer's "I've been thinking…" revolutionizes our event handling system.

A UX designer's "Can I share what I'm seeing?" reveals patterns we'd missed in months of analytics.

Each voice that rises carries the echo of Amara's wisdom: magic happens when we let it surprise us.

The New Normal

Our remote meetings take on a different rhythm, like bedtime stories that unfold at their own pace:

The dreaded "awkward silence" becomes valuable thinking space, pregnant with possibility.

Chat messages get acknowledged and explored, not just "liked" and forgotten.

Screen shares happen less, conversations deepen more.

Team members start reaching out directly:
"Can I think out loud about something?"
"I noticed a pattern I'd like to explore…"
"This might sound crazy, but…"

Each conversation reminds me of breakfast with Amara, the magic happens when we let ideas transform naturally, not when we force them into predetermined shapes.

The Reality Check

Now when I catch myself reaching to share my screen mid-explanation, I hear Amara's voice: "Let me tell it."

It's a powerful reminder that our enterprise architecture challenges often stem not from technical complexity, but from our rush to solution.

Today, our design system serves thousands of enterprise users better because we learned to listen like a five-year-old:

With full presence, even through screens
Without preconceptions
Until understanding emerges naturally

Because sometimes the best technical solutions come from the simplest human wisdom.

That evening, I close my laptop at 6 PM.

"Daddy?" Amara peeks into the home office right on schedule, knowing this is our time.

"Yes, honey?"

"Is it pajama time?"

"It is," I smile, standing up. "And I want to hear all about today's elephant." The smile that lights up her face tells me everything: sometimes our biggest technical breakthroughs start with a simple promise kept.

Originally published on Medium.

Technical Mentoring: The Art of Seeing The Whole Person

daniel llach — Wed, 30 Sep 2026 13:08:01 +0000

A guide to nurturing complete humans, not just better engineers

"My name is Yadu, I like party," she said with a mix of nervousness and determination during her technical interview.

Her code was excellent, her logic impeccable, but her English… well, let's say it was a work in progress.

As a technical lead interviewing for one of the teams at the leading CAD software company project, I faced a crucial decision. It would teach me the most valuable lesson in technical mentoring: look at the whole person, not just their current technical abilities.

"Are you sure?" the Project Manager asked when I recommended hiring her.

"Her English…" she left the sentence hanging.

"She'll be able to do it," I responded with a conviction that came from seeing beyond the immediate technical evaluation to the whole person sitting in front of the screen: her determination, her problem-solving mindset, and that spark in her eyes that tells you someone is willing to overcome any obstacle.

"The greatest paradox in technical mentoring? The most significant technical growth often happens during conversations that have nothing to do with code."

What follows is a practical guide drawn from real experiences, including the story of how focusing on the whole person, not just the engineer, turned that nervous interviewee into one of our most respected technical leaders. You'll learn:

Why traditional technical mentoring fails when it focuses solely on technical skills
How to build a mentoring framework that nurtures the complete human being behind the code
Practical strategies for developing both technical excellence and personal growth
The crucial understanding that professional success comes from supporting the whole person

Whether you're a seasoned tech lead or aspiring to mentor others, this guide will show you why the most effective technical mentoring happens when we dare to see and support the complete person.

The True Meaning of Technical Mentoring

The greatest mistake in technical mentoring is believing it's just about code reviews and architecture discussions.

Real mentoring begins when we understand that every technical challenge is solved by a complete human being, bringing their whole self to work each day.

During those first months, I supported Yadu in English calls. The team, captivated by her natural charisma, showed extraordinary patience.

But what was most impressive wasn't others' patience. It was her determination.

While she improved her English, her code spoke for itself: cleaner, more efficient, more innovative than the rest of the team's.

Over the next two years, Yadu became my right hand in the project. Her technical excellence, combined with her growing confidence and leadership skills, made her an invaluable asset to the team.

When I promoted her to Tech Lead of our most critical team, her first reaction was still doubt. "Are you sure?" she asked, echoing that initial PM's question, but this time about herself.

The team not only trusted her. They relied on her. Her discipline, thoroughness, and dedication had earned her that position long before the official promotion.

"Trust isn't built in code reviews. It's built in those moments when you choose to see the person behind the pull request."

She just needed to believe in herself as much as others believed in her.

Practical Framework for Technical Mentors

After years of mentoring experiences, here's the practical framework I've developed and used successfully:

1. Building Trust Through Regular Check-ins

"Your calendar reveals your true priorities. A 30-minute mentoring session might seem small, but it can change someone's entire trajectory."

Your calendar is your statement of values. Make time for what truly matters.

The Evolution of Check-ins:

Start with weekly 30-minute sessions
Gradually transition to bi-weekly as they grow
Eventually move to monthly deep-dives
Always remain available for urgent needs

Session Structure:

80% open to whatever is on their mind
20% for technical aspects, but only if needed
No fixed agenda, follow their lead

The Art of Questioning:

Never give direct answers early on
Use questions that spark more questions
Share your decision-making process initially
Gradually shift to pure Socratic dialogue
Let them discover their own solutions

The key is to evolve from mentor-led to mentee-led sessions. Your role transforms from guide to sounding board.

2. Progress Indicators I Look For

Success leaves clues. Here are the signals I watch for:

Technical Growth:

Taking initiative in technical discussions
Proposing solutions instead of just raising problems
Other team members starting to seek their advice

Personal Development:

Increased confidence in communication
Willingness to take on new challenges
Better work-life balance decisions

3. Empowerment Techniques

Growth happens in the space between support and challenge.

The Step-Back Approach:

First phase: be present in all technical discussions
Second phase: let them lead, be there for backup
Third phase: only attend when explicitly requested

Decision-Making Framework:

Help them structure their thinking
Ask guiding questions instead of giving answers
Celebrate when they make decisions independently

4. Creating Growth Opportunities

Real growth happens outside the comfort zone, but not in the panic zone.

Visibility Tasks:

Assign them to present in important meetings
Include them in architectural discussions
Give credit publicly for their contributions

Stretch Projects:

Start with small, low-risk challenges
Gradually increase complexity and visibility
Always provide a safety net, but rarely need to use it

5. Supporting Life-Career Integration

Success at work starts with balance in life.

Flexibility Framework:

Help prioritize personal milestones
Support time-off requests actively
Demonstrate trust in their judgment

Success Metrics:

Focus on value delivered, not hours worked
Celebrate personal achievements as much as professional ones
Look for signs of growing confidence in both spheres

The Whole Person Approach

After more than a year of successfully leading her team, during one of our mentoring sessions, Yadu shared her ambitious plans: a month-long trip to Japan.

As a contractor, getting such a long absence approved is almost impossible. Keeping your project when you return is even rarer.

What touched me most was what she shared upon her return.

Coming from Colombia, where trees maintain their green throughout the year, she was mesmerized by her first experience of autumn in Japan, watching leaves change their colors, something she had never seen before.

"Sometimes growth, like autumn leaves changing colors, reveals beautiful possibilities we didn't even know existed." This wasn't just a trip. It was a metaphor for her own transformation: discovering new perspectives, experiencing changes she hadn't imagined possible. Just as those autumn leaves showed her a new way trees could be, her journey showed her new ways she could grow.

This wasn't just luck. It was the result of more than a year of exceptional leadership and the deep trust she had built with both her team and the client.

She had created something more valuable than code: a reputation for excellence and reliability that made her irreplaceable.

80% of our mentoring sessions weave through the rich tapestry of life beyond code.

"The best technical leaders aren't those who work the longest hours. They're the ones who bring their whole, balanced selves to work each day."

We talk about family dynamics, the adventures of pet cats, moments of self-doubt, and the excitement of moving to a new city.

We celebrate significant life milestones together: getting a driver's license, buying that first car and the newfound freedom it brings.

We discuss personal finances, from investment planning to budgeting for that dream vacation.

The conversations flow naturally from heartbreaks to celebrations, from diet changes to exercise routines, from financial goals to creative pursuits like painting sessions.

We share stories about dancing at parties and planning vacations, always understanding how each aspect of life contributes to our overall growth.

"A breakthrough in code often comes after a conversation about life. Because developers don't solve problems. Whole humans do."

We are integrated beings. The developer who shows up to daily standups is the same person who dances on weekends, paints in the evening, and worries about their cat's latest vet visit.

The person discussing complex algorithms today might be excitedly sharing their first independent drive to work tomorrow.

The true art of technical mentoring lies in understanding that our professional success is intrinsically linked to our personal wellbeing and growth.

It's about recognizing that productivity isn't measured in hours worked, but in the value we create when we bring our whole, balanced selves to work.

Sometimes, the breakthrough in a complex technical problem comes after a conversation about finding joy in a painting class, the energy boost from a new exercise routine, or the confidence gained from mastering a new life skill.

Conclusion

Today, when I see Yadu confidently leading her team, traveling the world, and breaking barriers that once seemed insurmountable, I feel her achievements as my own.

As a mentor, there's no greater satisfaction than seeing your mentees exceed their own expectations.

"The measure of successful mentoring isn't in how much you teach, but in how much they grow beyond what you could teach them."

Technical mentoring isn't about creating miniature versions of yourself. It's about helping others discover and develop their own version of excellence.

Sometimes, all they need is someone to say "They can do it" and truly believe it.

Remember: your role isn't to solve their problems, but to help them develop their own problem-solving framework.

Sometimes this means watching them take a longer path than you would have chosen, and that's perfectly fine.

Have you had similar experiences as a mentor or mentee? How have you handled seemingly insurmountable challenges in your career? Share your stories in the comments.

Originally published on Medium.

The Power of Slow Leadership

daniel llach — Wed, 30 Sep 2026 13:06:08 +0000

When my biggest weakness became our greatest strength

"Take… your… time." My voice wavered during the high-stakes architecture review at Autodesk. Twenty faces stared at their screens, waiting.

That familiar tightness gripped my throat. The same one I'd battled since childhood, now threatening to emerge in front of my entire team.

For years, I'd seen my tendency to pause and carefully form words as a weakness. Each hesitation felt like a failure in leadership.

But that day would prove different. My perceived weakness was about to save our most critical component.

Sometimes what we perceive as our greatest weakness becomes our most powerful strength.

The Morning Everything Changed

The calendar invite arrived with crushing weight: "Emergency Architecture Review: Table Component Performance Issues."

Our most complex component, a data table used across the enterprise platform, was causing significant slowdowns. Despite using a popular open-source library that promised community-backed improvements, something was critically wrong.

Stakeholders were alarmed. Enterprise applications were suffering. Teams were pointing fingers.

The old me would have jumped in with quick fixes: swap the library, add more optimizations, anything to show immediate action.

Instead, my measured response created space for something unexpected.

In the pressure to speak quickly, we often miss the wisdom that comes from slowing down.

When Silence Speaks Louder

"What… if…" I started, each word carefully chosen. "We step back… and review… how the data flows?"

The silence that followed wasn't awkward. It was electric.

In that space:

A junior developer found courage to share how certain columns triggered unnecessary rerenders.
A QA engineer revealed patterns in the performance logs we'd all missed.
A frontend architect spotted memory leaks in our implementation.

The solution wasn't in replacing the library or adding more optimizations. It was in understanding our own implementation deeply.

Leadership presence isn't about filling silence. It's about making silence meaningful.

The Unexpected Discovery

As our teams adopted this slower, more thoughtful communication style, a transformation swept through our meetings:

Developers who rarely spoke began sharing critical insights, QA engineers felt confident challenging assumptions, and technical discussions evolved from rapid-fire debates to thoughtful explorations as team dynamics shifted from competition to collaboration.

What started as my personal challenge had become our collective strength.

The pace of your words sets the pace of your team's thinking.

The Art of Slow Leadership

Three practices transformed our team dynamics:

1. The Power Pause

Count to three before responding
Let silence create anticipation
Allow thoughts to crystallize fully

2. Deliberate Speech

Choose words with intention
Speak at half your usual pace
Let importance resonate

3. Active Waiting

Watch for unspoken concerns
Notice who hasn't spoken
Create space for quiet voices

When you slow down your words, you speed up understanding.

The Real Magic

Watching our collaboration with the library's creators deepen, I noticed one of our newest developers, Sarah, constantly almost speaking in partner meetings, then holding back.

Instead of filling the space, I waited.

One second.

Two seconds.

Three…

"I think…" she started softly, "we might need to rethink how we're integrating their updates."

Her insight led to a streamlined integration process that both teams eventually adopted.

This was the magic of slow leadership spreading through our organization.

Real innovation often lives in the spaces between our words.

A New Way Forward

That moment of slowing down led to something none of us could have predicted.

Instead of just fixing our implementation, the company established a partnership with the library's creators. Our careful analysis had uncovered core issues that affected other enterprise users.

The collaboration grew deeper over time. When we proposed new features or improvements, their internal team would analyze and often incorporate our changes into their core codebase.

What started as a performance crisis transformed into a strategic partnership, all because we took the time to truly understand the problem.

Sometimes slowing down creates opportunities that speed could never discover.

Today, when pressure mounts and stakes rise, I don't fight my natural pace. I embrace it. Because I've learned that thoughtful pauses don't just solve problems. They build bridges.

The Poetry Exercise

The success of our table component collaboration taught me something profound about leadership communication. It wasn't just about speaking slowly. It was about intentionally creating space for understanding.

Now, when training new tech leads, I share a surprising exercise.

"Choose a poem you like," I tell them. "Now read it as slowly as you possibly can."

Without fail, everyone rushes through. Just as I once rushed through technical discussions, the urge to make words flow naturally is too strong.

Then I demonstrate. Taking Chilean Nicanor Parra's short anti-poem about two loaves of bread and average consumption, I stretch each sound to its limit. Every vowel, every consonant becomes its own moment. What could be read in seconds extends to minutes.

The room often fills with awkward laughter at first. But then understanding dawns.

The most delicate messages require the most careful delivery.

"The more crucial your message," I explain, "the more each word matters. The more each word matters, the more time you should take to choose and deliver it."

This exercise reveals a profound truth about technical leadership: in our most important moments, speed is the enemy of precision.

Looking Forward

Next time you feel pressured to rush your words, remember this: the weight of your message should determine its pace.

Try this: pick a simple sentence. Any sentence. Now read it as slowly as you possibly can. Notice your resistance to extreme slowness. That resistance is what we need to overcome in our most crucial leadership moments.

Because in the end, leadership communication isn't about speed. It's about impact.

Share your experiences in the comments: what techniques have you found to slow down your communication when it matters most?

Originally published on Medium.

From Top Developer to Poor Leader: The Myths That Broke Me

daniel llach — Wed, 30 Sep 2026 12:50:44 +0000

Your best developers deserve better than being thrown into the deep end.

"Congratulations, you're our new Tech Lead!"

Those words cost me irreplaceable moments of my daughter's first months.

I'll never get those moments back.

What started as a career advancement became my darkest chapter. It taught me why companies keep destroying their best developers by turning them into poor leaders.

The promotion ended my eleven-year relationship. But the deepest wound was missing those fleeting early moments with my baby.

It was 2019. Peak pandemic uncertainty. Mass layoffs swept the tech industry.

I was working as a Senior Web UI Developer at Globant. We provided contractors to leading businesses worldwide, primarily in the US.

Projects were shutting down left and right. I had a three-month-old daughter at home. When they offered me my first leadership role, I felt trapped.

The catch? Moving from an international client to a local healthcare provider. A step backward to move up.

The Self-Destruction Begins

I confined myself to our small guest room. The furthest corner of the house.

I tried to shield my family from the constant parade of Zoom calls.

No proper desk. No office setup. Just me, my laptop, and mounting anxiety in a space meant for occasional visitors.

Each morning at 8 AM, the meetings began. My self-imposed isolation deepened.

"In trying to protect my family from work disruptions, I ended up disconnecting from them entirely."

I couldn't let my team see my real state. Not my exhaustion. Not my doubts. Not the toll this was taking on me.

I was their leader now.

Each morning, I'd put on a brave face for the camera. Hiding the dark circles under my eyes. Forcing energy into my voice.

In my mind, showing any sign of weakness would undermine my position as their technical guide.

Sometimes my partner would bring food to my room. Her frustration was palpable. Justified.

She managed everything alone. Our baby. The household. Meals.

I sat in endless meetings, falling into the toxic trap of seeing childcare as "her responsibility" while I focused on "important work." Looking back, I'm ashamed of how I perpetuated these harmful gender roles.

"I had convinced myself that being a 'good provider' justified abandoning my responsibilities as an equal parent. I couldn't have been more wrong."

Her resentment grew with each plate delivered. I wasn't contributing to any family responsibilities, hiding behind work excuses that now feel hollow and rooted in outdated stereotypes.

Most days, I'd forget to eat until 6 PM. Then I'd scramble for whatever I could find. Adding more burden to an already overwhelmed household. A household where my partner was shouldering far more than her fair share.

"I was coding through the night to prove I was a good leader, while failing at the most important leadership task: enabling my team."

Sleep became a torturous cycle of guilt and anxiety.

Three hours of restless rest became my new normal. Lying awake. Hearing my partner handle our baby's night feedings alone.

When exhaustion won, my dreams were haunted. Project deadlines mixed with my partner's justified complaints. Our baby's cries echoed through it all.

I existed in a zombie-like state. Paralyzed between two fears: failing at work and failing my family.

Each night brought the same cruel choice. Sleep and feel guilty for not helping with our baby. Or stay awake and risk making critical mistakes at work.

"Fear of unemployment chained me to a path of self-destruction. The irony? I was destroying myself to keep a job I couldn't even enjoy."

The fear of unemployment kept me trapped in this destructive cycle.

My energy vanished completely. I wasn't living anymore. I merely existed in a perpetual survival state.

I kept sinking deeper into a destructive spiral.

This experience drove me away from leadership positions for almost two years.

The impact was devastating. But time brought understanding.

It wasn't the role itself that destroyed me. It was the toxic combination of leadership myths I had internalized.

"Sometimes you need to hit rock bottom to clearly see the myths that are drowning you."

The Leadership Myths That Destroyed Me

Every morning, these toxic thoughts echoed in my mind:

"I must perform perfectly, or they'll evaluate me poorly"

"I need to have all the answers, or I'll look incompetent"

"If I show weakness, they'll take advantage of me"

"If I compromise on any point, it'll show my judgment isn't valid"

These thoughts became self-fulfilling prophecies:

1. "A Leader Must Do Everything Themselves"

Coding until 3 AM instead of delegating
Making decisions alone out of fear
Building a team based on recommendations, not competence
Accepting former teammates who had a big tech gap
Coding their tickets in secret for the first sprints
Committing directly to their branches when progress felt slow
Taking over tasks instead of mentoring through challenges

2. "Leaders Must Know All The Answers"

Frantically studying every technology stack
Making rushed decisions based on quick searches
Imposing views even in areas I barely understood
Being afraid to say "I don't know"
Interviewing for roles without expert support
Lowering the technical bar out of desperation

3. "Leadership Means Total Availability"

Accepting meetings from dawn till dusk
Responding to every message instantly
Putting work above basic needs
Ignoring my family's needs
Taking on other people's responsibilities
Covering up team limitations instead of addressing them

4. "Showing Uncertainty Undermines Authority"

Hiding my exhaustion in video calls
Pretending to have everything under control
Never admitting when overwhelmed
Isolating myself to maintain an image
Accepting recommended candidates without proper interviews
Making hiring decisions alone to avoid exposing my knowledge gaps
Micromanaging every aspect of development
Obsessing over every line of code my team wrote

"My fear of appearing incompetent led to a self-fulfilling prophecy: building a team that needed constant rescuing."

The Escape

Surprisingly, from the outside, the project was going well.

But inside, I was crumbling.

By the fifth month, a stark realization hit me: if I continued like this, I wouldn't live to see my daughter grow up.

This wasn't an exaggeration. It was a moment of brutal clarity.

I wanted my daughter to have a living father more than I wanted to be a "successful" leader.

Quietly, I started searching through my company's talent pool. Not for another leadership role. I looked specifically for Senior Web UI Developer positions in US projects.

I needed calm. I needed peace. I needed to breathe.

Then came the news that felt like a lifeline: an opening at Autodesk. The perfect escape route.

My leaders understood when I spoke about the move. The Autodesk project carried enough weight to make the transition possible.

After a brief handover period, I could finally breathe again.

The damage to my relationship was already done. The traumatic repercussions would stay with me for years.

But I was alive. I could be present for my daughter again.

A Different Approach to Leadership

Today, I personally ensure potential tech leads receive proper training before promotion.

I work with our outstanding developers long before they step into leadership roles.

Why? Because I never want anyone to experience what I did.

Our best developers deserve real promotions. Transitions to leadership should feel like growth, not torture.

"Lead with calm. It's not just a motto, it's a promise to every developer stepping into leadership."

Key Leadership Lessons

Warning Signs of Toxic Leadership:

Working nights to complete your team's tasks
Feeling you must know everything
Hiding exhaustion in meetings
Sacrificing basic needs for "availability"
Using work to escape family responsibilities
Perpetuating harmful gender roles through work "priorities"

Growth Indicators of Healthy Leadership:

Delegating work confidently
Admitting when you don't know
Setting clear boundaries
Prioritizing your wellbeing
Maintaining work-life balance
Being an equal partner at home and a leader at work

Remember:

Technical excellence doesn't equal leadership readiness
Leadership is a skill that requires its own learning path
Your health and family are non-negotiable metrics
Leading calmly is more effective than leading heroically
No career advancement justifies neglecting your role as an equal parent
True leadership starts with breaking harmful traditional patterns

A Call to Action

To future tech leads: if you're feeling overwhelmed by a recent promotion, remember: it doesn't have to be a trial by fire.

You don't need to sacrifice your health, relationships, or peace of mind to be an effective leader.

Reach out. Let's discuss how you can transition while maintaining your balance and sanity.

To companies and tech leaders: your best developers deserve better than being thrown into the deep end.

I help organizations build sustainable leadership transition programs. We can prioritize both technical excellence and human wellbeing.

Together, we can create a path to leadership that doesn't require burning out your brightest talents.

Don't let another developer go through what I did.

Let's transform tech leadership into what it should be: a calm, supported journey of growth.

Ready to explore a different approach to tech leadership?

Connect with me to discuss how we can prepare your future leaders to thrive, not just survive.

Originally published on Medium.

LEGO Lessons in React: When My 5-Year-Old Made Me Rethink Component Design

daniel llach — Sun, 01 Dec 2024 23:48:16 +0000

Remember that feeling of opening a new LEGO set as a kid? The excitement, the clear instructions, the satisfaction of pieces clicking together perfectly. Now remember your last code review of a "flexible" enterprise component. Not quite the same feeling, is it?

After years of watching developers (including myself) struggle with over-engineered solutions, I've learned that the best React architectures have more in common with LEGO than with the complex machinery we sometimes try to build.

The LEGO Principle: Simple Pieces, Infinite Possibilities

What My 5-Year-Old Daughter Taught Me About API Design

Last weekend, I watched my daughter play with her LEGO set. "Today we're building a dog park!" she announced excitedly. Without any documentation or "senior LEGO architect" guidance, she proceeded to create slides, sandboxes, a water area, feeding stations, and play zones for dogs. The next day? "Let's make cars!" And just like that, the entire dog park transformed into a fleet of vehicles.

This hit me hard. Here was my 5-year-old intuitively understanding something we often overcomplicate in software development: with the right building blocks, you can create anything, transform everything, and rebuild without fear. Each LEGO piece had one clear purpose, connected in obvious ways, and worked reliably every time.

Meanwhile, back at work, we had a "flexible" component that looked like this:

// The "enterprise-ready, flexible" approach
const EnterpriseDataComponent = ({ 
  data,
  configurationMatrix,
  transformationPipeline,
  errorBoundaryStrategy,
  optimizationHeuristics,
  // ... 20 more intimidating props
}) => {
  useEffect(() => {
    // 100 lines of setup logic
  }, [/* dependency array longer than my coffee order */]);

  return (
    // JSX that would make a senior dev cry
  );
};

Something was very wrong with our approach.

The LEGO Master Builder's Guide to React

1. Start with Perfect Bricks

// A basic LEGO brick - it does one thing perfectly
const Button = ({ onClick, children }) => (
  <button 
    onClick={onClick}
    className={styles.button}
  >
    {children}
  </button>
);

// A slightly more specialized brick
const ConfirmButton = (props) => (
  <Button 
    {...props}
    className={styles.confirm}
  />
);

2. Build Bigger Things from Simple Pieces

// Combining bricks into something useful
const ConfirmationDialog = () => {
  const { confirm, cancel } = useDialog();

  return (
    <Dialog>
      <DialogTitle>Are you sure?</DialogTitle>
      <DialogActions>
        <ConfirmButton onClick={confirm}>Yes</ConfirmButton>
        <Button onClick={cancel}>No</Button>
      </DialogActions>
    </Dialog>
  );
};

3. Hide the Complex Machinery

// The complex machinery is there, but hidden
const useDialog = (options = {}) => {
  // Level 1: The Happy Path (90% of developers only need this)
  const simplePath = {
    confirm: () => handleConfirm(),
    cancel: () => handleCancel()
  };

  // Level 2: Extended Features (9% of cases)
  if (options.advanced) {
    return {
      ...simplePath,
      onBeforeConfirm: handlePreConfirm,
      onAfterCancel: handlePostCancel
    };
  }

  // Level 3: Escape Hatch (1% of power users)
  if (options._superPowers) {
    return {
      ...simplePath,
      _internal: internalAPIs,
      _context: dialogContext
    };
  }

  return simplePath;
};

The Design System: Your Master Builder Kit

Think of your design system not as a collection of components, but as a LEGO Master Builder Kit. Each piece should be:

Instantly Recognizable

// Anyone can understand this
const Card = ({ title, children }) => (
  <div className={styles.card}>
    {title && <h2>{title}</h2>}
    {children}
  </div>
);

Predictably Connectable

// Pieces that work together naturally
const ProductCard = ({ product }) => (
  <Card>
    <CardImage src={product.image} />
    <CardContent>
      <ProductDetails product={product} />
    </CardContent>
    <CardActions>
      <AddToCartButton product={product} />
    </CardActions>
  </Card>
);

Safely Extensible

// Senior devs can add features without breaking simplicity
const withAnalytics = (WrappedComponent) => {
  return function EnhancedComponent(props) {
    useAnalytics(props.analyticsEvent);
    return <WrappedComponent {...props} />;
  };
};

// Still simple to use
const TrackableButton = withAnalytics(Button);

The Security Advantage: Fewer Entry Points, Better Control

When you build with well-defined "LEGO bricks", security becomes more manageable:

// One secure implementation, used everywhere
const SecureButton = ({ onClick, children }) => {
  const { validatePermissions } = useAuth();

  const handleClick = () => {
    if (validatePermissions()) {
      onClick();
    }
  };

  return <Button onClick={handleClick}>{children}</Button>;
};

// Developers can't accidentally bypass security
const DeleteButton = () => (
  <SecureButton 
    permission="delete:items"
    onClick={handleDelete}
  >
    Delete
  </SecureButton>
);

The Unexpected Benefits

After implementing these principles, we discovered some surprising benefits:

Junior developers became productive faster
- "It just makes sense" was a common feedback
- Less time reading docs, more time building
Senior developers found it easier to optimize
- Clear boundaries made performance improvements isolated
- Easier to implement advanced features without affecting basic usage
Code reviews became discussions about business logic
- Instead of "Why is this so complex?"
- We got "This is exactly what we needed"
Documentation practically wrote itself
- When your APIs are intuitive, you need less documentation
- What documentation you do write is focused on advanced use cases

The Master Builder's Wisdom

Remember:

If your components need a PhD to understand, you're doing it wrong
Complex features should be opt-in, not opt-out
The best code is the code you don't have to explain
Build for the many, extend for the few

Looking Forward

The future of React development isn't about who can build the most complex system. It's about who can make complex systems feel simple. Just like LEGO has been doing for generations.

Next time you're designing a component or system, ask yourself: "Could a 5-year-old understand how these pieces fit together?" (Okay, maybe not the code itself, but the mental model should be that clear.)

How do you keep your React components simple yet powerful? Share your LEGO-wisdom in the comments below!

How to Scale a Team from 6 to 25: Building Down to Move Up

daniel llach — Mon, 25 Nov 2024 00:45:24 +0000

Traditional career growth often feels like climbing a ladder — always reaching for the next rung up. But what I learned while scaling an Autodesk team taught me something different: sometimes, the best way to grow is to build downward, creating opportunities for others to rise.

Here’s how I transformed a 6-person development team into a thriving organization of 25 professionals across three specialized units, and the unexpected lessons about leadership it taught me.

What started as a team of four developers, one project manager, and myself as Tech Lead grew organically to 10–12 people during the first year, as we established our processes and culture. However, the real challenge emerged when we needed to scale rapidly: new projects demanded we nearly double our size, pushing me to rethink our entire structure and approach to leadership.

The Pivot: Breaking Down to Scale Up

With this rapid growth ahead of us, I proposed splitting the team into three specialized units, each with its own leader.

The restructuring plan was based on technological specialization:

React Base Project Team:

Focused on core React architecture
Handled foundational components and features
Maintained core project stability

Web Components Project Team:

Specialized in web component development
Created reusable, framework-agnostic components
Ensured cross-platform compatibility

Design Team:

Contribute to the design system team:
Ensured UI/UX consistency
Bridged the gap between design and implementation

This technical division wasn’t arbitrary — it aligned with Autodesk’s architectural vision and allowed each team to develop deep expertise in their domain while maintaining clear interfaces between teams.

The Key Innovation: Rather than maintaining direct control, I would:

Promote two developers to Tech Lead positions, each specializing in their respective technical domains
Elevate a UX designer to lead the design team
Position myself as a leader of leaders, ensuring architectural consistency across all three areas

Implementation: The Leadership Matrix

The new structure worked like this:

Benefits of this approach:

Created clear growth paths for team members
Reduced communication overhead
Enabled specialized focus for each team
Allowed for faster decision-making
Provided leadership development opportunities

Reality Check: When Growth Comes Knocking

While I’ve presented this scaling journey in a structured way, I should be honest: much of this happened faster than ideal. The reality of being a contractor means sometimes having to move at the speed of business rather than the speed of perfect planning.

Our big scaling moment came unexpectedly during a visit to Autodesk’s Portland offices. The news of a major project would require adding eight team members, while our existing projects needed five more developers and UX designers. This meant we would nearly double our size, going from 12 to 25 people. I had to present my team-splitting strategy the very next day. Fortunately, both the Autodesk manager and director loved the idea, and my Globant leadership supported it as well.

Did it work? Yes. Could it have been smoother with more preparation time? Absolutely. While we succeeded, I would have loved more time to train the new leaders before throwing them into their roles.

Learning Through Challenges

New Leaders’ Journey

Not everything was smooth sailing. One of our biggest challenges came from an unexpected place: my assumption that new leaders would naturally adopt my leadership style. I learned that leadership transition requires explicit knowledge transfer — not just about processes, but about leadership philosophy and approach.

Key Learnings from This:

Leadership styles need to be actively taught, not just demonstrated
Internal leadership processes need clear documentation
New leaders need space to develop their own style while maintaining team consistency

Words of Wisdom for Future Leaders

After this journey, here’s what I wish someone had told me at the start:

The Urgency Trap: Don’t let the daily urgent tasks prevent you from working on important, non-urgent matters. It’s tempting to focus solely on putting out fires, but that’s a recipe for perpetual reactiveness. Block time for:

Strategic planning
Team development
Process improvement
Identifying growth opportunities

Remember: If you’re too busy fighting fires, you’ll miss the chances to fireproof your house.

Investment in People: The time you spend developing your team members isn’t a cost — it’s an investment that pays dividends in:

Team loyalty
Improved performance
Reduced stress
More opportunities for everyone

Looking Forward

Now, as I begin my new role at Hilton account, I’m taking a different approach. Armed with these experiences, I’m investing time in the “Important but Not Urgent” quadrant from day one:

Identifying potential leaders early
Building scalable processes before we need them
Creating training programs proactively
Establishing clear growth paths ahead of time

The experience taught me that scaling a team isn’t just about managing more people — it’s about creating systems that allow others to grow. By building down, you create a foundation that allows everyone, including yourself, to rise higher.

What’s your experience with scaling teams? Have you found traditional hierarchical growth limiting? Share your thoughts in the comments below.

Photo by Nandhu Kumar on Unsplash

[About the Author: A Subject Matter Expert with 12+ years in IT, currently leading technical initiatives at Hilton and mentoring tech leads. Previously led teams at Autodesk and other major enterprises.]