Gonzalo Rodriguez Pardo

The short version

My background runs across product, business analysis, business development, negotiation, communication and engineering, as well as data, which turns out to be unusually good preparation for this work: most of a data job is understanding what somebody else's system was built to do before asking it for something it was never designed to give.

On paper it is a degree in Information Systems Engineering, closed with a 9.23 average, a number I mention only because I worked hard for it. In practice the useful part was never the syllabus. It was the professors, the future colleagues, and the habit of defending a design in front of people whose job was to find the one assumption I had not checked, which is roughly every meeting I have had since.

Where the curiosity comes from

Every child gets handed a wheel that is connected to nothing. Most of them are happy with the noise. Judging by the photograph, I was busy looking for the linkage, and I never quite stopped. Every system I have worked on since has been the same question in better clothes: what is this attached to, what moves when I turn it, and how would anyone know if nothing did.

Numbers showed up soon after, and they showed up as a competition. Taking first place in a national accounting olympiad taught me something no syllabus did: a number is worth exactly as much as the reasoning somebody can defend around it, and the person who knows where it came from tends to win the room. Two decades of technology later, that is still most of the job.

How the keys were learned

Each of the seven came from paying for it. Co-founding a venture with colleagues, and building products in it where a mistake is permanent and public, taught the value of correctness and of decisions you cannot cheaply undo, which is most of what architecture is. Owning something end to end also teaches how quickly a shortcut taken for speed becomes the constraint everything else has to work around. Sitting between business definitions and technical priorities taught that the hard part of analytics is agreeing what a word means before computing anything with it.

Writing the systems that produce data, before ever consuming them, is where foundations stopped being an abstraction. It is a very different experience to overwrite a column knowing that somebody downstream will one day need the value you just destroyed. Then the move into data made the rest concrete: pipelines that have to run without being nursed, models whose targets are business metrics, and reporting that people actually steer by, which is when evaluation stops being optional.

What gets built on weekends

A recurring group of us keeps building things in focused bursts of a couple of hours. The pattern is always the same: pick something that used to be too expensive to justify, and check whether it still is.

The one that came straight out of daily annoyance was agentic triage for failed pipelines. When an orchestration job fails, somebody has to stop, read logs, find the root cause and propose a fix. So we wired the orchestrator to hand the failure context to an agent, so that an engineer starts from a diagnosis and a reviewable draft fix rather than from raw logs. Part of it went back upstream as a contribution to the open source project.

Others in the same spirit: a multi agent generator that turns study material into flashcards, split into one agent that routes, one that structures, one that generates and one that answers follow up questions. A retrieval agent that answers strictly from your own documents. A conversational interface over a lakehouse that turns a question into a query and the result into an analysis, which is the semantic layer argument made tangible. An assistant that detects purchase intent in a conversation and alerts the commercial team.

Leading a team day to day does not mean losing the ability to go down to the trenches. Building alongside people who are very good at this is what keeps the leadership half honest: estimates stay grounded, standards stay concrete, and the conversation with engineers happens in the language they actually work in.

Teaching

Every year a group of fifth year engineering students discovers, usually all in the same week, that a brilliant system nobody will fund is a hobby. I teach on the subject where that happens: business plans, cash flow, investment appraisal, and a closing round where teams defend a full plan and its numbers in front of simulated investors.

It is the least technical thing I do and probably the most useful. Nobody in that room cares how elegant the design is until someone explains what it returns and when, which is exactly the conversation a data platform has to win with a board. Teaching it twice a year makes it very hard to forget.

How I work

Three habits, learned the expensive way. Look one layer below the question, because a broken metric is rarely a broken query and is usually a schema that never recorded what somebody now needs. Count cost in engineering hours rather than only in invoices, because a team whose week goes into keeping things alive has nothing left to build with.

And write the expectation down before deciding, then go back to it afterwards. An organisation that evaluates honestly learns something from every decision it takes, including the ones that did not work.

Beyond data

I take part in advertising productions whenever the chance appears. It is deliberate practice rather than a hobby: everything in an ad is built around the message it carries, and being on the other side of that makes you far more careful about what you are actually communicating. Learning tends to happen outside the comfortable part.

During my youth I volunteered on the fundraising side of a social organisation, talking to companies and securing donations. Different vocabulary, same underlying job as most of my work since, which is getting people who do not share a language to agree on something concrete.

I do not believe in translations. Words carry the culture and the history of the language they grew up in, and moving them across borders quietly leaves most of that behind. Something subtler goes missing too. People open up when they are spoken to in their own tongue, and they are able to feel your message, instead of just understanding it. That is what pushed me to full professional proficiency in Spanish and English, and to start on Japanese and Russian.

The full professional record is on LinkedIn and the code is on GitHub, both linked at the top of this page, and both better places to start a conversation than a contact form.