As a software developer, there’s an intrinsic desire to be right. It comes with the territory of a craft that is perceived as being black and white. But beyond the precision required to write a program that compiles, the path to building successful software is far from clearly defined.
I’ve been reading Staff Engineer: Leadership Beyond the Management Track by Will Larson, which highlights eight “keys to success” for operating effectively as a technical leader. There’s lots to unpack, but one topic that stuck out to me is learning to never be wrong.
At first the intent wasn’t clear. Keep quiet, never risking the chance of being wrong? Only share when certain I’m “right”, forcing my peers into submission until everyone “agrees” that I’m right? Neither feel like an effective use time.
Will expands on the topic further.
Shift away from being right and towards understanding and communication. Stop spending your social capital repairing relationships frayed by conflict, and learn to collaborate with folks with different priorities and perspectives.
The intent isn’t so much that we should never be wrong, but rather that our efforts to drive toward a solution should come from a place of trying to find the best possible solution. You can present a solution that is objectively “wrong”, but if you’re able to pivot towards a solution that works for all parties, that’s what counts. As soon as you walk into a room with the intention of convincing others that you’re right, you’ve set yourself (and your team) up for failure.
Software developers are expected to deliver value, but delivering value isn’t a zero-sum game. True value delivery happens when a team is aligned, and members are willing to compromise on their ideas. Sometimes the best contribution you can make is to put your idea on hold, ask questions, and work towards a solution that works for everyone.