Driving Technical Change – Page 2

On Manipulation

My book, Driving Technical Change, is about trying to get your coworkers, your teammates, and your management to accept new tools and techniques. It involves politics, persuasion, and an organized campaign to win hearts and minds.

On several occasions I’ve gotten comments both positive and negative about the contents of the book or my talks being “manipulation.”

One could mean manipulation as “getting someone to do something”, which is not that bad. Using that definition we could say:

My doctor manipulated me to quit smoking
That salesman manipulated me into going with the cheaper option
My spouse manipulated me into eating healthier

Unfortunately, “manipulation” has some baggage as a word. We would never use it in those ways. Rather we would say:

My doctor convinced me to quit smoking
That salesman steered me into going with the cheaper option
My spouse encouraged me into eating healthier

Right? Because manipulation doesn’t just mean “getting someone to do something.” It usually means “getting someone to do something either using dishonest means, or with sinister outcomes.” Either you get someone to do the right thing through trickery, or you get them to do something that is positive for you more than it is for them.

Therefore, I feel I have to equivocally state Thou shalt not manipulate.

Tricking people might work in the short term. It might even win your game for you. But it never works out long term. You’re going to be with your team for awhile. You’re investing in long term advantages for you and them (You know, whatever you are trying to get them to uptake.) Therefore anything that will leave your team feeling used and abused is not in your best interest.

I talk about this a bit in Chapter 17 Creating Trust, which you can download for free from the Pragmatic Bookshelf.

Black Friday Deal for Pragmatic Bookshelf

There’s a one day sale going on at Pragmatic Bookshelf:

Everything will be available for 40% off Friday November 26th *

That everything includes my book, Driving Technical Change.

So stock up for yourself, buy gifts for your benerded friends, or just BUY MY BOOK! 😉

Get more details at the Pragmatic Bookshelf.

* Everything evidently excludes The Pragmatic Programmer, and Programming Ruby 1.9 for perfectly rational reasons.

Driving Technical Change on Kindle

I’ve gotten a few questions about the availability of Driving Technical Change on a Kindle. Short answer is that you cannot buy Driving Technical Change through the Kindle store.

That does not mean that you cannot read the book on your Kindle though. You can buy an eBook version of the book from the Pragmatic Bookshelf. Once purchased you can buy and download epub, mobi (Kindle format), and/or PDF.

If you switch eReader technology in the future, you can come back and download the appropriate version.

Finally in print – Driving Technical Change

Ever go to a technology conference, read a coding book, or just get inspired by a blog post to try something new? You try it, you love it, you want everyone else at work to do it.

Everyone else says “No- not just no, hell no.”

It’s easy to blame your coworkers. But the responsibility lies with you. If something is great, and your coworkers aren’t buying, then you need to up your game.

I had this problem. I worked through it. I started changing what I did. If it worked, I did it more.

I started recording what I was doing and started shaping it into a presentation and a book.

In a moment of hubris, I pitched the book to Pragmatic Bookshelf. In a moment of luck they picked it up. In many moments of staring at a blank screen, I wrote it.

Now it’s in print.

I sincerely hope that what’s in the book helps people change their workplaces for the better. I also hope people buy the book.

More FUD for Thought

Get it? FUD for thought… I kill me.

I was all fired up and started writing some stuff up about FUD, and why you shouldn’t do it, and what not.

So I started writing, and it felt really familiar, like I read it somewhere else… so I did some searches for key phrases and turned up this post on not resorting to FUD. It quotes me… talking about FUD in my forthcoming book.

I just totally almost plagiarized myself. Here what I had to say about FUD:

FUD stands for “fear, uncertainty and doubt.” Though the phrase was coined in the mid 1970’s, the concept has been around since the first caveman traded a rock to another one “in case the mastodons come back.” More recently it’s been marketers, public relations flacks, and sales guys who use this on you. Basically, the idea is to tell you something that will make you afraid of a rival’s tool, enough so that you invest with the FUD’er.

At a smaller level, this happens in the workplace a lot. Developers with experience with proprietary tools spread rumors about crazy license implications of open source tools. Open source adherents spread horror stories of hidden code in proprietary tool kits.

It’s ultimately self-defeating. At best it can win people some sort of short term gains, but in the long term, it is a road to nowhere. Eventually people wise up to be bullied repeatedly and some people speak out. This spread of information inoculates the rest and the technique becomes ineffective. [from chapter “Create Trust“]

I stand by that. FUD does ruin credibility. It hurts you, it hurts your listeners. Even if your product is better, talk about why your product is better, not why the other guy’s is worse.

I’m an Author – Driving Technical Change

About a year and a half ago, in a moment of overconfidence I sent a proposal to the Pragmatic Bookshelf, the publishing company headed up by Andy Hunt and Dave Thomas of The Pragmatic Programmer fame. I wanted to write a book about my experiences trying to get coworkers to adopt new tools and techniques. Much to my pleasure and surprise, they accepted my proposal, and I’ve been working on it ever since.

My goal was to write a book to help people who were struggling to get new tools and technologies adopted at their workplace. I wanted to share tools and techniques for promoting change. Or to put it more eloquently by the publisher:

Your co-workers’ resistance to new technologies can be baffling. Logical arguments can fail. If you don’t do politics, you will fail. With Driving Technical Change, by Terrence Ryan, you’ll learn to read users’ “patterns of resistance -and then dismantle their objections. Every developer must master the art of evangelizing. With these techniques and strategies, you’ll help your organization adopt your solutions-without selling your soul to organizational politics.

As of April 7th the book is now available in Beta format. Part of the deal when your publishers are programmers is that books can go through beta. So you can buy it now, in a package deal with the eventual paperback. Feel free to go buy it… Wait what a horrible salesman I am. BUY MY BOOK!

If the topic sounds familiar, it is. I gave a talk a few years back at cf.Objective 2008 called Selling Professional Development at the Hostile Shop. This book is certainly a descendant of that talk. But I have to say I’ve learned a lot more since then:

The people who aren’t adopting what you want are not your enemies
In most cases, you yourself are responsible for your difficulties in getting people onboard
But this means in most cases you have success within your reach
Trust is the most important commodity you have in your efforts

I tried to bring that wisdom into the book version. Titling the book was pretty hard, so we called in Meat Loaf as a consultant, and he arrived at the monster title – Driving Technical Change: Why People On Your Team Don’t Act On Good Ideas, and How to Convince Them They Should. (His original pass was My Co-workers Will Do Anything at Work but They Won’t Do That.) It’s hard to succinctly explain what the book is about, so we figured we may as well go whole hog.

So check it out, and if you think it would help you go ahead and BUY MY BOOK!