Throughout my career, I've watched ego become one of the biggest bottlenecks in engineering teams. More often than not, it wasn't technical ability that slowed projects down, but strong convictions, tightly held ideas, and an unwillingness to leave room for others to contribute.

I always believed I was avoiding that trap. I made a conscious effort to bring others along by writing design documents, gathering feedback, running architecture workshops, and pairing with teammates to shape the systems we were building.

It took years of experience, a fair share of failures, and—most importantly—a great team to help me realize that, despite my best intentions, I had become a different kind of bottleneck. I wasn't blocking people through toxicity or arrogance—I was blocking them by always leading the way.

Shaping a System

When I joined the Payments team at MoonPay, the foundations of a great payments platform were already being built. Like any engineer joining an established team, I brought my own ideas, challenged existing approaches, and gradually became one of the people helping shape its evolution. Over the years, I developed strong convictions about what a great payments orchestration platform could become, and every project or refactor felt like another opportunity to move us closer to that vision.

As my role in those discussions grew, so did my influence. More and more architectural conversations naturally gravitated toward me. I proposed designs, answered questions, and tried to provide context wherever I could. My intention was always to enable others, but I failed to notice that I was too eager to provide my perspective before anyone else had formed theirs. Over time, I unintentionally became the default source of architectural direction. Collaboration was happening—but there was less room than I realized for others to shape the vision themselves.

The turning point

As the team grew, it became impossible for me to be involved in every architectural decision. At first, I struggled with that, but it forced something much better to happen. Engineers stepped up, proposed their own designs, challenged long-held assumptions, and took ownership of parts of the platform I would have naturally led.

The result wasn't a diluted vision—it was a better one.

That's when I realized the biggest bottleneck in our architecture wasn't our technology. It was my inability to let go.

I had spent years trying to scale the platform. I hadn't realized I also needed to scale ownership.

Learning to Let Go

Accepting that wasn't easy. As engineers, we naturally become attached to our designs. We spend weeks thinking through trade-offs, edge cases, and abstractions, so it's tempting to believe that the closer the final system is to our original vision, the better it will be. But great platforms don't belong to one engineer—they belong to the team building them. Accepting that the platform would never look exactly as I had imagined wasn't a compromise. It was progress.

Over the following months, I deliberately started stepping back. I resisted the urge to answer first, stayed silent during some design discussions, and intentionally let others take ownership of initiatives I could have easily led. Every time I created that space, someone stepped into it. The platform became stronger every single time.

Lessons Learned

The biggest realization for me was that silence creates space. I always thought I was helping discussions move forward by answering first or filling awkward pauses. In reality, I was unintentionally anchoring the conversation around my own thinking before others had a chance to form theirs. Once I started speaking less and listening more, participation changed dramatically. Engineers challenged assumptions, proposed ideas I would never have considered, and ownership spread naturally across the team.

The second lesson was that architecture is a team sport. Great systems may begin with a strong vision, but they only become great when many people are empowered to shape them. Inviting others into the design process doesn't weaken the architecture—it strengthens it by exposing blind spots, encouraging diverse perspectives, and creating genuine ownership. As an unexpected side effect, sharing that responsibility also gave me more time to write production code again, keeping me close to the implementation and the day-to-day challenges engineers face.

Above all, I learned that leadership isn't about having the best ideas—it's about creating an environment where the best ideas can emerge, regardless of who they come from. If every meeting ends with your solution, your team never gets the opportunity to develop their own. The best leaders don't build teams that depend on them; they build teams that no longer need them. Ironically, the more invisible your leadership becomes, the more successful you've probably been.