Experience
From software engineer
to engineering leader.
My responsibilities have expanded from writing software to leading teams, managers, and engineering organizations. This timeline shows the roles and company transitions behind that progression.
Career timeline
-
2024 — present
Head of Engineering
I lead engineering across all of Make's projects and the company-wide adoption of AI in software delivery. My work combines research, practical playbooks, internal tooling, and direct support for teams.
-
2014 — 2024
Software Engineer → Head of Engineering
Citrusbyte · Theorem · TheoremOne · Formula.Monks · Monks
This was one ten-year chapter at the same company, through several name changes and the 2022 integration with Monks. I moved from hands-on engineering to leading engineering organizations: roughly 90 engineers before the integration and approximately 350 people afterward.
Alongside client engineering, I built and managed the internal IT function, hired its team, and held responsibility for security before transitioning the function to the COO.
-
2022 — 2024
Head of Engineering
As Head of Engineering, I led an organization of roughly 90 engineers before TheoremOne joined Monks; it reached approximately 350 people after the integration, working through directors and engineering managers. Together with the leadership team, we established structured engineering career paths, a hiring process designed to preserve a high quality bar at scale, security and IT policies, and practical playbooks for engineering and engineering leadership. My responsibilities also included internal IT and security alongside client work.
-
2020 — 2022
Director of Engineering
I led multiple engineering managers and expanded my responsibility beyond Apple as the client portfolio grew. Part of that work was developing new engineering leaders who could take ownership of additional accounts.
-
2017 — 2020
Engineering Manager
As the work with Apple expanded, I handed the original project to another engineer and became responsible for engineers across the wider Apple portfolio. I coached and hired engineers and managers, represented Engineering with technical stakeholders, and helped establish the company's engineering-leadership practices.
-
2014 — 2017
Software Engineer
I joined Citrusbyte on an AT&T engagement, working mainly on a Ruby backend distributed across three AWS availability zones, with a large Elasticsearch cluster and extensive Redis use. I played a leading role in performance work that enabled 15,000 requests per minute in each zone, while also contributing to infrastructure and operations. I later moved to Apple, shipping a working prototype in two weeks and the first production version in two months.
-
-
2014
Software Developer
I briefly worked as a consultant modernizing a Ruby on Rails application before joining Citrusbyte.
-
2012 — 2014
Lead Engineer
Breaktime
I led a small cross-functional product team spanning engineering, design, and psychology, while contributing to analysis and implementation.
-
2008 — 2014
IT Consultant
I built software and handled infrastructure, networks, support, and technology consulting for local clients.
-
2007
Professor
ISIPE · Universidad Siglo 21
I taught Java and software development in two programs: one prepared students for internships, and the other trained incoming engineers in Java EE.
The through line
Lessons I carry forward.
I got into teaching because it was the best way I had found to keep learning: explaining something forced me to understand it more deeply. My early roles also combined development, consulting, infrastructure, and product work.
Breaktime taught me an early product lesson. We spent too long refining the product before putting an MVP in front of real users, then invested in marketing before knowing whether people would use it. I now prefer to release the smallest useful version and learn from actual use.
An operating principle
Keep the system understandable.
As my scope grew from software into teams and organizations, I kept returning to the same principle: reduce unnecessary moving parts, make responsibilities and decisions visible, and help people build an accurate mental model of the system they are working in.
-
01
In software
Simple software comes from choosing dependencies deliberately, keeping attention on the product’s core purpose, and separating responsibilities clearly. Tests should cover meaningful risks and return feedback quickly.
-
02
In the development process
Simple delivery keeps routine decisions in shared channels, where the people affected can find the context and contribute. It also means fewer meetings, each with a specific purpose. Traditionally, focus time protected one uninterrupted thread long enough to reach deep concentration. AI changes that model: work can proceed in parallel, but every stream adds context to supervise, review, and integrate. The challenge is to gain parallelism while maintaining a clear view of the whole.
-
03
In organizations
Information that needs to last should have an authoritative home, especially documentation. Small teams can share context, make decisions directly, and keep coordination proportional to the work.
The goal is to make systems genuinely simpler and easier to understand: people should be able to anticipate how they will behave and know where to act when something needs to change.