The Efficiency Paradox: What I Learned From Scaling (and Leaving) the Open Source Community
In the world of software engineering, we are taught to optimize. We look for the Big O notation, we refute redundancy, and we automate the mundane.
For the past year, I applied that exact engineering mindset to a role that is usually drowning in subjective ambiguity: Human Resources.
As the Head of HR for the Open Source Community (OSC), I treated the department not as a social club, but as a system architecture project. The results were quantifiable, record-breaking, and undeniable.
But as I learned the hard way, in some organizations, "optimization" is interpreted as "disruption." Here is the story of how I built a high-velocity machine in a low-velocity environment, and why we ultimately parted ways.
Phase 1: The Build (Quantifying Success)
When I took over as Head of HR in October 2024, the goal was simple: Scale. The reality, however, was a logistical nightmare. We needed to process hundreds of applicants with a volunteer team that was used to doing things "the way they’ve always been done."
I didn’t want to just manage people; I wanted to build a pipeline. I implemented a strict, data-driven operational framework. We moved away from ad-hoc decisions and authored a comprehensive "Rules of Engagement" sheet—establishing clear guidelines for disciplinary actions, rewards, and KPIs.
The numbers speak for themselves. In my first recruitment cycle:
- We increased total interviews from 127 to 248 (a nearly 100% increase in throughput).
- We successfully onboarded 164 candidates.
- I personally conducted 37 interviews while managing the macro-operations.
We weren't just hiring; we were upskilling. I led weekly mentorship sessions covering everything from KPI development to data manipulation. I wanted my team to be operators, not just paper-pushers.
Phase 2: The Engineer in the Room
Here is where the friction began. I am, at my core, a software engineering student.
In a traditional corporate structure, HR stays in HR. But in an open-source community, if there is a bug, you fix it. When our Tech Committee stalled on a critical project, I didn't schedule a meeting to discuss why it wasn't done. I didn't form a sub-committee. I wrote the script. I pulled an all-nighter, built the automation tool, and deployed it.
I thought this was "taking initiative." The leadership viewed it as "breaking the chain of command."
There was a fundamental disconnect between Output and Optics. I focused on results: Is the script running? Is the recruitment data organized? Are the candidates happy? The organization focused on the noise: Are you active on Discord? Did you tag everyone? Did you follow the bureaucratic ritual?
I was playing Factorio; they were playing The Sims.
The Exit: Velocity vs. Stability
Ultimately, my tenure ended. The leadership and I realized we were incompatible.
They wanted a Head of HR who would maintain the status quo, engage in the "performative work" of constant communication, and respect the hierarchy. I was a Head of HR who wanted to ship features, automate workflows, and optimize runtimes.
The irony? The most efficient process in the history of the organization was my removal. For a group that took weeks to approve a project, they managed to revoke my access in under four minutes. I respect that speed. I just wish they applied it to the projects.
The Lesson
I’m walking away from OSC with my head high. I built a team of 17 incredible people. We broke recruitment records. We proved that HR can be run with the precision of a backend system.
But I learned a valuable lesson about Culture Fit: You can be the fastest engine in the world, but if you put that engine in a tractor, you’re going to tear the chassis apart.
I am not looking for a tractor. I am looking for a race car. I am taking my experience—the recruitment scaling, the operational design, and yes, the ability to troubleshoot Linux while running an event—to a place that values velocity over visibility, and that place is MSP
On to the next challenge.