The engineer’s curse

Its a rare luxury this week as I have the house to my own. Perhaps those of you with partners and or younger kids will identify with this sentiment! Suddenly life seems to be easy and manageable. I don’t feel responsible for looking after other people and their problems. The challenge to manage a house, be a mother and partner, run a business, organise a conference and oh yeah, do some testing is a lot easier when its only yourself to look after!

When I took PSL last year, one of the ‘skills’ I realised I had was running around making sure everyone on the team was being heard and was ok. Another word for this is meddler. How, I thought could the team function without me, unless I was there to keep it together?

I guess after reading the first paragraph again work isn’t the only place I fall into meddling.

In a moment of retrospection, I feel my desire and ability to solve problems is sometimes more of a curse than an asset. Perhaps in my drive to solve problems, I forget something crucial. That is, often it’s not about solving a problems its about having the conversation.

Earlier this year, Michael Bolton introduced me to Marshall McLuhan and his concept that “the message is the medium”. Is it possible then, that solving a problem is not as important as the process used to solve the problem? Or in other words, the conversation you have to solve a problem, is more important than the resolution of the problem you are having?

A while back I read David Bohm’s book “On Dialogue”. In it, he encourages groups in dialogue to take the focus off decision making and instead put the emphasis on the process of communication.He encourages participants in the dialogue process to suspend judgement and be open to what emerges from dialogue. In this way a group can develop deeper meaning. For example, instead of trying to create a common terminology, common terminology becomes created.

He also talks about the challenge in problem solving. Mostly, what we call ‘problems’ are in reality paradoxes and inherently its impossible to solve such ‘problems’. Bohm believed that the dialogue process(I haven’t tried it) is a way of acknowledging and respecting differences allowing new ideas to emerge.

We all have a basic need(well I like to think we do!) to connect and understand each other. To be *human* if you will. Its this human need, at a tacit level that perhaps defines who we are, more than any high level problem solving skill dictated by our frontal lobes. As an engineer, I’m taught communication is essential to solve a problem. As a human, I’ve learned that its about taking the time to include people in your day, to actively listen regardless of the outcome.

Just a thought.

Straight up, no ice….

You know the way sometimes, a post, or even a comment on a post gets you thinking. A recent comment by Phil Kirkham on Georgia Motoc’s blog got my subconscious brain working overtime. So much to the point where I feel compelled to put finger to keyboard and write about it.

I had always been a fan of positive praise before negative feedback. As the bearer of bad news (like many software testers), I though this was an effective way of cushioning the impact of what I wrote or said.

So, when Georgia Motoc wrote  a post on feedback discussing the ‘Praise Sandwich’ I was surprised how negative Phil was on the approach. However his comment and  his link (indirectly to a post by Art Petty ) really got me thinking of how I communicate with developers. It made me realise that the positive feedback I was providing was more for my benefit than for the software developer.

Here is some Art’s original post:

5 Reasons Why the Sandwich Technique is a Truly Bad Practice:

  • It is a crutch that is solely for the benefit of the giver, not the receiver.
  • It obfuscates the real message.
  • It confuses the receiver by watering down the key message.
  • It destroys the value of positive feedback by linking it with the negative. Don’t forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.
  • It is insulting to the receiver and borderline deceitful. “Bob, you did a great job on XYZ, but .” It’s like a pat on the back followed by a sucker punch followed by another pat on the back.

I have a real reason why I have changed my attitude to this:

When I’m on a short term assignment (which is often)  I don’t have time or the need to cultivate deep relationships with software developers. What is important is that the bugs I find are communicated in a clear and concise manner. That’s what I am paid for.

The praise sandwich is not necessary and more importantly it does not provide best value to my client.  This is something I learnt on James Bach’s course and has stuck with me. What ever you do ask yourself, “Is what I’m doing right now adding value for my customer”.