From Founding Engineer to Tech Lead: Growing a Team and a Product in LatAm
Disclaimer: The software described in this article is the intellectual property of Soy Más de las Américas. The purpose of this essay is to share my personal growth alongside the product’s development — not to disclose proprietary technical details.
The Empty Office
There’s a specific kind of freedom that comes with being the only engineer in a startup.
In the early days, the co-founders would leave the office for days at a time — pitching to the first believers, chasing the first checks, telling the story of what we were building. And I’d be there alone, with a blank editor and complete creative liberty.
Those were the days of pure imagination. How could this product serve its demographic better? How could we integrate AI tools to make them accessible to users who had never interacted with anything like this? There were no stakeholders to align, no sprint ceremonies, no pull request reviews. Just a builder and a problem.
I’ll always remember that phase with deep affection. Not because it was easy, but because it was mine.
The First Feedback
Then the beta testers arrived, and everything changed.
Feedback has a way of humbling your assumptions. Features I thought were intuitive confused people. Flows I considered elegant felt clunky. The gap between what I imagined and what users experienced was the first real lesson: the product isn’t what you build — it’s what they use.
It quickly became clear that my engineering-first prototypes needed something I couldn’t provide alone: real design. Not “developer CSS” — actual visual communication that could carry the founders’ brand vision. The kind of work that makes a user trust a product before they’ve even clicked anything.
Building the Team
The first hire was a designer. That single addition transformed the product more than any refactor I’d ever done.
Then came the engineers. I had the fortune of bringing in people I trusted — engineers I’d worked with before, people whose judgment I respected. We also collaborated closely with leads from other internal teams, which taught me how different groups within the same company can have wildly different working cultures.
Watching that team grow was one of the most rewarding experiences of my career. Not because of what we shipped (though we shipped a lot), but because I got to witness my colleagues’ own empowerment — moments where a junior engineer who’d been hesitant in standups started proposing architecture changes with confidence, or where an intern presented their work to the whole company for the first time.
The Transition
My day-to-day shifted completely.
Before: Write code. Imagine the product. Ship.
After: Review pull requests. Document the codebase so new engineers could onboard. Have long conversations about architecture, scalability, and long-term technical strategy.
That last part surprised me the most. I didn’t know I needed to learn how to debate architecture. When you’re a solo builder, your technical decisions are monologues. When you lead a team, they become dialogues — and sometimes disagreements.
Different engineers brought different perspectives. Sometimes they challenged patterns I’d used for years. And here’s the uncomfortable truth: they were sometimes right.
The Tool Paradox
One of the subtler lessons: you can’t always use your favorite tools.
When it’s just you, your stack is whatever you’re fastest with. When you lead a team, the stack has to match the team’s skill set. It’s easier to adapt your tools to your people than to adapt your people to your tools.
I learned this the hard way — advocating for a technology I loved, only to realize that the onboarding cost for the rest of the team would delay us by weeks. The “inferior” choice that everyone already knew was the superior choice for shipping.
Letting Go of the Code
The hardest part of the transition wasn’t learning to lead. It was learning to release.
My best engineer didn’t write code like me. We’d get into detailed conversations about specific patterns — I’d have an approach I was convinced would work, and he’d have a different one. Sometimes we’d go back and forth, each making our case.
What I eventually learned: trusting an engineer doesn’t mean agreeing with them. It means giving them your honest pushback, listening to their honest pushback, and then — when they can articulate that they understand your concern but still believe in their approach — empowering them with that decision.
That was the moment I went from “lead who codes” to “lead who grows engineers.” It’s a fundamentally different job. And it’s harder. And it matters more.
The Interns
A brief note on mentoring interns, because it deserves its own space.
The best things I taught them had nothing to do with code:
- How to think about problems before reaching for solutions.
- How to present your work to a team — not just the what, but the why.
- How to ask questions that aren’t “how do I do X?” but “what should I be considering when deciding between X and Y?”
Watching someone develop that meta-skill — the ability to think about their own thinking — was more satisfying than any deployment.
The Hardest Part: Leaving
At some point, it was time to move on.
I don’t want to romanticize it. Leaving a team you built — people you hired, mentored, debated with, celebrated with — is genuinely painful. There’s a specific kind of grief in stepping away from something that still has your fingerprints all over the codebase.
But the product reached 100,000+ users. The team was strong enough to carry it forward without me. And the relationships survived the departure — to this day, those colleagues are close friends.
That might be the best measure of whether you led well: not whether the code was clean, but whether the people still call you after you leave.
What I Carry Forward
- Creative freedom is a privilege, not a right. Enjoy the solo phase. It doesn’t last.
- Your team’s tools > your favorite tools. Ship with what the team knows.
- Debates about architecture are not threats — they’re the job. If nobody disagrees with you, nobody’s thinking.
- Empowerment is letting someone make a decision you wouldn’t make. And being okay with it.
- The hardest part is always leaving. Build something worth missing.
Diego Jiménez Vergara — AI Infrastructure & DevOps Engineer. Former Founding Engineer & Tech Lead at Soy+.