About
Carlos Hernández is an engineer working where product, technology, teams, and the people who build them meet.
I’ve spent almost my entire adult life building things.
For a long time, that meant writing software.
I started out as a developer, and I still think of myself as one. I like stepping into a problem I don’t understand, taking it apart, figuring out how it works, and ending up having built something that did not exist before.
But over the years, the scale of those problems began to change.
It was no longer only about building a system that could handle more traffic, but about helping twenty people work on it without getting in each other’s way. Not only about shipping faster, but understanding what was stopping the team from doing so. Not only about the architecture we needed, but about the responsibilities, processes and structure that had to exist around it.
At some point, I stopped working only on software and started working on the human systems that build it, too.
I’m still an engineer. What I consider a system has simply grown considerably.
Over the last few years, I led an engineering group of around 25 people, supporting another 400, and responsible for a platform serving tens of thousands of websites and millions of visits every week.
The technical scale was interesting. The human scale, much more so.
My work became about designing teams, defining responsibilities and reporting lines, hiring, mentoring, and creating processes that helped people make better decisions without turning into bureaucracy.
It also meant creating enough context for other people to work autonomously. Recognising when a problem needed a technical decision and when it needed a conversation. Knowing when to step in and, perhaps harder, when to get out of the way.
Over time, I’ve found that leadership and architecture have something in common: both are about designing systems in which the parts can work well without depending on you all the time.
It does not always work out.
But that is probably one of the things that has changed how I understand work the most.
I’ve moved much closer to the code again.
After spending the last few years moving ever closer to a leadership role, my next step has been to return to a Product Engineer role.
Not because leadership stopped being interesting to me.
But to get closer again to the product, the code, and the small decisions that, given enough time, end up becoming large systems.
And to do it with everything I learned from the other side.
Having led teams changes the way I write software. I better understand the organisational cost of a technical decision, the importance of creating context, and why some abstractions help a team while others only make the code more elegant.
And continuing to build software also changes how I understand leadership.
I’m not particularly interested in choosing one side over the other.
I’m interested in the space between product, technology and people.
I’ve taken a few paths to get here.
I’ve built my own products and products for other companies. I’ve worked with startups in different countries, in small teams and much larger organisations.
I founded several projects and a studio, Commit Sans, where we built products used by more than 100,000 people. I spent several years getting to know startups (and founders) in more than seven countries, helping them solve all sorts of problems. I served quite a few million pages a day for two years. I taught software development to more than 20,000 people and built a community of thousands of developers.
A lot of numbers. All very fancy.
I have also built platforms from scratch, inherited systems that had been growing for years, and worked on products where a bad decision stops being small rather quickly. The hard kind of legacy.
I’ve written code, designed architectures, hired, fired, mentored, defined processes, built teams, and had conversations far more difficult than any technical problem I’ve come across.
Some things went very well.
Others taught me considerably more.
I’m not especially interested in turning all this into a timeline. If you are looking for titles, companies and dates, there is LinkedIn ↗.
What matters to me about having worked in such different places is being able to look at the same problems from different perspectives.
Problems amuse me.
Especially the ones that do not belong neatly to a single discipline.
The ones that seem technical until you realise they are organisational.
The ones that seem like product problems until you find an architectural constraint.
The ones that seem like one person’s problem until you realise you have built a system that pushes everyone to behave that way.
And the ones that arrive perfectly defined until you ask two questions.
That is where I’m most at home.
I’m not particularly attached to a technology, a methodology, or one specific way of doing things. I am quite attached to understanding why we do them.
Sometimes, the answer ends up being software.
Other times, it does not.
Some of those ideas end up on a stage.
I’ve been teaching and speaking for many years. Over time, I’ve become less interested in explaining tools and more interested in the difficult decisions that come up when you build real products, systems and teams.
The ones without a clean answer.
The ones we usually learn only after getting them wrong a few times.
When I close the editor.
I like motorbikes, photography, making music, writing, cooking for far too many people, and learning things with an intensity wildly disproportionate to their usefulness.
I also like beer a great deal.
Some of those things end up in a newsletter I write in Spanish. Fortunately, others never get published anywhere.