The Persuasive Wizard

My book, The Persuasive Wizard: How Technical Experts Sell Their Ideas to Non-technical Decision Makers, is scheduled for publication in late August.  This book was written specifically for technologists who must present their ideas and recommendations to decision makers – men and women who have the power and wherewithal to determine your fate.  Maybe your presentation is for increased funding, a new project, maybe a plea for sustained staffing, or maybe just a petition for a better job.  In watching the NBA playoffs last night, I was struck by how forcefully that game emphasized a key point that I bring out in my book – stay laser-focused on the desired end result.

Here’s how the NBA game went down.

The Dallas Mavericks were clearly the underdogs in this game and in the entire series.  Last night they were down two games to one in a seven game series.  The Miami Heat has arguably the two greatest players in basketball, Dwayne Wade and LeBron James.  Add Chris Bosch and you have what appears to be an absolutely insurmountable trio of superheroes.

Who’s on the Mavericks side?  Clearly Dirk Nowitzki is in the top 25 of the greatest seven-footers to ever play basketball, but he does not have the athleticism of either James or Wade.  Plus, he is only one man.  Last night, Nowitzki was running 102 degrees fever from a sinus infection.  Add to Notwitzki’s ill health the 38-year old Jason Kidd who does not need to be defended because he doesn’t shoot.  Add to that a Jason Terry who has been sub-zero for the last two games.  There are flickering embers from Tyson Chandler and Shawn Marion, but they are not going to get you 20 points.  And then there’s the 5′ 10″ J.J. Barea, my personal favorite.  There is no way such a combination could have won last night, especially when they were behind by nine points.  But they did win.  How?  Because they stayed focused on the end result – winning that game.

In contrast, here’s how it usually goes down with the technology wizard.  The technology wizard starts out the presentation like a house afire.  Data, facts, conclusions, implications, assertions, details, details, details, details, details, …. and there you have it.  Almost every technology wizard gets bogged down in details and forgets what he wants to accomplish in the meeting.  He forgets why he came.  Most technology presenters cannot even answer the question, “What do you want to accomplish in this meeting?”  They just go into the meeting with a boatload of data and and forty viewgraphs describing everything they have done since they last made a presentation.  What you want to accomplish is to have the decision makers approve your recommendations.  They can scarcely do that if you are injecting them with Novocain-details and putting them under at every turn.

Next time, try a different approach.  Prepare your last viewgraph first.  That viewgraph is what you want decided in the meeting.  That viewgraph is your walk-off-the-stage viewgraph.  It will be the last thing they will see, the last thought you stick in their minds.  What is on that viewgraph?  By no means is it a summary of what you said.  Forbid.  Don’t even think it.  It is your recommendations, my sweet, what you want done, what you want enacted.

Once you have that viewgraph perfected and razor sharp, make sure that everything you show, everything you say, every gesture you make, every neuron, every piece of data, every implication, everything, absolutely everything, is pointing right at that end result.  If it does not point to the end result, take it out of the presentation entirely.  Never falter, never waiver.  Say nothing, do nothing, and think nothing that does not lead to that end result.

You can gain a valuable lesson from that NBA playoff game.  Never, for even a moment, take your eyes off of what you want to happen.

I spent much of my career directing think-tank organizations that focused on the needs of the US Intelligence community.  My organization investigated the forefront of every new technology that came along, which meant that I bought them the latest and greatest processing equipment.

We were intrigued by an expensive and novel computing asset for our laboratory.  Because it was so expensive, our corporate officer, Gene Stapp, and my division president, Marshall Williamson had to be sign off on the purchase.  They had me fly to Redwood, California with them so they could be convinced that this investment would have a suitable return.

Now, Marshall Williamson had joined our predominantly hardware company as a software programmer.  His notable distinction was being the first software person to be promoted to division president.  At company functions, employees would surreptitiously post an old photo of Marshall with his scraggly beard and leather sandals, the way he looked when he first started work at the company as a software geek.  My guess is that Marshall took secret pride in these postings.

Gene, on the other hand, had not seen technology for years.  He was a corporate officer.

Larry Ellison, the flamboyant cofounder and CEO of Oracle, was our first stop.  Larry had personally invested in the computing technology I was investigating and agreed to share with us  his reasons for investing and his thoughts about taking the new technology public.  His high-rise office, elaborate lifestyle, and California persona were poised to impress us, but in our government contracting we often found ourselves on opposite sides of the table from Oracle, so, at best, we were circumspect in the meeting.  Larry was cordial and Gene and Marshall asked a lot of questions, mostly financial.  My mind was not overly engaged because I was focused on the technology.

That afternoon, we visited the company with the technology.  The gurus put us in a conference room with ample refreshments and began the technology presentation.  I was engaged, asking questions and probing the capabilities.  I had done my homework.  We were connecting the dots and filling in the logic.  Marshall and Gene asked only a few questions.  The room was smoking hot with technology.

We were only about seventy minutes into an entire afternoon’s presentations and still accelerating to speed when something strange occurred.  Gene waited for a natural break in the presentation and says to the president of the company, “We need to caucus among ourselves, Marshall, Lynwood, and I.  Would you mind leaving us (alone) so we can caucus and consider the things we have heard so far?”

The president of the company does not know what to think.  He looks worried.  I’m a little worried myself.  Did I miss something?  Did Gene spot a technology flaw that slipped past me?  Is he thinking we should not invest in this technology?  Does he think it is too expensive?  What?

There was nothing the president of the company could say except, “Of course.  Take all the time you need.  Let us know when you’re finished.”   All their troops march out of the room and leave Gene, Marshall, and I to caucus among ourselves.

Gene waits until they are all gone.  I’m quiet not knowing what to expect. Marshall does not say anything, either.  I look across the table at Gene who finally breaks the silence, “I don’t want anything,” he says.  “It’s just that I’ve had about all the technology I can stand.  If you want to buy this stuff, go ahead.  I’ve heard all I need to hear.  I’m done here.  It’s your call.”

I let out a relieved laugh.  “Okay, I say.  Sounds good to me.”  I reach over for the refreshments and pass them around.  We take our coats off, loosen our ties, put our feet on the conference table, and lean back.  Gene and Marshall spend the next half-hour talking about other things they are working on.  Gene calls his secretary and has her book the next flight out, about ninety minutes away.  I call the group back in.  I tell them that Gene and Marshall have had a change in plans and we all must now leave on an earlier flight.  I tell the president of the company that I will get back in touch with him.  Gene, Marshall, and I head for the airport.  I call the company later that week and close the deal.

What you have here is Decision Maker saturation.  Decision makers can only stand so much technology and then they shut off.  Therefore, when you brief a decision maker, be certain that the technology part of the presentation is pertinent to the overall business objective.  Do not brief technology for technology’s sake.  Keep your objectives in plain sight.  If you are requesting an investment, focus only on those items important to the investment and of interest to the decision maker.  Work the deep technical issues off-line or separately with the technologists.  Do not take up the decision makers’ time with technology they do not want to hear.

A better approach in this particular scenario would have been for the company to stick to the high nails and brief Gene and Marshall only on the technology features of interest to them – the competition, life-cycle costs, technology maturation, asset aging, and so forth.  Then, find something for the them to visit or tour while the technology was briefed to me.

Now, you ask, why did I fly back to Dallas with Gene and Marshall and not stay, myself, and hear more of the technology?  “Why would I do that?” is my answer.  Think about it.  I had already made my technology decision before I ever went on this trip.  The purpose in going was not to convince me, but to convince Gene and Marshall to sign on the dotted line.  That being done, I was done.  I needed to spend my time working the next project, not staying there to fill in an afternoon.  Plus,  as technologists we do not get much face time with the big decision makers in our company.  I wanted to fly back to Dallas with them so I could talk about my next great idea.

The bottom line is this: be careful with decision makers.  When the subject is technology, they saturate readily.

I regret to add that Marshall Williamson departed this life far too early.  His perspicacious humor, creativity, and unique leadership skills earned him my devotion.  I am proud to say that he was my friend and even though he left several years ago, I yet often lament his parting.

I was in the community of Cranfills Gap, Texas over the holiday weekend.  The only reason you might ever have heard of this Norwegian town of 350 people, two stop signs, and no traffic lights is that in 2008 the Las Vegas tourism bureau made national news by picking the entire community for a promotion.  The Las Vegas bureau flew half the residents, virtually all the persons over 21 years of age, to Las Vegas for a fun-filled five days of gambling and shows.

This past weekend, however, I was not having fun in Cranfills Gap.  It was Friday afternoon of a three-day weekend and my vacation property had no water.

Now, even though this is a remote area, a private company runs lines from their water wells to their customers.  So, my son and I journey to the property anticipating a great weekend with our friends only to discover: no water.  I rush into town (an intersection) at 2:30 PM on Friday afternoon.  The office for the water company is in a carved-out paneled corner of an otherwise abandoned building.  No one is there.  I tap on the window of the neighboring office and Rita, the coordinator for a local contractor, jumps about a foot off her chair.  (My tap was louder than I intended.)  Rita tells me that the water people have gone for the weekend.

So, I tell Rita my plight and ask her what she would suggest.  She gets on the phone and calls the water administrator: he has gone for the day.  She calls the repairman: he does not answer his phone.  She knows one of the board members: that person does not have a phone number listed.  Rita calls a friend who has the cell number of the board member.  She tries that number: they’ve gone off for the weekend on their motorcycles.  She checks the internet.  She checks her directory.  Rita calls another board member: no answer.  She tries a second person who might know.  No answer.  Rita knows all six people on the board.  She calls a friend to get some of their cell phone numbers.  No one answers.

First of all, keep in mind that Rita has nothing whatsoever to do with the water company.  She is just one of the wonderful people in Cranfills Gap.  Second, I found out that Rita is one persistent devil.  On her fifteenth call she gets the president of the board on his cell phone.  He tells her he will check and call her back.  He calls her back in a half hour to say he cannot get the repairman on the phone, but he’ll keep trying.  The repairman has gone home to Iredell and probably leaving for the weekend.  Now, all of this has taken almost two hours.  It’s about 6:00 PM on a Friday weekend so I thank Rita and go on to the land expecting that the repairman will show up sometime next week, if at all.

About 8:30 PM a truck rolls up to the gate towing a trailer with a giant backhoe.  It’s Chris, the repairman.  We hold flashlights while Chris replaces a faulty meter and regulator.  (Chris does not get any extra pay for after-hours or weekend callouts.  He works on straight pay.)  By 9:30 PM we are in business.  I have to force Chris to take a $20 bill so he can go buy himself dinner.  Now, isn’t that a great little community of wonderful people?

But I tell you all this to discuss an essential element of persuasion: persistence.  Success occurred only because of the unrelenting persistence of  Rita, the scheduler for a totally different company.  Once she was engaged there was no stopping her.  She knew about persistence and she knew about follow-through.

If you want to persuade decision makers, you must be like Rita.  You must try and try and try and keep trying.  When it comes to computers or networks or engineering, wizards will work all night long on technology and never think twice about it.  But when it comes to people, they somehow think that everything should happen with one request.

Here are the cries of the hapless technology wizard who has no notion of persistence and no chance of success.

“I called them but they haven’t called me back.”

“I left three messages.  What else can I do?”

“I’m waiting to hear back from them.”

“I sent him an email.”

“I left her a voice mail.”

“I asked Susan to give them a call.  I’ll check and see if she’s done that yet.”

“They said they would get back with me sometime next week.”

“I can’t get a hold of them.”

Those are the whines of failure, the whimpers of the unsuccessful.  Opportunities do not come knocking, they do not even come creeping by.  You ferret them.  You seek them out.  You track them down in the dead of night and the cold of winter, at the most inopportune times.  You lay traps and stake ambushes.  You mine for them like silver.  You sift for them like gold.  You work for every opportunity.

The world is full of people who will work for those opportunities, your opportunities.  They will steal your opportunities while you sit and whine about it.  You must take charge.  I realize that as a technologist this is your weakest suite.  You hate to “pester” people or bother them.  Why, when you were a kid, you couldn’t even sell cookies to your grandmother.  I empathize with you, but if you want success there is no alternative.  You must continue to pound on the door until either opportunity opens or you break down the down and drag it off with you.

This does not mean that you keep doing the same thing over and over again like an idiot, just hoping someone will notice.  It means that you keep your message, but you vary your techniques.  You try different tactics.  You approach from a different angle.  You parry instead of thrusting.  You wield a claymore instead of a foil.   You pass instead of running.  You think of another reason to call.  You send a letter.  You post a blog  You do whatever it takes to make those opportunities available to you.  You become persistent.

If you want to develop persuasive skills, know that there is no weapon in your arsenal that will serve you better than persistence.

If you want to persuade a decision maker, your first requirement is to capture and hold her attention.  You can scarcely influence one who is not at least drawn into your arguments.  Obviously, even when drawn in, the decision maker may not confer your recommendations, but you have no chance if she is abstracted.  Practice audience capture by taking a single argument and examining how you might present it in a compelling way.

For example, yesterday we all watched the century event of the Indianapolis 500.  It finished with flair as rookie J.R. Hildebrand stuck the wall only a few hundred yards from the finish allowing Briton Dan Weldon to whiz past him for the trophy and the several millions dollars that accompany it.

Weldon started in the number six position with a qualifying speed of 226.4 mph, only one mph behind the pole starter and two mph better than the number 24 starter.  That is a small variation and emphasizes the athletic/team skills required to win the race, not to mention a peck on the cheek from that two-timing mistress, Lady Luck.

I plotted the top qualifying speed for the entire 100 years of the Indy expecting to scientifically curve-fit the data and predict the speed for the 150th Indy event.  Surprisingly, I found that the pole position qualifying speed has not changed appreciably since about 1991.  In other words, within statistical bounds the fastest qualifying speed has remained in the same small range for 20 years.  Now, pundits will say this is the fault of the track, the Indy specifications, and so forth.  Nevertheless, it points out how the race has transitioned from dominant speed to coordinated team skills.

I plotted the average lap speed for the winner each year.  That was even more surprising since you can fit the data with a reasonable straight line and impressive correlation coefficient starting almost forty years ago, way back around 1970.  In looking at the data, you might even make a case that the slope is slightly negative.  In other words, the average lap speed might be decreasing instead of increasing.  Again, the pundits will hand-wave the yellow flags, varying weather, pit affairs, and so forth.

Regardless, the compelling observation is that speed is not the primary factor in the Indianapolis 500 and has not been for decades.  All cars that enter are capable of and exercise almost the same top speeds, the same average lap times, and the same pit efficiencies.  Track and weather conditions are the same for all entrants in any given race.  Speed is not the essential element.

So, if it is not speed, what is it?  Probably a combination of athleticism, team ability, team coordination, split-second decision making, strategy improvisation, equipment optimization, and, of course, random events that take the moniker ‘luck.’  This convoluted complexity makes modeling the speed a tad more difficult.  So, what about my prediction for the top speed 50 years from how?  Can it be done based on past events?

I liken it to the NBA finals coming up this week.  You can posit all the statistics you like, you can make all the predictions you want, but the winner will be determined by who has the highest score at the end of the game.  Thus, the Indianapolis 500.  The only way to predict the winner is observe who crosses the finish line first and that likely will keep up coming back year after year.

This is the final part of a four-part series comparing four different methods I used for creating this web site.  You are viewing the results of the fourth.  In  Part I, I contracted a third party for design and development.  From that experience, I concluded that the use of a third party was the obvious and good choice for those who wanted to focus on web content and not be concerned with the underlying technology, likely the vast majority of users.  Part II described my adventure using iWeb, Apple’s WYSIWYG site builder.  I concluded that the iWeb capability is best suited for personal use and small networking , similar to Facebook.  In Part III, l studied and learned HTML and CSS over a period of about two weeks and built my own site.  This was wonderfully satisfying.  And now, armed with the ability to write my own code and far more knowledgeable than I had been originally, I decided to advance to its blog design.

I created a prioritized list regarding my blog:

1.  Needs to be read by a large audience.

2.  Must be attractive and readily accessible to a large number of readers.

3.  Must be easily updated and maintained by me, personally.

3.  Must have a fully addressable archive.

Examine the first priority, the requirement to attract and be read by a large audience.  I want someone to actually read what I write;  I want it to make a difference.  I desire to transform the technology wizard into a persuasive force for entrepreneurial funding, research dollars, a higher paying job, or whatever else she desires.

I discovered that a primary and necessary (sine qua non – without which none) component to attracting a large audience was ‘searchability’:  blog content must be frequently and efficaciously cataloged by the major search engines.  There is an entire community that focuses on just this capability, generally referred to as Search Engine Optimization (SEO).  It is a broad field and includes companies, tools, and schema. Since I did not want to create yet another thing to spend my time on, I decided to use a platform that already had an effective SEO capability, WordPress.  WordPress is open source software that provides SEO  right out of the box.

Matt Cutts heads up Google’s Webspam team. See an interview regarding his recommendation of WordPress.

Having chosen WordPress, I considered appending the WordPress blog capability onto the site I had written already.  However, WordPress is designed to use its own templates so I chose one.  I transferred the content from my existing site to the WordPress template.  The new site was up and running within hours and here you have it.  I used my newly-learned knowledge of HTML and CSS to make small modifications, but those were insignificant changes.

I will continue to use WordPress and report on its effectiveness in satisfying my prioritized criteria for the blog and would welcome any comments regarding SEO or the selection of WordPress.

In ending this series, I must annotate that my research and decisions were greatly hastened by the third party I mentioned in Part I, Harrison Givens.  Harrison keeps up with all things technie and is invaluable for creating and exchanging ideas.  I recommend him highly for all your entertainment lighting needs.

This is the third part of a four-part series comparing four different methods I used for creating this web site.  (You are viewing the results of the fourth method).  Part I dealt with the use of a third party for design and development.  I concluded that third party development required an unsatisfactory amount of interaction and iteration.  Part II describes my adventure using iWeb, Apple’s WYSIWYG site builder.  I concluded that the iWeb capability is best suited for personal use and small networking , similar to Facebook.  That did not suit my needs.  The third approach would be to build one from scratch.  This would be  more difficult than either of the other two approaches.  Did I want to invest the time and resources to program my own site?  That would mean I must learn the HTML and CSS programming languages.

It might be worth a short discussion of my software programming experience.  In my very early years I scratched out a few algorithms in Assembly Language.  Those algorithms were placed in satellites where memory and bandwidth were at a high premium and Assembly Language was mandatory.  Later, I designed my five patents using Fortran, a programming language tailored to scientific applications.  For a short while I worked in cognitive recognition and learned a little LISP.  For the last number of years C++ was the language of choice.  Having said all this, I was never a software programmer of any ilk.  In physics, software is a tool to solve scientific problems and implement algorithms.  Physicists prefer to work from first principles, make theoretical models, and predict outcomes.  I find software too much a try-this, try-that bailiwick.

Nevertheless, thus armed with my limited software experience, I decided to learn HTML and CSS (self taught) and program my own web site.  From reading the internet reports, I chose Adobe‘s Dreamweaver as a tool to help learn the languages and build the site.  I signed on for a 30-day free trial of Dreamweaver and headed to the bookstore to load my cart with the Dreamweaver Bible by Joseph Lowery and Dreamweaver: The Missing Manual by David McFarland.  Total investment $65.  (I would have preferred to buy used books but could not find used editions that supported the latest software versions.)

My experience with Adobe is that their user interfaces are opaque and proficiency in their products is a vocation.  Dreamweaver did not alter the statistics. With Dreamweaver I quickly found I could split the windows and use WYSIWYG in one window and the associated HTML (or CSS) would apper in the other.  This was so useful that all interactions gravitated to WYSIWYG.  Of course, one would know this would happen since I did not know the languages.  I was back to the same approach I had used with iWeb except with manifold variations on a theme.  I will not criticize the thousands who love Dreamweaver, but I could not develop a relationship.  My intent was to build a website from scratch using HTML and CSS and Dreamweaver was not getting me there.

Off to Barnes and Noble again.  This time $70 got me  HTML, XHTML &CSS for Dummies and CSS: the missing manual.  I read about twenty pages in Dummies and started writing code.  I have always thought the collection of Dummies to be uneven,  some good, some bad, probably inevitable with a syndicated series.  The HTML Dummies book was both of these, quite good for the first third of the book and noticeably weak for the latter two-thirds.  My speculation is that the authors started out on the right path and then got behind schedule.  They were in a hurry to get their publication out for the new software version, so they hastily pasted the second two-thirds together: informative and correct, but not to the standards of the first third.  Pure speculation based on content.  I found CSS the missing manual to be adequate, but unremarkable.  Between reading the books and referencing the internet, it took me about two weeks to learn HTML and CSS enough to get a test site up and running.

HTML and CSS are very similar, both high level languages that take only a short amount of time to come up to speed.  Did I achieve proficiency?  No.  Did I become expert?  No.  Did I make a professional looking and highly functional web site?  Absolutely, yes, and better than any WYSIWYG approach I tried.  It was loads of fun and unbelievably satisfying.

I tweaked on the site until I had it perfect, getting the header cropped to perfection, smooching the spacing here and there, and finding the best links for my images.  It was a blast.  Unfortunately, like so many things in a technologist’s experiences, it developed a life of its own.  I was reveling in my newly found engine.  I envisioned hiring myself out to develop web sites, making millions of dollars and then selling my Web-Site-For-Hire company to purchase the Dallas Mavericks.  After a month of fun, I realized that I had forgotten why I was doing this.  What I really wanted to do was promote my book and write a blog to help other technologists become staunch communicators, that is, persuasive wizards.  It was time to move on to the real purpose.

I needed a platform to launch a technology persuasion blog, a site that would develop interest, be read by thousands, and be effective.  That decision and how I implemented it is the subject of Part IV to follow.

This is the second part of a four-part series comparing four different methods I used for creating this web site.  (You are viewing the results of the fourth method).  Part I dealt with using a third party for the design and implementation.  In Part I, I discussed two problems with using a third party.  The first was cost upon which I did not elaborate because of my special situation.  The second was the necessity always to coordinate with the third party for modifications and alterations, an inefficient approach.  It is unrealistic to expect a third party to read your mind.  Exchanging ideas, iterating options, and implementing changes was cumbersome.  I felt the third party utilization did not suit my constant need to envision and alter, so I tried a second method, the use of iWeb.

iWeb is an Apple product intended to create web layouts using the WYSIWYG ( What You See Is What You Get) approach.  iWeb has you select from a few standard formats that carry promotional names like Doodle, Gazette, Highlighter, Elegant, and Watercolor, to name a few.  I chose Elegant because I wanted it to look like a professional site.

It took me about four days to create a sophisticated, five-page site that included  a blog.  Had I gone for the simple approach, I could have published the site in 1-2 days.  The iWeb interface is easy to learn, images are conveniently inserted and resized, and the finished product looks clean and neat.  Unfortunately, it bordered on looking ‘cute.’  I retained the Cyberduck FTP client that I mentioned in the Part I blog and the HostGator web host.  Once I had the iWeb-produced site up and running, I left it online for 3-4 weeks. I continued to make tweaks and modifications, as is the practice of all technologists.  The more I viewed and used the site, the less I liked it.

There are numerous shortcomings in iweb, some of them fatal for a professional site:

1.) It was annoying that each page had an Apple logo with a crass “Made on a Mac” statement as the footer.  This was trivial to delete, but an annoying annotation, especially when it sometimes went unnoticed until the site was published.

2.) iWeb is only partially WYSIWYG.  If you try to modify the actual template, (like increasing the width or changing the divisions layout), by using its inherent drag-and-drop technique, you can produce unplanned changed in alignment and positioning.  Another flaw is that the images and text sometimes move as directed and sometimes do not.  The path to correcting a mistake is virtually hidden to the WYSIWYG developer: in other words, if you make adventurous or inadvertent changes, you are clueless as to how to correct them.  (Obviously if you know HTML and CSS you could make those changes but that is the subject of Part III in this series.  At this point I am critiquing the iWeb WYSIWYG concept).

3.) The page width is only about 600 pixels.  This appears archaically narrow on most monitors.  The blog does not move to the center when the window width is broadened; it continues to remain as a sentinel on the left.

4.) Strangers did not read my blog because there is no WYSIWYG-way to insert key words or descriptions to guide and influence the web crawlers bots.

5.) The site was highly sporadic in how long it took to load.  Sometimes it would take as long as 15-20 seconds at 1 Mb/s transfer rates.  And this was after I had ensured that no image was larger than 8kB.  I assume the slowness arose from the computational overhead produced by iWeb’s generalized template approach, but I did not investigate.   This long time to load was not only annoying but made the effectiveness of the site questionable.

6.) The more you viewed the site the less professional it looked.   I cannot tell you exactly why this was so but it was like viewing a house designed by a builder as opposed to one designed by an architect.  iWeb is functional but not overly so and certainly not professionally attractive.

7.) The ability to add interactive tools such as ordering my book (The Persuasive Wizard: How Technical Experts Sell Their Ideas to Non-Technical Decision Makers to be published this summer), submitting credit cards, getting feedback, and other information was obscure, if even attainable, and certainly not an integral part of Apple’s design or the WYSIWYG capabilities.

iWeb is best suited as a personal web site intended to be viewed mostly by friends and visitors who would call up the site by its unique URL and not by search or reference.  If you want a web site whose primary function is to blog to no one, post pictures of your family, or make friends jealous of your vacation to Budhanilkantha, then iWeb is a perfect choice.  If you want to have a professional look and feel, iWeb is not suitable.

After 2-3 weeks of the iWeb site I decided I could endure it no longer.  Perhaps the only thing to do would be to design and write my own web site from scratch.  Hmmm.  That would require learning HTML and CSS.  Perhaps it would be best to look before I leap and that is the subject of Part III of this series.

ABC is an acronym in Sales organizations for Always Be Closing.  In other words, always be working to finalize the deal, complete the sale, get the signature on the bottom line, cash in and take the money to the bank.  This pithy admonition was ingrained long before Alec Baldwin made it a centerpiece it in the movie Glengarry Glen Ross. But, if ABC means Always Be Closing to the Sales organization, what should it mean to the Technology organization?

What it too often means is  Always Be Completing.  In other words, for the scientist, engineer, or technology wizard, nothing is ever actually completed because there is always something else that must be done, adjustments to be made, tweaks to try, improvements to add, bells and whistles to bolt on, ideas to try, bugs to fix, research to finish, or a new version to install.  ‘Completed’ is asymptotically approached but never realized.  Ofttimes, to get a product to market you are forced to yank it out of the hands of the engineers and get it to production, ready or not.  This fault of never achieving closure is in the genetic makeup of technologists because they want it to be “perfect” and perfection is unachievable.  This approach hinders business and is why I wrote The Persuasive Wizard:  How Technologists Sell Their Ideas to Non-technical Decision Makers, so that we technologists might improve ourselves.  (The book will be out shortly.)

What ‘ABC’ should mean to technologists is Always Be Concise: a capability mandatory for technology persuasion.  In other words, get on with it.  An unfortunate trait of technologists is to give unnecessary, undesired, and unappreciated details to every technology query, drilling to the core of the earth with each response.  A garrulous technology answer is the bane of our trade.  We love our work so we want to keep talking and talking and talking.  This shortcoming plagues science, engineering, mathematics, medicine, computer science, telecom, software, and the thousands of other occupations where wizards ply their trade.  It affects the high and the low in our profession.

I was director of a renown think-tank organization.  The division president caught me in the hall one day and remarked, “You know, you have a smart group, I guess, but let me tell you a typical experience.  I’ve been looking to buy a piano for my daughter.  So, I asked Barry (one of my engineers with broad interests and deep knowledge) which piano he might recommend.  First he started with the molecular structure of how trees grow.  Then, he described the Bessemer process.  Next, he talked about the tension in strings.  I left him rambling about the mechanization of piano levers.  Doesn’t anyone in your group know how to be concise?”

I wish this reaction were either rare or anecdotal.  It is neither.  This has been pointed out to me time and again regarding some very smart people.  So, I caution you.  Strive to be concise.  Here is how.

Reflect on your response.  Answer the question that is asked, not the one you thought was asked, wish had been asked, or the one for which you know the answer.  Keep your answer to a 3-5 sentences.  No more.  If the interlocutor wants more, let him request more.  Listen to his response.  If he moves the conversation in a different direction, he’s done with your answer.  If he asks a slightly different question about the same subject, focus your answer to address this added nuance.  Again, give no more than 2-3 sentences and then iterate the process.  Let it be a dialog.  If you follow these simple steps, you will find yourself well on the way to becoming The Persuasive Wizard.

I was reading Tacitus, a first century Roman historian, and in doing so was drawn to a recorded dialog between a Parthian prince and his subjugated listeners, “Might is right with those who are at the summit of power,” he admonishes them.  His words echoed the Athenian edict of almost 500 years earlier.  Well-armed Athens was ruthlessly and causelessly annihilating the tiny island of Milos.  Thucydides tells us the Athenians justified their actions with, “the strong do what they can and the weak suffer what they must.”  Thus, was handed down the rationalization that “might makes right.”

Now, this Parthian prince was destroyed by Rome and great Athens was subdued by an even greater Sparta, so one might conclude that “might makes right” is not the foremost criterion.  Nevertheless, it persists as a philosophy of implementation.  While I indeed have experienced this “might makes right” attitude with decision makers, my focus here is not on management, about which much has been written, but on the technology wizard, about which little has been composed.

Do technologists sometimes operate by this philosophy that “might makes right?” Yes, in the sense that a high technology reputation is often falsely equated with technology judgement.  Or, similarly, that favorite projects, funded and already in place, are treated by technologists as sacrosanct and perfect: regardless of the facts otherwise and irrespective of the lack of  results.

It happens like this.  Technologists frustrate themselves trying to get a project funded and resources in place.  This particular type effort is exhausting because technologists get scant fulfillment in producing reports, inking schedules, and forecasting outcomes.  (“That’s a job for bean counters,” they would say.)  Thus, once a team is formed and a project is in place, once the equipment arrives and the research begins, once salaries hit the payroll, technologists naturally want to continue the research and sustain the project indefinitely.  Unfortunately, projects are thereafter often sustained even in the face of negative results and patent failures.  Technologists keep pushing the decision makers to continue the project, give it more budget, hold the team together, citing reason after reason why the project should not only be continued, but elevated.  “We can’t quit now, we’re almost there.” “The competition has nothing like this.”  “We’ll take the market by storm.”  These allusions may or may not be true.  The unbiased and sincere evaluator must ascertain progress against quantifiable, targeted outcomes.

Now, the decision makers are not entirely faultless, here, as they may ignore what is said and they obviously have their own biases.  Nevertheless, the decision makers rely upon their technologists to give them valid and factual assessments of the technology, the competition, the issues, and the portents.  Projects that have budget often get more budget, not because the technology cries out with results, but because high-level technologists cry out, because momentum is great, reputations are huge, researchers are in place, and because warning signs are ignored – by the technologists who do the evaluating.

History is replete with examples.  In the first draft of this blog I listed over half a dozen projects and companies where the technologists, themselves, almost carried the company into default.  After my review, I realized that technologists would read those examples and say, “That wasn’t engineering’s fault.  The marketing was poor.  Management was just hosed up.  They kept reducing the funding.  The company was slow to react.”   And, the list would go on.

But, the issue I am called to address is that technologists often let their own egos, established fiefdoms, and historical budgets dictate the technology plan instead of working with the decision makers to properly evaluate the direction the company should take.  It is difficult to make those hard decisions and cancel a project or shift the funding elsewhere.  No one, absolutely no one, likes to do that.  Especially when jobs are at stake and reputations are on the line.  It is easiest to stay with the status quo. (“No one ever made a mistake by going with ‘Big Blue'” is an ancient aphorism to point).  I understand all that, but as a technology wizard, your job is to make an honest assessment.  You must have integrity and not let internal feeling or external influences deter you from a proper evaluation of the technology projects.

Once given the facts, decision makers can decide whatever they like. That is their job.  Your job as a technology wizard is to make factual, quantifiable, candid reports as to the efficacy, output, and future of each project.

Examine the facts.  Listen to all the opinions of the team.  Seek council with peers.  Abandon stubbornness, ego, and historical precedence.  Don’t base your decision on, “I made my assessment and that makes it right.”  Base your assessment on quantifiable facts, clear goals, technology acumen, and a thorough analysis of variables.  Don’t let “might makes right” produce disaster for you, your teammates, or your company.

For any hands-on technologist who might visit Colonial Williamsburg, a trip to the Gunsmith’s Shop is mandatory.  The heat from the forge, the radiation of glowing steel, the waft of oil, the grinding of the reamers, the pounding of hammers, all proclaim the considerable technology required to build a flintlock weapon two centuries ago.

Of special note, here, is the firing mechanism.  When the cock (firing lever) is pulled back completely, it seats until the trigger is pulled, whereby a metal spring energizes the flint to spark the powder.  Boom!  It goes, smoke fills the air, and a projectile sails to its target.  Now, to load the pan with powder, you must clear the flint.  Clearly, you do not want the cock in firing position since the weapon is already loaded and an unintentional firing will be troublesome.  So, the inventors created a half-cock position whereby the lever goes back halfway and seats in a sort of safety position.

I say ‘sort of’ because over time the seat wears, play develops in the lever, and the weapon may unintentionally fire from the half-cocked position. Bad things follow.  Or, you might go off to the hunt, raise the weapon, pull the trigger and nothing happens because it was left half-cocked.  Hence, the term, “Don’t go off half-cocked,”  means “do not go into something unprepared, when only partly ready.”

It occurs like this.  You spend months on a project and, suddenly, are called to an important meeting to explain your progress, or lack thereof (meaning the decision makers are tired of spending money and want to know when they will make money).  You work all night on your presentation.  You feel you have barely begun when a decision maker asks, “When will you be finished so we can see the results of this project?”  You are not prepared for such a direct question.  (You didn’t even know you had a schedule.  Who needs that?)  You are frustrated.  You are at a loss.  Instead of responding with a well though out, carefully targeted, definitive reply, you explode in the half-cocked position, “I don’t know when it will be finished.  No one can predict the outcome of research!”

Immediately, you have raised your weapon and started a battle that, unquestionably, you will lose.

Here’s the right approach.  First, get them to agree on what is meant by ‘finished’ and ‘results.’  Is it the completion of the research, validating the output, building the prototype, what?  Doing this will give you time to group your thoughts together.  In any event, your answer will be directed at something specific and you will know what they mean by ‘finishing.’  Do not just start talking.

Never forget that some of the decision makers are your advocates.  Otherwise, how did you get here in the first place?  They may be helpfully prodding you to get off the technology details and move on to to the subject.  They may want you to explain what has been done, why the delay, what you will need, and how long it will take.  Do not transform every question into an attack.  Do not make yourself a target.  I cannot tell you how often technology wizards needlessly assassinate themselves with ‘friendly fire.’

Now, once you understand what they mean by ‘finished,’ take some time to explain what needs to be done in order to get to that finished point.  What is holding you back?  What equipment is needed?  What personnel?  Why do you need them? Do not mention cost or budget.  Be specific.  Talk about what you need, not about what it costs.  The difference in effect is enormous.

In most cases, when you will finish depends upon the level of resources bestowed upon the project.  While ten ships cannot cross the ocean a magnitude faster than one ship, there likely are areas where additional resources will sway the schedule.  Be specific and quantitative.  Decision makers usually want to help, not hinder.  After all, they did fund it to this point.

Finally, answer the question by saying, “We’ve had these problems and that has slowed us down.  (Be exact, accurate, and specific.)  Given these resources (the ones just discussed) I predict we can finish (using their definition of ‘finish’) by the end of the summer (or whenever).

What is the lesson from the Gunsmith’s Shop?  Never go into a meeting unprepared.  Like the Boy Scouts, “Be Prepared.”  If, however, you find yourself in short supply, take the time to gather your wits and and formulate a definitive response that hits the target.  Do not go off half-cocked and senselessly shoot yourself and your project into history.