Photo by Alex Holyoake on Unsplash

A gamble 20 years ago unleashed the source code for the browser that became Firefox. The approach is now core to Facebook, Google and everyone else. … “For so long the mindset was ‘protect the code, protect the code, protect the code,'” said Chris Tino, director of engineering at Ghostery, a privacy-focused browser extension maker that just released its software as open source. “Now it’s almost to the point where if you’re not open source, there’s a little bit of a shadow cast over you.” cnet.com, March 29, 2018, Mozilla’s radical open-source move helped rewrite rules of tech

I faced a similar dilemma. What I wanted to do would be going against the tradition, culture, and even rules of the organization. Why would I do this? Because it seemed obvious to me that what we had been doing, what was embedded in the organization as the way to do business, was not only not working but looked pretty silly to an outsider.

My classic example was the daily detailed defect review of our product. It turned out to provide very little added value to our product development. When we dispensed with such reviews, the product’s progress continued on just fine with equal or increased quality, and numerous people had significant time freed up for them to do more value-added activities.

See defects are your best friend for what we did instead.

Another significant change was when I trusted my programmers to get the job done, rather than micromanaging their every activity. I had been told that they were not very experienced and needed close supervision, and that is exactly what previous supervisors had done. While I still coached and encouraged them and listened to them when they wanted to talk through issues, I otherwise didn’t check their work, nor even had another person check their work. We not only delivered on time but were a month early, where no other similar project had even been on time. Micromanaging had held the team back rather than helping them to do better.

In a final example, we had been trying to improve the organization’s software development process for years by implementing a particular methodology. No matter how much we demanded and cajoled that things be done differently, very few teams made any real progress in adopting this new methodology. So, instead of continuing to edict what they had to do, we decided to just provide a service to let them know the difference between what they were doing now and the new methodology. We would simply interview each team and then show them how close (or how far) they were from the target methodology. In nine months, all but one team had made the switch. This was after over three years of the “do it now” approach that management was sure was the only way to get the change implemented.

Sometimes an effective method to achieve what we want to achieve is practically the opposite of what we are currently doing. This will almost always appear counter-intuitive, especially to those who have lived through the previous attempts. The insight to do the complete opposite usually comes from examining objective data (e.g., defect trends) or by spending time talking to the people we are wanting to change (e.g., development teams about methodologies).

Have you considered approaches to your project that are effectively opposite to the expected and conventional approaches?