You debug programs, I debug people

Every day at work, a few colleagues and I will chat over the lunch table.  Usually it's just small talk, but sometimes the conversations get rather deep.  (BTW, I love it because it gives me ideas to blog about!)

The topic that came up today was "solving engineering problems vs. solving people problems".  My colleagues were defending that people are very much harder to deal with.  However, I had a rather different view.  I argued that people are not much different than programs, in that people's actions are also consistent with their belief systems, much like a program does what it's designed to do.  Yes, people will carry some variability (or volatility!), but usually if you can grasp the "root cause" of what makes a person tick, debugging people should be no different than debugging programs.

And of course, this sparked a healthy debate.  I find this fascinating!  Looking back at my own education and career, I also believed that engineering problems were easier to solve than people problems.  After all, that's why I became an engineer, and not a politician.  But as my career progressed and I was exposed to more people and customers, I realized that there was a pattern to people, not unlike engineering systems and programs.  Yet this realization, this ... sense of confidence that people can be managed ... I don't recall any course in college being able to address this, at least at the undergraduate level.

Imagine what world we would be in, if fresh graduates were college were equipped and armed with a solid base of people management?  (Yes I agree that people management skills improve with maturity and age, but I'm only referring to basic knowledge such as "if-this-then-that" logic and skills.)  Entry level jobs, such as front-line customer support reps (which was also my first job) would be so much more effective in handling customer complaints and objections.  Businesses would gain customer satisfaction, and skilled engineering graduates wouldn't have to retreat to a reclusive role, as in, "Oh I think dealing with people is just too hard for me, I think I'll join R&D and code all day and not talk to people."  It's a win-win, both for the employee and for the business.

Academically, engineers are well trained in problem solving.  Transferring these problem solving skills over to people management isn't hard.  You just have to see the similarities.  I hope to share more case studies in the blog post to come.

Effective communication for engineers

Ok so I'm an engineer.  I studied engineering when I was in college, like many other students.  I chose engineering because it's fun, and I get to build things.  But one thing I've noticed about engineers is that, we're not really known for being great communicators.  When was the last time you saw an engineer giving a TED talk?  (Ok that's not really fair, there are plenty of good TED talks hosted by engineers, but you have to admit, out of all of the TED talks that's only a small percentage.)

Not to be stereotypical about engineers, but there is some truth to this.  How many times have you sat in a meeting with an engineer presenting, and he/she goes on and on about you know, current progress, challenges and obstacles, technical jargon, but not really making a point?  Maybe it's just you ... you went to bed last night late, you didn't get your coffee this morning, and so you think, "Maybe it's just me that's tuning out."  But you look around, and everybody in the meeting room is tuning out.  Colleagues are unattentive, playing with cell phones, checking stock quotes or last night's game scores, or even just dozing off.  What an unfortunate waste of time!  The presenter, with all good intentions, failed to get the point across.  And think of the time investment from the presenter to prepare, as well the cumulative time investment by the meeting attendees.  Communication skills should be a basic cornerstone of all academic areas, and I don't think most engineering curriculum have put much emphasis on this aspect.  Furthermore, in today's modern workplace with remote meetings and skype calls, we are faced with even more obstacles for effective communication.

Luckily, there's hope.  I'm not trying to turn everyone into Steve Jobs, the master puppeteer who can control emotions from the audience at his whim.  I'm saying with only a few small changes, you can raise your communication effectiveness from 40% to 80%.  Key points:

1. Use less words, not more.  If a picture helps, use it.
2. Apply structure to the meeting agenda.  For instance, the PPOC structure is fairly popular (Purpose - Plan - Outcome - Check)
3. Is your information valuable for the audience?  What is the main point that you want them to take away?

I could go on and on, but these are my 3 main principles, and they've worked for me.  It's as my high school teacher said, "If your paper does not have a clear thesis statement, then everything else will fall apart."  So challenge yourself.  Next time when you host a meeting, ask yourself, what's your "thesis statement"?  If you don't have a good answer, chances are the meeting participants won't have a good answer as well.

Inaugural Post

The saying goes:

You don't have to be great to get started, but you have get started to be great.  I've been meaning to start a new blog for a long time, but I've been stuck with analysis paralysis.  This quote gave me the jump start I needed to start this blog, and now here I am.  I hope this blog will be valuable to my readers, as I know it will be very valuable for me.  Please stay tuned.