Welcoming Dumb Ideas

11 Apr 2024

0 interest is an interest level

I just stumbled upon a viral-ish X post where most of the commenters made fun of Grant Cardone, a known “grifter” in a lot of people’s eyes: Grant Cardone has an IQ of 42 and is worth $600 million. What is holding you back?

A comical thesis he proposed was that “0 interest, is an interest level”. Which I don’t recommend you try unless you want HR to randomly Zoom you.

When you have a perception of a person, it’s hard to not have a certain preconceived bias. Instead of taking it face value I thought about it a bit more. Is there any possible nugget of wisdom or something we can learn here? While you may not need to agree 100%, you should be aware of these biases that might potentially shoot down ideas pre-emptively.

After some more thought, I believe what he was trying to say is when you want to sell something to someone who has 0 interest level, it’s not the end of the world. The “0 interest level” is a litmus or calibration point to effectively tell you where you stand in this person’s mind.

In software engineering, we are constantly exchanging ideas back and forth and trying to build consensus. Believe it or not, one does not simply read How to Win Friends and Influence People and become an expert in soft skills as repeatedly pitched by managers around the world.

My personal problem with the book is some what summarized from another Reddit user:

However, after 80 years in the field, its techniques have been vastly surpassed by later developments in human psychology and influence. I’m in a role where I have to deal with dozens of salesmen hitting me up every week. If I see a Dale Carnegie technique (‘complementing’, ‘using my name’, ‘talking in terms of my interests’) I know I’m dealing with someone very new in a sales role.

Although the principles I will highlight later make them quite evident, I find that they need more concrete ways of applications as a day to day software developer.

Something I experienced in my last company was the idea of Test Driven Development or Testing culture in general. Principal engineers would vouch for the bugs saved or the cost savings from re-work. Being able to be agile and move fast while having regression safety net. On the flip side there are cultures that do not embrace testing as it slows them down, etc. Regardless to say, testing was mandated, but how effective was it exactly? Thats not the topic of this post in particular, but the semination of ideas into your organization.

Building organizational consensus for effectuating change:

Build the why:

Listing benefits that people already know isn’t going to necessarily help in my experience. Non technical people prefer ROI/Cost savings, data helps. Listening and solving their major pain points from their point of view helps. If you are just simply trying to practice resume driven development or over optimize/refactor a piece of your code base with no convincable benefits, you are probably going to get shot down. Avoid Shiny Object Syndrome for the sake of shiny.

Principle 1: Fundamental Techniques in Handling People. By listening to their ideas and solving their major pain points, you’re showing genuine interest in their perspective and fostering a positive relationship.

On a random side note on Clean Code. I highly recommend this very informative debate between Bob Martin and Casey M: https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md It’s a very good case study of two programmers coming from two different backgrounds on why they believe in their philosophies.

Provide Education and Training for Ease of adoptability:

Offer training on the importance, methodologies, and best practices. Empowering team members with knowledge helps them embrace the change confidently. To introduce a new process or idea, it must be low barrier or small investment for users to adopt. If it’s something completely ridiculous and creates more work it’s obviously a no.

Having an “escape hatch” or a backup plan can provide reassurance and mitigate the fear of failure when implementing changes in a company. It allows for a safety net in case the change doesn’t yield the expected results or faces unforeseen challenges. This backup plan can include alternative strategies, contingency measures, or even a way to revert to previous processes if necessary.

Principle 2: Six Ways to Make People Like You. By offering training on the importance, methodologies, and best practices, you’re demonstrating genuine interest in their development and success. Empowering team members with knowledge helps them embrace the change confidently and builds trust and rapport.

Involve your team early:

I think a more effective approach is talking to your co-workers one by one, and listening to their ideas. You can then achieve better overall buy-in now that everyone is on board. If you can then sell why your new idea or approach is saving them from a pain point(or for non technical people, make $), you are going to better be able to get consensus. Include team members in decision-making from the start, seeking their input and concerns. This fosters ownership and commitment to the change.

Principle 3: How to Win People to Your Way of Thinking. By including team members in decision-making from the start and seeking their input and concerns, you’re showing respect for their opinions and making them feel valued. Additionally, your emphasis on selling the benefits of your ideas by addressing their pain points ties into the principle of appealing to the other person’s interests.

Conclusion

Sometimes dumb ideas can have benefits that you never thought. It’s more of a matter of building the proper consensus with your team. Tying back into the idea that a company culture that embraces psychological safety will have a lot more potential for innovation compared to ideas simply mandated from an ivory tower. If all else fails just become the CEO of your own company 😂