Low diatribe

I didn't know I was looking for the thrum until I found it.

On my first day as Principal Engineer at Music Startup, I was given my repo credentials and a directive to extend the ordering platform and sent off on my merry way. At the time it felt like a natural extension of the autonomy I'd worked so hard to achieve and it never occurred to me that it might be too much to ask of me without additional support. I felt instantly in over my head, but I tried to remind myself that as the new head of engineering I could handle it. I handled it, but the struggle left a sour taste.

At EdTech Startup, it began the same way. The CTO handed me the codebase, but then something different happened. He added that he would be happy to walk me through it and answer any questions. It felt like a trap. I politely declined, thinking that he expected me to be experienced enough to handle it. I took that codebase like the big ball of tangled holiday lights it was and charged into the untangling with hubris at the helm. I felt the hot flush of embarrassment when I hit the first knot I had no idea how to unravel. It rose to a fever when I thought about admitting I actually needed the readily offered help, but I pushed through the awkwardness and asked for it anyway. Without blame or ego, the CTO and I worked through my confusion together, and for the first time I felt safe enough to ask for help when I needed it.

When it came time to add a quality engineer to our team, the CTO asked me, "Do you want to do the hiring? Or should I take care of it?" For two decades I had pursued a technical path. I was a computer guy, I led technical teams and technical projects, but the thought of being a people manager was way outside my comfort zone, and I told him so. "I'm terrified by the concept, so I think I should do it." With enough of his support to feel safe making my own mistakes, I hired someone amazing who set the bar for quality. Hiring track record so far, 1 for 1.

Then came my second hire, the first engineer. I was on a quest to find the most senior, most rock-star ninja we could afford. I found someone who seemed like a perfect fit until he didn't. Looking back, he was so much like I had been in that first Principal Engineer role. I assumed that because we shared that background, he would embrace the same attitudes toward change that I was developing. I was wrong.

I tried to carry forward the collaboration and trust the CTO and I had built. He politely declined, just as I had done. I ended up repeating the cycle and handing him that same ball of lights, perhaps a little smaller and slightly less tangled. He never asked for the help I offered.

He came with strong opinions and operated at maximum volume, always broadcasting, never tuning in. He didn't adapt. He kept doing what he did best, and when he hit his unravelable knot, he just patched around it. We closed tickets quickly, but during code review he would default to "Look, it currently works... if you really want I can go back and do it right, but with the deadline coming up..."

Then we hit a production edge case that exposed the fragility of his implementation. We had to revert all his changes. He jumped ship relatively quickly, leaving behind a mountain of tech debt and the realization that I'd been hiring for the wrong frequency.

When I hired to replace him, I changed what I was listening for. Instead of looking for the loudest signal, I looked for someone who could find clarity in complexity. I was determined not to hire for volume again. When I found her, I could see the difference immediately. Instead of sending her off to work alone, I made sure we built trust from the start. During our first three months together, we systematically reimagined and rebuilt every practice I'd used up until then. She had this way of cutting through technical noise to ask the essential question: "What are we actually trying to solve?" Her questions didn't add complexity. They revealed what was already there, waiting to be seen.

That's when I recognized the thrum. It wasn't about being quiet and hoping someone hears your signal. It was about operating at the frequency where signal travels cleanest.

Working with her taught me to recognize when someone was cutting through noise versus adding to it. "This approach creates more problems than it solves" carried more weight than lengthy technical justifications. I started tuning for the signal that distilled complexity rather than amplified it. The thrum carries essence, not decoration.

I learned to notice when conversations were happening in the wrong medium. Complex architectural decisions needed face to face conversations, not scattered Slack threads. Some signals need different carriers to travel cleanly. I started matching the channel to the clarity needed.

Instead of defending existing approaches, we would quietly untangle small sections of lights and let the results speak. We focused on solving the problems, not on making existing solutions better. Each piece we rebuilt created its own clear signal, and gradually the whole system began to illuminate properly. I discovered that the thrum isn't declared. It's recognized by others when the signal consistently carries something worth receiving.

What I discovered through these experiences is that the thrum creates its own path. When that engineer and I rebuilt those systems, we weren't trying to be heard above the noise. We were operating beneath it. The results spoke before we did. People started coming to us with their hardest problems because they recognized something reliable in how we approached complexity.

The CTO at EdTech Startup had been operating at this frequency all along. His offer to walk me through the codebase wasn't a test of my competence. It was an invitation to tune into something clearer. He never needed to broadcast his expertise because his consistent presence carried its own authority. The thrum threads the signal through the static not by fighting the noise, but by creating a different kind of transmission altogether.

I still didn't know I was looking for it when I found it. But now I recognize it when I hear it in others. That quiet authority that cuts through confusion. That consistent presence that carries meaning without amplification. The frequency where signal travels cleanest, where trust builds naturally, where the work itself becomes the strongest argument for the approach that created it.