The Visual Basic Joke That Taught Me About Earning Engineers' Trust

Three months into my first project management role at a software company, I watched a colleague destroy his credibility in thirty seconds. The engineering team was discussing a legacy system bug, and someone cracked a joke about Visual Basic. My fellow PM laughed loudly and nodded knowingly, clearly trying to signal that he was technically savvy enough to get it. The problem was obvious to everyone in the room: he had no idea what they were talking about. The engineers exchanged glances, and I could practically see his authority evaporate.

That moment crystallized something I'd been sensing for weeks. Walking into a team of skeptical engineers as a new project manager feels like entering a room where everyone speaks a different language and you're holding a phrase book upside down. These developers had been burned before by PMs who talked a big game but delivered bureaucracy instead of value. Some had been working without any project management oversight and genuinely questioned whether my role would help or hinder their work.

I learned that earning their trust required a completely different approach than I'd expected. Instead of jumping in to immediately demonstrate value, I spent my first two weeks mostly listening. I sat in on their daily standups, observed how they communicated about blockers, and paid attention to their natural workflows. The urge to start organizing and optimizing was strong, but I forced myself to understand their rhythm first.

When I finally began suggesting changes, I made sure every single one removed friction rather than adding it. Instead of introducing new status reporting processes, I streamlined the existing ones. Rather than scheduling additional alignment meetings, I made their current meetings more focused and productive. Each intervention had to pass a simple test: does this make their work easier or harder?

I also committed to never pretending I understood something when I didn't. When technical discussions went over my head, I asked clarifying questions or simply listened without comment. Over time, I picked up their terminology naturally and could participate more meaningfully in their conversations. The difference between this organic learning and my colleague's forced familiarity was night and day.

Protecting their time became sacred to me. Every meeting I scheduled had a clear agenda and defined outcomes. If I couldn't articulate exactly why each person needed to be there, I canceled it or reduced the attendee list. When stakeholders requested updates that would require developer time, I found ways to provide that information myself rather than pulling engineers away from their work.

Most importantly, I never took credit for improvements that started showing up. When deployment cycles got smoother or cross-team communication improved, I let those wins speak for themselves. The engineers gradually began mentioning how helpful certain processes had become, but these observations came from them, not from me announcing my successes.

By month six, something had shifted. The same developers who initially questioned my presence were actively including me in technical discussions and asking for my input on workflow challenges. They started defending the value of project management to other teams, which was worth more than any performance review.

The lesson goes deeper than just relationship building. Engineers respect competence and authenticity above everything else. They can spot performative leadership from across the room, and they have long memories for PMs who promise the moon but deliver red tape. But they also recognize and appreciate someone who genuinely makes their professional lives better.

Building trust with a skeptical technical team isn't about proving you belong there immediately. It's about demonstrating through consistent actions that you understand their world well enough to improve it without breaking what already works.