👋 Hi folks

I’m Iván (he/him), pronounced ee-bahn.

I’m an Engineering Leader from Asturias, in the north of Spain, with over 15 years of experience building product software at the intersection of engineering, product, and people. More and more of that time now goes into building the teams that build it.

Over the years, I’ve learned that building software is rarely just about implementation. The real work is often in shaping ideas early, defining scope, making trade-offs explicit, and building systems that can evolve without becoming harder to understand. I care about useful software, maintainable systems, and teams that can do meaningful work without burning out.

It all started at a small R&D company in Gijón, turning half-formed ideas into something people could actually use: online reputation analysis, gamification platforms, early intelligent assistants. Backend became home after that. First Ruby on Rails, then Elixir, where I helped take an HR platform from an empty repository to a real product with a team of eight around it.

Still, I’ve always followed the problem wherever it went — frontend, platform, mobile, delivery, product shaping. Not because I wanted to collect skills, but because I care about the full path from idea to production. That instinct hasn’t changed much. It just has more places to go these days.

What fills my days

My day job is 0→1 product engineering: shaping ideas before they harden, slicing scope, and building end to end with Product sitting right next to me rather than three handoffs away. It’s the kind of role where I’m most useful, contributing beyond implementation and helping turn ambiguity into clear, sustainable execution.

Outside of it, I’m building Avenida with a former colleague, a 0→1 product in the intentional shopping space. The idea is simple: a calmer way to save, organize, and come back to products from any online store, instead of losing them in forty open tabs. It keeps me close to product thinking, fast iteration, and the reality of building with limited time and real constraints.

It’s also where I push hardest on AI-native product development. Not to generate code faster, but to improve the whole lifecycle: ideation, product definition, technical proposals, scope slicing, implementation, testing, and delivery. Speed alone has never been the interesting part. Clarity is.

And then there’s my Engineering Leadership Playbook, built around the things I wish someone had handed me the week I started leading: better operating rhythms, clearer ways to support people, and healthier ways to lead in remote-first teams. It’s less a manifesto than an operating system.

That week, by the way, is worth explaining.

Why the team became the work

The real turn came at Lingokids, when I was promoted to lead a small team of three engineers. Part of me expected it to be a detour from the “real” work.

It wasn’t a detour. More like the part of the job I hadn’t known I was missing. For the first time, my impact showed up somewhere other than my own pull requests — in someone getting unblocked an afternoon earlier, in a 1:1 that changed how a person saw their next step and, more slowly, in a team that started trusting its own judgment more than mine.

Honestly, it felt like a revelation. And it rearranged what I wanted from my career.

Since then, leading distributed teams at Factorial and at Remote, the job I care about most is being a multiplier, not the strongest individual contributor in the room. Team dynamics, unblocking, facilitating, the slow and unglamorous work of supporting engineers along their career path: that’s the part I’d choose every time.

My focus moved from “how do we implement this?” to “how do we build in a way that stays healthy?” Architecture and engineering strategy still matter a lot to me, just not as diagrams. They’re a way to protect focus, clarity, and momentum. It’s also why the next step I’m building towards is engineering management.

A lot of what I learned along the way ended up written down.

Why I write

I write because some of the hardest parts of our work never appear in the backlog.

Technology is the visible layer. Underneath it sits the human one: attention, confidence, motivation, conflict, ambiguity, the pressure to always be “on,” and the slow accumulation of emotional debt. That’s usually where things start to break.

You can have smart people, good intentions, and strong technical execution, and still end up with a team that feels reactive, exhausted, or disconnected. So a big theme here is how to build software without losing yourself in the process: delivery, team health, sustainable pace, and what changes now that AI keeps speeding up how fast work moves.

I’m especially interested in teams that want to move fast without becoming brittle. Whenever I can, I turn the idea into something you could use on Monday. A template, a checklist, a prompt, a script for a hard conversation, a ritual that stops confusion from compounding.

Mentoring and community

Writing reaches people I’ll probably never meet. Mentoring is the opposite, and it started long before it had a line on my CV.

Back at that first job in Gijón, one of the people I worked with took what they later called their “first real steps into Ruby on Rails and web development” with me. They work in Product now.

These days most of my mentoring happens through MentorCruise, helping engineers grow in backend development, system design, leadership, and career clarity. Sometimes that also means what one mentee called “the rollercoaster of job interviews.” The same review credits our sessions with “breaking down all my misconceptions and guiding me to focus on what truly matters,” and that rollercoaster ended in a better offer. Hard to ask for more than that.

Community has been the other half of it, mostly here in Asturias:

• FabadaConf, a one-day, single-track software conference in Gijón that I co-founded. And yes, there was fabada.

• Elixir Asturias, the local community I also co-founded, with meetups and hands-on workshops for anyone curious about Elixir and Phoenix.

• Awesome Mental Health and Awesome Diversity, two open collections of resources I maintain.

For me, mentoring, inclusion, mental health, and healthy engineering cultures were never side topics. They’re part of what good engineering actually looks like.

Away from the keyboard

Outside of work, I’m usually playing guitar, taking photos, or leaving a conference or meetup with a few ideas that genuinely change how I build.

If any of this resonates, whether it’s a role, a collaboration, a mentoring session, or just a conversation, I’d love to hear from you.