Don't Go Into Business Of Convincing People

People hate it when someone tries to convince them

I think I operate on a somewhat different level than most people I know. Ever since I can remember, I was always getting easily excited about novel things, something I did not know. I was always very curious. Yes, I was aware that there are well established ways of doing something, but I was always curious to see if there are better ways we haven’t thought of yet.

It is that propensity for looking into innovative ways of doing things that has determined by career path. I started my career doing scientific research (worked as a research assistant in the numerical ecology department), but after realizing how stifling scientific community tends to be, I decided to shift gears and move into a more dynamic, less regimented field. So, I chose software development.

Little did I know that software development profession is also staffed with people who are averse to change. Most software developers I’ve worked with figured out how to do their job, and once they settled into that role, they were reluctant to ever consider changing anything.

I, on the other hand, found immense joy in experimenting and learning about different, sometimes seemingly crazy ways of doing software development. Once I discovered concepts such as Extreme Programming (XP), Test Driven Development (TDD), Functional Programming (FP), Pair Programming, Mob Programming, Agile Manifesto, etc., I wanted to shout from the rooftops about those amazing practices.

Which is why about 15 years ago I started moving more and more into the coaching/teaching role. My first teaching gig was 24 years ago, when I got hired by several local colleges to teach courses in software development. But those course were hardened into curricula that was quite obsolete. Dissatisfied with the rigid academic agendas, I decided to strike on my own and started leading, coaching, and teaching software development teams. I wanted to share my excitement about those newfangled practices.

I was young and naive. I was convinced that my contagious enthusiasm for those novel things in our profession will instantly rub off on others. But alas, that was not to be. I had many people complaining about my approach, looking for ways to get rid of me. Some even went as far as to claim that I have invented all those things (TDD, XP, whathaveyou) simply just to torment them.

Disappointed, I at first thought that the failure is down to my inability to clearly articulate those ideas. I tried changing my approach. I started publishing series of articles in various tech publication, hoping that it would lend a bit of gravitas to my ways of teaching.

None of the expected results materialized. People just did not like what they were hearing. They did not like what I was telling them.

Then, at one recent point in my trajectory, I crossed paths with a person who is running his own consultancy. He listened to my value proposal, and interrupted me midway, asking: “May I explain to you how we are doing it?”

“Sure, please”, I responded. And once I heard about their approach, I suddenly realized the error of my ways. And the error is as follows: I was trying to go into the “people convincing business”. I was trying to reach out and soften my audience, to gently point out that there are better ways of working. I was doing my best to convince them that there are better ways, better practices.

Of course, that approach was doomed to fail from the outset. Why was it doomed? Because no one likes to be told how the way they are doing their job is the incorrect way. In other words, it is false math, false economy to expect that people will agree that after doing something for years, their approach is wrong.

Trying to convince them that they are incorrect in how they do things is never going to fly. It is for that reason that I’d advise young and upcoming experts to abandon that approach when they attempt to convince people to do something they are not familiar with.

So, is there an alternative, or is our profession destined to forever be stuck in the current crude, defects-prone way of delivering software?

There may be a viable alternative. Only if the proposed changes get first sold to the top executive suite, do we stand a chance of seeing some changes propagate down to the software development teams. Without the endorsement and sponsorship from the executive team, chances are slim to none that anything will ever change in the way software developers are going about delivering software.