The language of respect: Yes, and…

“If this is so obvious, why do I face so much opposition?” A colleague of mine asked me why, to someone with experience in open source work, it is obvious that a company would try to leverage the value and mitigate the risks of open source. Yet many organizations seem to pose barriers to implementing the very processes that would benefit them.

People have different propensities to change beliefs and implement new processes. Many years ago when I was first exposed to open source, I did not see it as something that could be favorable to my company (I have since changed my feelings on this matter). My views at the time were shared by many of my colleagues. Eventually, I came to understand that my view was not completely mistaken, but it was flawed and wrong. I missed seeing a larger picture. Moreover, I had a stake in the current processes. I was exposed to other organizations and a range of sentiments toward open source; some organizations were biased to see the inherent value in open source, others skeptical. Thus my friend was really asking: How does one change a bias?

During Thanksgiving this year, I had three thoughts that I wanted to string together into a message that may be worth sharing and might help that colleague. 

1. I was thinking of the good people I get to work with. I remembered someone who would always build on ideas with a "yes, and…" even in places that might have invited a "no, but…" disagreement response. At first, I thought she was being a bit trite with her signature "yes, and…" responses. Then I realized it was a powerful expression of respect. She taught me a lesson. At the heart of her response was an element of disagreement. Responding to supplement, complement, or even supplant a point one can bring the other person along, or can set the other person in opposition to a point you wish to make. "Yes, and…" is a gesture to indicate acknowledgment and seek to build upon. 
2. In a contrasting thought, I remembered how much I can’t stand the popular clickbait and often shared articles that effectively tell you "you are doing it wrong" when it comes to something mundane (you tie your shoes the wrong way, you are eating sushi wrong, shower at night not morning, etc.). The smug "you are doing it wrong" article bothers me. Is it that the author feels superior? No, they might be right. There is a more effective way to tie a shoe, a traditional way to consume sushi, and a better showering process. It bothers me that the author encourages readers to convey that sense of superiority when sharing the article. Learning new things could be a process of mutual discovery; it could be a "yes, and…" conversation.
3. There is a lesson to an OSPO leader when contrasting a respectful tone versus a judgemental tone. Leaders in an organization may perceive the open source experts and consultant to be saying "you are doing it wrong." If so, the message may be resisted. Organizational behavior is a result of deeply ingrained and monetarily rewarded processes. Few people will be excited to hear they "are doing it wrong" especially when they are paid to do things as they do them now. The novelist Upton Sinclair once said, "It is difficult to get a man to understand something when his salary depends on his not understanding it."

I was introduced to the agile software methodologies at about the same time as I learned about open source (the concepts differ, but have a certain element of similarity being novel ways of rethinking controls). The agile practitioner at work told us that by using the waterfall method to plan our software releases, we were "doing it wrong." He met resistance. Not that he was wrong, but that people were having a difficult time seeing things his way. 

Another practitioner helped explain why agile was superior. The waterfall method evolved from previous methods such as PERT and Gantt. Those work breakdown methods were developed by civil engineers and operations research experts working for the US Navy, Army, and government construction projects. They were optimized to expose critical path (risk), dependency, time, and cost issues of complex projects. They worked well when both the goal state and the specific steps to achieve the goal were fairly well understood. They didn't work as well where projects had a lot of uncertainty. They worked when the army core of engineers needs to build a bridge or set up a field hospital. But what about creating software? Not so well.

Software engineers often quip "On time, within budget, to specification; you can only pick two." Customers were lucky to get two and never got all three. But why is that? A carpenter can tell me how long it takes to build a deck in the backyard, providing a fixed price for time and materials. A factory worker can tell me how long it takes to assemble a car, and exactly what will be in it. Why can't software engineers provide the same level of process reliability? The practitioner explained that an increasing amount of our software projects are creative work, not assembly work. You want a predictable process to configure a new corporate laptop, to apply an image onto a provisioned virtual server, or to construct another micro-site based on a template. Creativity in those areas can introduce error and inconsistency. But many of our software engineering tasks are becoming more like creative work -- solving new problems. Those projects require a different way to identify risks, costs, dependencies. Yes, predictable processes can use traditional tools. New types of projects need newer tools better suited for their levels of uncertainty. (Admittedly, agile is more, but that's not my point here.)

Suddenly the "you are doing it wrong" message that we were hearing from the first agile professional made sense. The waterfall process we had was fine for a category of work, but we were doing a different kind of work. The second practitioner explained agile using the "Yes, and..." tone. Yes, waterfall exists because some projects are well managed that way. We're shifting our work to more creative types of projects. We need new processes to help us with the shift.

For the OSPO leader: you know that open source processes will be beneficial to the company. But the people who are paid to run the current processes may not have the mindset to understand why this is the case. They're not wrong. They might not be seeing the shifts that lend themselves to new processes; where open source can help. Try conveying the message: "Yes, the processes we have today are ideal for the software we used to manage and for some of the software we will still manage. There's a new type of software work we're beginning to do more; work that requires an approach better suited to leveraging and managing it." I do not believe these conversations will always be easy. But I do believe that if it comes from a place of understanding and respect, it will be better received.