Category Archives: Communication

Superheroes in IT, come down to earth…

Are you a technology superhero?  Then you might want to read this (and even comment!)

Information technology is a widely misunderstood part of business:  executives view us as a necessary evil, yet do not understand  IT is an investment.  As technology professionals, we lament our treatment as suppliers (or even servants) instead of business partners, and spin our wheels trying to prove that we add value to the business. What we fail to see is that we unwittingly contribute to the dysfunction with a superiority complex that we project on the business.

We view ourselves as technology superheroes, while the rest of the world sees us as overpaid intellectuals lacking in social skills.  There is no right or wrong here, just misunderstanding on both sides of the relationship.

The Superhero World

As software engineers, it is hard to imagine that the world thinks any differently than we do.  We take for granted how we learn, digest and embrace new concepts, so much so that we assume it is universal.  Certainly, we recognize genetic individuality, but we assume thought patterns are common. When we assimilate new ideas easily, we assume that others can too. We reinforce our beliefs by seeing co-workers behaving the same as we do.

This is a major issue in IT and engineering (and other professions as well) where success hinges on clear communication and a shared understanding of business needs. As software engineers and product developers, we live in an insulated world – one laden with technical terms and concepts, and life as we know it can be exciting!  We are the superheroes in IT – we use Kanban, Lean, and Agile to get close to our customers and we develop advanced software solutions that make the world better in a single bound.  Or so we think…

The world would be perfect if we could concentrate on doing what we do best – building great software solutions – without interference from the outside world. The problem is that we have to deal with “mere mortals” in business, and for some reason we are simply not on the same page. Herein lies the problem:  our assumption that the world thinks the same way that we do.

As superheroes in the IT world, we ARE different, but we need to function in the real world.  We are addicted to technology but others are not… so who has the problem and what can we do about it?

First steps…

The first step in solving any problem is to admit that it exists and take responsibility for our part.  This means taking a hard look at our role and what we can do to change the dynamics of the business / IT relationship.

Here are a few ways that we can take responsibility for improving the relationship:

  • Realize that the way we look at the world is not universal. As software engineers our passion for technology is hardwired, just as others are hardwired with passion about banking or marketing. My professors (and maybe yours) taught that everyone aspires to engineering and computer science, but few can make it, and this created an elitist view of the world.  I now know how this attitude projected a sense of superiority and entitlement to special respect that is simply, undeserved. Recognizing these differences is the first step to humility and true communication.
  • It might sound impossible but… technology IS intimidating.  Moreover, the subject can be boring to others. The world does not share our zest for IT English – we may be superheroes when it comes to creating technology solutions, but that does not make it interesting to others. While it might seem like “dumbing down” when we translate IT English into business English, there is no other way.  If we continue to talk our talk without consideration of others – well, we sound unintelligible.  (Just watch an episode of the TV show “Big Bang Theory” for a glimpse of how techies seem to the world).
  • There is no base level of idiocy. Many technical professionals believe that there is a base level of knowledge idiocy.  In IT, we dismiss anyone as an idiot whose technical knowledge is below this “line” and then treat him/her as a lesser being. While we do not necessarily do this consciously, it comes across in the way we talk down to non-technical people.  Sure, doctors do this, lawyers do this, and software engineers do this, but it does not promote good relationships on projects. The sooner you realize that your basic level of knowledge (such as knowing about the software development life cycle or communication protocols) is above the general population, the better off you will be.  While you and I might be aghast to realize how little most people know about software concepts, they do lead successful and productive lives without this knowledge.  We are the idiots if we cannot translate IT English so our customers can understand, not the other way around.
  • Read outside your world. If we want to understand how our customers think, we need to explore outside the world of technology. Find out what journals your customers read, and pick up a copy. When you start to understand what your customer’s world is all about, you can start to solve their problems.
  • Accept the world that is. Engineers are known the world over as being great at technology and poor at communication.  Instead of denying this fact and defending ourselves, we ought to accept it, improve it, and move forward.  Communication and soft skills can be learned, but we first have to admit that we need help.  I know many software engineers who behave as ostriches by burying their heads in their work and avoiding customer contact.  Why not accept the world as it is and improve on it through education?  Ignorance is bliss except when it comes to communication – and the good news is that communication can be learned.

If we want to garner respect for the IT superheroes among us, we need to come down to earth and live among the “mere mortals” (non-IT).  Only then can IT save the world.

What do you think?  Agree or disagree? Comments?



Separated by a common language... IT English is different

I am not a stupid person, but I simply cannot keep up with all the new information technology (IT) terminology!

I know that every industry has acronyms and terms, but it seems that IT artifactis unique: every time a new methodology comes in, English words are redefined.  Today, IT English is expanding.

For example IT English uses Scrum (but not for rugby), Ruby (not for birthstones), Java (without caffeine), and Artifacts (but not from Egypt).  Certainly, English English is different from American English and Australian English, but IT English is a dialect unto itself.

If I, as an engineer with experience in IT, am daunted by the ever-changing IT English, how much worse is it for laypersons who work on software projects?  It can be intimidating.

I read an “introductory article” written by an IT colleague today and had to read and re-read it several times before I gave up. Despite visual aids and process flows, I felt I needed a geek-to-English dictionary to make sense of it.  (Yes, it was written in English.)

Most of us are not bilingual, so it should be no surprise that many technology professionals only know IT English. In fact, some do not even realize that there are other English dialects. When engineers find a new way to do things, you can expect a flurry of new acronyms and variations on IT English.

This happened with “waterfall”, client/server, web development, agile, lean, and Kanban. Once you understand that old words get new meanings, it all makes sense, but it is a learning curve every time.

Do you know that everyone (outside of IT) asks

Why can’t IT just speak English?

Outside IT, it’s no mystery why software projects fail (to meet user needs).  Just when users and the business learn enough IT English (technology) words to converse, a new method comes in and the dialect changes.

In my post earlier this week (IT’s all about the people, stupid), I touched on the need for “soft skills” in technology, and mentioned the communication factor.  Soft skills or EQ (emotional intelligence quotient) covers more than communication (such as empathy, consideration, mutual respect, cultural sensitivity, communication, and a host of other people skills), but communication is the linchpin.

My first IT English “encounter”

I’ll never forget my first engineering job in Alberta, Canada working for a pipeline engineering company. During the first week, a colleague suggested that I should “sign on” to the mainframe.  I gave him that “are you nuts – why would I want to do that and have to call IT?” look and walked away shaking my head. No one in his/her right mind would purposely “interface” with IT unnecessarily.

monitorAs luck would have it, I found myself working in IT a year later. On my first day, I had to sign on and predictably, the system crashed within an hour.  I became the network operations’ comic relief when they asked me my terminal address and I responded that I was on the eighth floor. Over muffled laughter, they told me they needed the 16-digit number on the side of my terminal (monitor)… and added that they were also on the 8th floor.

I had no idea that my English fluency would be so tested in IT.  While I knew that English is the language that separates so many across countries, I didn’t know it also was true with IT.

What is the solution for IT English?

misunderstandIf we truly want to make progress with technology, we need to recognize the walls that IT English puts up around us.  It’s not enough to know that there are walls and to converse with each other – we need to care about the misunderstanding that arises whenever we redefine English words and expect the world to understand.

IT needs to stop talking in acronyms and start translating our IT  English into English English or American English (a dictionary or savvy translator can help) so that when we talk technology, others will listen.

That is, if we truly want to communicate with the business.  It reminds menapoleon of the English Channel Tunnel (Chunnel) project:  did you know that it was originally started by Napoleon over a hundred years earlier?  The project stopped when Napoleon realized that the tunnel would not be a one-way deal…

What do you think? Am I being too cynical about IT?  Is there hope for IT English to become mainstream or vice versa?

(Fade to black with the strains of Dr. Doolittle’s “I want to talk to the animals…” )

Have a productive week!


P.s. Don’t forget to register for the #LSSC11 FREE Webinar series – Feb. 2, 2011 (noon-1pm PST — 3 -4pm EST!)  Session #1: INTRODUCTION TO KANBAN with Janice Linden-Reed. Register here:


IT's all about the People, Stupid...

(Note to self: Remember Mark Twain’s quote – If I had more time, I’d have written less…)

It seems apropos to use this headline to illustrate soft skills’ importance in software development (the 1992 Clinton presidential campaign coined the originalIt’s the economy, stupid).

What do you think?  Do technology skills trump people skills in IT (this was the traditional engineering approach)?  I believe that people skills are at least as important – if not more important – than the hard methodology or coding skills.

I believe that the lack of people skills are at the root of several issues in IT today, unless you work on projects for unknown customers, such as the story this week in the NY Times: Can Apple Find More Hits without its Tastemaker:

Steve JobsShortly before the iPad tablet went on sale last year, Steven P. Jobs showed off Apple’s latest creation to a small group of journalists. One asked what consumer and market research Apple had done to guide the development of the new product.

None,” Mr. Jobs replied. “It isn’t the consumers’ job to know what they want.”

“IT would be easier without the people”

One of my first MIS projects as a programmer was memorable for two reasons:

  1. It was the first time I heard the phrase above; and
  2. My boss made a deal to get sponsor sign-off on requirements by promising that he (the sponsor) could change anything down the road that he didn’t understand.

It was a project from hell (change running rampant) and it was the first time I truly realized that we go into computer science and engineering because we are good at technical subjects, not communication.  Back then, waterfall development was essentially done “over the fence” with the business throwing the requirements over to us, we doing the design and build, and then us throwing the finished software back to the business for testing. More often than not, our “perfect” software missed the mark in terms of functionality, and was typically late and over budget.

Certainly much has changed with the new approaches – can you imagine software development without regular end-user contact?

How much rework is people-based?

CalendarDoes it surprise you to learn that software development is fraught with rework – in traditional settings it is close to 40%?  This means – literally – that we do great work every Monday, Tuesday and Wednesday, and then get to redo it all every Thursday and Friday.

Thanks to Kanban, Agile, Lean, Scrum and other customer-focused methods, our industry is getting a lot better at reducing rework, and at identifying non-productive wait times/delays from customers and others. We are also better at knowing how to deliver incrementally to customer needs. Augmenting the new approaches are job roles specifically tasked with customer facing such as business analysts, project managers and user advocates or scope managers. Some might argue that these roles are inconsistent (or even counterproductive) with Lean or Agile approaches, but that is the topic of a future post.

Regardless of approach, however, engineers and computer scientists are no fundamentally different today than they were in the days when I attended college.  We choose these professions because we love math, science and technology, have a reasonably high-IQ, and want to make a difference in the future of the world (at least that is my excuse!)  People do not go into engineering or computer science for the people skills.

Sure, there is a growing recognition that both engineers and computer scientists must have good people skills when they enter the workforce, however, soft skills training is still secondary.  Soft skills remain some of the most elusive and necessary skills in software and systems development.

(Side note: at an SEPG conference several years ago, research showed a high concentration of early onset autism/Asberger’s syndrome among Silicon Valley’s professionals.  For SEPG, this was a very controversial session that led t interesting results: 1. developers who already felt socially inept wondered just how inept they might be; and 2. others took careful notes so that they could report people they didn’t get along with to HR with the suspicion that they might be autistic. Presenters were careful to say that this research was inconclusive and PRELIMINARY.)

In my experience software engineers score high marks in technical areas but fall short in communication skills because:

  • they do not realize that they are poor communicators (their co-workers and friends understand them);
  • they see themselves as superior in intelligence to non-IT’ers, which can lead to condescending behavior (“what do you mean that you don’t know what these acronyms mean?”
  • they do not realize that both the sender and receiver are part of the communication loop (as in “I understand perfectly, it’s the business who has a problem”);
  • they value technical proficiency over soft skills proficiency (if something is not complex and technical, where is the value?); and
  • they have not taken soft skills training aside from a presentation skills course in college.

What did I miss on this list?

What are soft skills?

While I hate to quote Wikipedia, it has a good definition for soft skills (better than

Soft skills is a sociological term relating to a person’s “EQ” (Emotional Intelligence Quotient), the cluster of personality traits, social graces, communication, language, personal habits, friendliness, and optimism that characterize relationships with other people. Soft skills complement hard skills (part of a person’s IQ), which are the occupational requirements of a job and many other activities.

Soft Skills are behavioral competencies. Also known as Interpersonal Skills, or people skills, they include proficiencies such as communication skills, conflict resolution and negotiation, personal effectiveness, creative problem solving, strategic thinking, team building, influencing skills and selling skills, to name a few.

How many of these skills are explicitly taught as part of Scrum, Kanban, Lean or Agile training?  (In fairness, they were never taught in waterfall or structured analysis classes.) I know that there is at least recognition of soft skills importance with newer customer-centric methods, and I believe there is still a gap.

Are you better at presenting and communicating with users doing  Kanban or Scrum than you would be if you were involved in waterfall development?

As our industry has learned better ways of developing software-intensivScalee systems, neither our business partners nor we are well skilled in soft skills.  Accountants, marketing majors, doctors, actuaries, and human resources can also suffer from too much IQ and not enough EQ.  So, who is responsible for making sure that business outcomes, funding levels, and trust are present in the IT/Business partnership?  Both sides are definitely responsible for their own part to make things better.

On the development side, we need to recognize that prowess in terms of effective communication, knowledge transfer, people networking, facilitation, cultural awareness, etc. do not come by osmosis – we need soft skills practice and training.  When we are experts at both the hard and soft skills, our entire industry will gain – and so will our business partners.

How are your soft skills?  Here is a quick quiz:

Soft skills workshops?

It is easy to blame misunderstanding, lack of technical prowess, and poor communication on users, but IT has yet to recognize that IT’s not about the business; IT is all about the people.

Are you interested in attending a dedicated session on soft skills for technical professionals?  Drop me an email for information on my upcoming one-day IT’s all about the People workshop.

Have a productive week!



Ever had this problem in Software Development?

software development videoHave you ever felt that the business side of software development just doesn’t understand what’s involved?  Watch the short video I created (just click on the “photo” above) and let me know if this is anything like what you’ve ever experienced.

It’s no wonder that so many projects end up over budget, behind schedule and delivering a product that just doesn’t fit.  One solution is scope management.  Call or email me today for a free white paper about Scope Management (

I know the video is tongue-in-cheek but I’d like to hear your comments!

Have a good day,

Defining IT Project Success

When the annual Standish Group Chaos report is published, IT professionals wait to hear whether the “project success rate” has gone up or down.  Between 1996 (the first year of the Chaos report) and 2006, the success rate doubled from a low of 17% in 1996 to a high of 34% in 2006.  Since then the rate has deviated up or down by a couple of percentage points.

In the Chaos reports, project success is determined to be on-time, on-budget, and delivering to requirements.  I don’t agree that this is a good assessment of project success, what about you?

[polldaddy poll=4093887]



Rework, bloody rework...

In software development as in life, Rework is a standard task… the only difference is that in software development, the problem is widely recognized and remedies are sought.  When one considers that billions of dollars are spent (invested) every year on developing new software solutions, it is easy to understand how the 40% rework statistic is UNACCEPTABLE.

When I am teaching project management workshops, I explain the seriousness of rework by stating that with statistics hovering around 40% of work is rework, it means that every Monday, Tuesday, and Wednesday, the teams work diligently on what needs to be done (that is the 60%) and then every Thursday and Friday (40%) they redo what they just did earlier in the work.  “Amazing!” you might exclaim — until you realize that the rework in everyday life can be even higher!

What causes rework in software development?  Poor upfront requirements (similar to building a house without a solid floor plan), changing needs or regulations (government or corporate changes), misunderstanding (due to a lack of knowledge), poor writing and communication (or no communication), intimidation (fear of raising issues or corrections during the building process) or a number of other reasons.  The industry has worked to fix the issues with cross-training, facilitation, and user focused approaches.

Rework in everyday life

What is “rework” in everyday life?  Here are a few examples of rework in our everyday life:

  • Going to pick up your child/partner/friend at a pre-appointed time only to discover that they are not yet ready because their needs have changed (and they did not tell you). You may have to wait (wasted time) or return at a later time;
  • Having to call/email/contact someone multiple times to follow-up and ensuring that they are doing a task they committed to do for you (and often have not);
  • Having to redo something you’ve already done because the requirements were incomplete or unclear the first time;
  • Having to redo part or all of a job because something critical (like tax rules) changed part way through the job;
  • Ending up finishing a job that someone else started (this includes getting up to speed about what they’ve done to-date and potentially learning what to do before finishing);
  • Calling/emailing/contacting a group of people to track down someone who knows the status of a job that they had originally committed to do;
  • Voice recognition system “menu games”.  Rework happens when you call your bank/utility company/cell phone provider/airline with a specific question, get stuck in the voice mail menu system, finally reach a “live body” and then the call gets cut off.  You end up having to go through all the same steps again;
  • Driving somewhere according to the directions from Google maps or Map Quest and discovering that the site was out of date with the directions. You end up redoing the last steps or driving in circles before you to stop for directions and sometimes even go back home to get new directions and have to do it all again. You end up late for an appointment (which might get canceled) or miss the entire event you had planned to attend;
  • Leaving multiple voice mail messages for your son/daughter/friend/partner and then finding out that they don’t bother to check their messages more than once a day;
  • Circular / triangulated communication:  When someone complains to another about something you have said/done/not done, and the third-party tells you (adding their own spin), it creates an extra communication path.  Now you have to talk to two people instead of the original one – it’s double trouble plus aggravation to your psyche.

All of this rework is frustrating and wastes precious heartbeats that we will never get back. It disrupts our day(s), challenges our psyche and can damage our relationships with others.  While technology has minimized some of the historical rework (e.g., waiting in the wrong place before cell phones existed), and exacerbated others (text shortcuts can cause confusion. See previous post TLA’s and other acronyms).

How much of your day is spent on Rework?  At least 40% if not more!  How often do you hear people say – “I never got anything done today!”  I do not remember people saying this when I was growing up — unless there was a baby or small child involved, yet I hear this often today.  Unproductive days so often involve other people – and we can truly only change our own behaviors.  This can compound our frustration because if it was a matter of simply doing it right the first time, most of us would learn quickly (at least the second time around).

So, what can we do to cut the rework in our own lives?

Here are a few suggestions (that work can also work in the corporate world):

  • When anyone agrees to do something (even if they are volunteers), formalize it in writing or at least, verbally.  As assignments are handed out, people will often volunteer simply because it makes them look like a team player.  And then they do not follow through.  Our word is our integrity and it is critical when we delegate or ask for volunteers that we get an explicit verbal yes or no to a commitment.  When people verbalize their commitment (and sign off in some cases), their word becomes their bond.  It also confirms explicitly what it was they committed to do.
  • Ronald Reagan said “Trust, but verify.”  We need to do the same thing and follow-up on commitments non-obtrusively (e.g., “I am just checking in with you…”) and quickly.  There is nothing worse than entrusting someone to do something and then finding out — when the project is supposed to be finished — that they have not even started. Of course, miscommunication can and does happen – and this makes it even more important to see progress early, and not just before the deadline.
  • Set a series of “milestones” where you can check the ongoing progress without micromanaging.  Only when something goes awry (in terms of schedule, scope or budget slippage) should you step in and offer your help.  This, of course depends on the dependencies for jobs you are doing – if you are awaiting something that prevents you from starting, you want to be sure that things are on track so that you don’t miss your own commitments and things end up snowballing quickly.
  • Do more yourself.  If timing makes it impossible to supervise the work, it may be easier just to do the job yourself;
  • Create backup plans.  This unfortunately is the way of the world today.  While it is rework in itself to have to create backup plans when none should be needed, it is the status quo.  When people create repeated delays, you may need to do this just to keep up your own sanity!
  • Be direct. Talk to people directly instead of hiding behind emails or voice mails to get through to people – and emphasize how important it is to communicate about reality (e.g., if someone says they need a ride at 9 pm, let them know that they need to call you by 8:30pm if the pickup time has changed).  Do not talk around people (i.e. go behind their backs) if you want to keep up good team relations.
  • Find another way. Sometimes the way things have always been done is not the best way.  Einstein said, “Insanity is doing the same thing over and over and expecting different results.” The same is true of processes where rework is typically high.  Change something in the process.

What Would Reducing Rework Mean in Your Life?

When you consider that most of us do not have enough time in our already overburdened and over-committed days, what would it mean to have 10% more time?  If we could cut rework by changing our own behaviors – would it prove to be a worthwhile cause?  Imagine if rework could be reduced 20% or even further?

What do you think can be done about rework?  What has worked for you?  I am interested in hearing what you have done to minimize your own frustrations and cut rework in your life.  Insanity (as quoted by Einstein) is doing the same thing over and over and expecting different results.

Let’s stop the insanity.

Please comment.


No Communication Sends a Message... (and it's usually not good)

In these past few weeks of blogging about Communication for PM’s and Techies, I realize that there are situations where No Communication sends an even LOUDER message.  You probably already know what no communication means (we’ve all been victims of the “silent treatment” at one point in our life!) – but it also means a negative view of what will be the outcome of communication.

Here’s what I mean by the first interpretation of “No Communication” and the messages it sends:

  1. Avoiding communication:
    After a negative interaction with someone (criticism, conflict, discomfort, intimidation, or other non-positive interaction), it can be difficult to talk to the person the next time.  As time passes, a continuing lack of communication can amplify the original discomfort – it just doesn’t feel good to undergo the initial encounter and we don’t want to experience it yet again.  If the original situation was verbal or in-person, subsequent communication often ensues in a more distant way such as email.  Often the offensive party doesn’t even know that they caused the situation in the first place and is unaware of the ongoing angst.
  2. Eliminating communication:
    We do this when we block incoming phone calls or divert unwanted emails to trash.  Sometimes this is a good stop-gap measure to prevent unwanted communication until it eventually stops all together.  While this is a good tactic to prevent communication, it sometimes backfires by escalating into more direct forms of contact before the sender gets the message you do not want to communicate.
  3. Ignoring communication:
    Instead of avoiding or blocking communication, we also sometimes ignore incoming communication through call screening, letting calls go to voice mail, leaving emails unopened, and simply not responding.  While this may be an appropriate coping mechanism with personal situations, it does not work well in a corporate environment when you are expected to communicate effectively.

In all the above situations where NO communication is sent, there is a perceived “clear” message that is sent regardless of the lack of words. To the person on the receiving end of the avoidance, blocking or ignorance – there is a message they receive.  They will make their own judgment (based on their own perceptions) about what they think is happening, and then typically come to the wrong conclusions.  “Perception is reality in the absence of fact” is an adage that certainly bodes well when there is no communication exchanged.  One such flawed conclusion could be that the original message (that caused the problem) was never received or was interrupted.  If this is the perception, then the person on the receiving end of the “no communication” may resend their message or escalate the attempts to communicate and send increasingly urgent (and sometimes event abusive) messages back to entice a reply.  We might say that “They’ll eventually get the message”, but unfortunately this does not always happen.  When we want to communicate with someone who does not want to communicate with us, we sometimes become quite dense.  The best communication is always active communication rather than passive non-communication.

There is a second interpretation of what no communication means. It can be the pre-conception of negative (i.e., No means negative) outcomes or envisioning a negative result.  For example, if I am going into a meeting where I anticipate a negative outcome and express such sentiments to co-workers beforehand, it is likely that the outcome WILL be negative.  The saying, “if you think you can or you think you can’t – you’re right” – ties into this.  Envisioning and verbalizing negative communication outcomes is like a self-fulfilling prophecy before the fact.  Why not envision potential positive outcomes and then making that happen?  It won’t necessarily change what happens in every situation, but aren’t a few positive outcomes a good reason to change your outlook?

It really can work – envisioning a positive outcome to a tenuous communication can give direction and a positive boost to upcoming meetings and interactions.  Why not work towards the positive instead of the other way?

Remember, no communication delivers a message all the same – and it’s usually not good or lead to a positive outcome.  Plan to communicate by communicating effectively.

To your positive interactions and communication!



ABZ's of Communication for PM's and Techies...R: it's all about Relationships and Rework

As we talk in the grander scheme of overall corporate communications, it all comes down to


Two different concepts but related as we’ll go into later.  Let’s start with RELATIONSHIPS.  If someone likes you and respects you, they will listen to what you have to say. If they don’t for whatever reason (that may or may not have anything to do with you!) – then getting them to listen to you will be an uphill battle.

Beca Lewis said:

“Yearn to understand first and to be understood second.”

This ties into a recent blog posting I discovered called “3 Deadly Sins of Business Relationships” by Diane Helbig.  The highlights of the post were that so many people go to networking events with an end goal in mind and in the process discard the importance of building the relationship first.  I know many of these goal-driven people (they are colleagues who brush past me on their way to the “kill” or prospects!) – they go to an event to get a preset number of qualified leads and work their way around the gathering like a fox on a hunt.  They are interesting to watch as they scope out their prey, approach the prospect, exchange their card, make their pitch and within 1.5 minutes move on to the next potential buyer in the room.  Often these “movers and shakers” end up leaving the meeting with what they consider to be a treasure cache of business cards – and think their time was well spent.

I’ve always approached networking functions with a different and likely less overall successful strategy – I simply like to meet new people.  People like me,  people who are different, people who have problems and opportunities and challenges and who are simply out to meet others.  At the end of the evening, it is as likely as not that I will have met a few new acquaintances and exchanged information.  Often it is simply a pleasant exchange whereby I’ve given them some information or a new idea that might further their business.  In the big karma bank of life, I might be truly naive in thinking that goodness given is repaid somewhere somehow when I need to make a withdrawal from the karma bank.  Certainly this is not a sales-focused approach, nor has it gained me any direct business ever!

I find the same situation arises when I attend or speak at major industry conferences. Perhaps I should have mined the lists of attendees, scoped out prospects and gone in for the leads, but that’s just never been my style.  Over the years, many colleagues have asked me why I bother to talk to people who won’t give me business – and my answer has always been that I genuinely like to meet like-minded people and that is satisfaction enough.  I believe that many of the contracts that I’ve gotten through word-of-mouth have come to me simply because I did not pursue people for their buying ability – and instead talk to them as people.

Read the 3 Deadly Sins of Building Business Relationships and let me know if you like it as much as I do!

Next posting – Rework and how much effort (and waste) it takes in communication.  Just this week alone, I’m quite certain that 1/3 of my time was spent on emailing people, following up when they didn’t answer, emailing yet again, calling and leaving voice mails and then still doing more.  What a total waste of time and energy chasing rainbows and promises that don’t deliver in the end!

Wishing you great relationships in all aspects of your life – and the communication success that comes from putting relationships before leads!


TLAs, Emoticons, and other Communicata...

textingTexting has gone viral and with it has come a veritable flood of TLAs and FLAs (three-letter acronyms and four letter acronyms), shortcuts, and emoticons.  When it comes to acronyms, it’s no big surprise to us in the IT (information technology) industry – we’ve been inundated with acronyms since IT was first coined.  (I remember smiling years ago when a “senior” consultant I worked with in Telecommunications asked why we’d capitalize ‘it’.)

Most niche industries use acronyms as a communication short-cut.  But acronyms also create confusion and communication obstruction when used outside of their knowledge circle, with few exceptions.  One exception I can think of is the universal acronym is “Rx” (short form for Radix, the derivative of Prescription) — seldom is this shortcut questioned or confused.

The same cannot be said for other acronyms. Take AMA for an example… this is used variously to mean the American Medical Association, the American Marketing Association, the American Music Awards, the American Management Association, the Alberta Motor Association, and others.  So when you see the acronym AMA – what does it stand for?

acronymsI got caught in an acronym fiasco yesterday – unwittingly!  I got a call and spent an hour on the phone with a prospective client who was looking for someone with exactly my “ISO” standards experience.  (I’ve been on the US delegation to ISO software engineering standards since 1994, both as a project editor writing international standards and as a national subject matter expert.)  The client told me that her firm had recently acquired a contract to provide insurance software to ISO and she knew that they would have to comply with all necessary ISO standards.

The hour-long discussion turned out to be for naught – the ISO she was looking for was the Insurance Services Organization, not the International Standards Organization (based in Geneva Switzerland) to which my experience pertained.  In retrospect, the conversation reminded me of a scene out of the old situation-comedy “Three’s Company” (which was a weekly satire filled with double entendres!)  Here I was talking about ISO standards as they might pertain to insurance (and knowing that insurance is both state regulated and nationally regulated… AND it did seem strange that an US-based insurance software company would be retained by such an international entity.  Nonetheless, I played along…) — and the firm was looking for someone in the Insurance Standards Organization based firmly in the US.

In software development, acronyms are commonly used to name software systems – and we even joke about having acronym naming meetings whereby a team creates a seemingly sensible system name to fit into a clever acronym like “ACES” (Access Claims Eligibility System).  Ultimately, the clever long form meaning is lost once the acronym is in place, and people then only remember the acronym.

Certainly, acronyms can shorten redundant and repetitive phraseology – but they do not make sense if they introduce communication barriers.  Texting shortcuts cause the same situation – if someone has to spend extra time figuring out what you are saying, you are NOT communicating.  LOL (laugh out loud), Gr8 (great), 2morro (tomorrow), L8R (later) and other shortcuts sometimes save only a couple of keystrokes so one wonders why they would be used.  In some cases, I’ve seen writings where scholars fear the dumbing down of America through texting.  They wonder if texters will lose their ability to spell (if they knew how to do so before they started texting…)

Emoticons serve to create more casual bonding between texters.  <>():- ; and other punctuation marks serve to create emotion signals and sometimes even show up in once formal written business correspondence and emails.  With emoticons there is not as much danger in being misunderstood – rather it is the introduction of “casual” language into traditionally formal settings.

If your industry needs to create an acronym dictionary to decode the meanings of the many shortcuts in use– then things may have gone too far.  Acronyms, abbreviations and other shortcuts should enable communication — not trip it up.

To your communication success!

TTFN (ta ta for now), TTYL (talk to you later), :-).