The real magic of discussion is when we discard the things we have interpreted and embrace what someone else can explain from their unique experience. The analogy I like to use here is that the truth is one big puzzle and we each may have different pieces of it.
As more and more people join a situation it is likely they may have extended their factual puzzle pieces with interpretations. Discarding these interpretations for facts that other people have is a valuable yet painful process. I don't think anyone is ever really motivated by something untrue, which makes most disagreements just misunderstandings.
I'd like to tell a story about my greatest career accomplishment, born from the worst criticism I've ever received. I call it the "ten things I hate about you" letter or "complaint" letter for short. This was a document sent to a principal engineer from a sister-team to the team I was on. My role was to build a new front-end system that would generate a front-end interface from configuration files that were served by a backend service. When the system launched successfully it was adopted by our sister team to complete a similar feature they were launching.
The complaint letter was ten things they hated about using the system... A system I was the sole author of at that time.
This is the story of how the situation turned around to the most memorable and highest achievement of my career for me. It was four months of relation-ship building and I'll never forget the satisfaction of seeing motivation return to my team, and our sister-team, as the whole group began writing tickets, opening pull-requests and making the system work well for everyone.
For background, I was at a company that had a front-end project slow and then almost completely stall. This was a team of about 4-6 mostly front-end engineers (including me). After the technical lead left a few months in, we had 2 other technical leads take up the mantle and then each leave the company, all in a span of two months. When a staff engineer took a look at the code by my invitation, he concluded that I should build a competing prototype of a more dynamic configuration-driven solution to the same application.
I spent a week or so making a prototype, and then was requested to replace the entire system with the remaining two and a half months of a nine month timeline. The catch was it was requested that I build this alone, given the lack of faith in the rest of the team's approach and the promise of my prototype. The intention of the prototype was to drive every page from a configuration GUI and so I based everything on complex JSON structures that were never intended to be authored by humans. This made my project, as a single engineer, very efficient and was the only option I could find to meet the deadline with the full feature-set.
This is not the story of how I built the system, other than to say, there were definitely corners I cut knowingly. The most challenging part about maintaining this system was not about what it did, but about what it didn't do. So much of the interfaces were generated by loops and configuration parameters that it was hard to grasp where things were coming from. The system was a critical part of a services rewrite that had three or four teams worth of innovation behind it, so the urgency to deliver was what attracted my focus. The first of more than one layoff rounds had already happened and I knew it was important to have a publicly visible win for the company.
"This looks like a front-end system written by a back-end developer" was one such item off of the complaint list. Which was interesting, because most of my roles at that point had been mostly front-end, though my coding style spanned a diverse set of techniques. My role quickly shifted from developer to team-dynamics fire brigade. I began holding meetings with members of the front-end community of the company and we slowly got to repair the bridge between the core-engine that I had built, and the methodology they preferred to use to fulfil how they modified the user-interface.
The turning point happened about four months after launch. A very talented engineer, we'll refer to him as "Sam", was advised to bring me into a zoom meeting because I had assisted their colleagues with the system before. He explained to me with great concern the situation he was in. This is a summary of my recollection of our conversation.
Sam:I don't think this component will do what I need it to.
Me: I know,
I wrote that component, and know it won't do what you just described.
Sam: Oh... well... what should I do?
Me: You can probably write a better one, or a different one.
Sam:Oh...
Me:Yeah, I've seen your work before, you could totally write an alternate that does exactly what you've explained to me. I can show you how to conenct it.
Within a very short period of time after this conversation, I want to say less than one day. I saw the pull-request he had written and it was brilliant. About 15 lines long and did exactly what he explained it needed to. I endorsed it heavily on our chat program. And that was the beginning of the turnaround, that pull-request was cited by several other enthusiastic engineers including several authors of the complaint letter from four months earlier.
When I received an award at the company, it was several members of that team, who were the authors of the complaint letter that were the most congratulatory on the chat channels. I had shown them how much I cared about their success, and they had become a stronger and more decorated team because of it, what they also knew was that my line manager had requested I put my energy only into my own team, and that may have made my efforts to help them even more valued.
This is the magic I was referring to at the beginning of the article about people seeing a different slice of the truth. What I knew as the engineer I had been was how to efficiently deliver a system within a very fixed time-frame. What the interaction engineers knew was the type of bridge they needed between the engine I had created and the design system components they had authored.
I think a lot about what happened across that year and a half that the project was running, a few things stand out, but what is firm in my mind is that inspiring team-members when they feel like they've been shut out of the process is the most inspiring and rewarding thing I've ever done.
I also learned that working alone is never a good thing, even if you have the tools to meet the objectives you can see, you don't have the visibility to know the objectives you're missing. Those are probably the puzzle pieces of the truth that other people have. And it's really nice to have team-members that can help you discard the interpretations that are from your own bias.