Recently I've got a question from a colleague: "Have you had a situation when somebody was trying to manipulate you  or your behavior? What can be the best way to stop/resist this sort of attitude? Stop any interaction with the person?" From my perspective manipulation, generally, has to aspects to it:

1. Other person wants you to do something (which is not necessarily a bad thing).
2. She wants to make you do it in a sort of "covert" way, which I would generally call a bad thing in professional environment.

When it comes to response to manipulation, all things being equal, I would have a conversation with a person saying something along the lines of "Hey, I've noticed that you try to trick me into something and don't like you doing that. If you need something from me, let's discuss, but don't try to trick me."

This kind of feedback serves two purposes: (a) letting other party know that you've noticed manipulation and don't like it (who does?); (b) showing a better way to do business with you. If a case is not helpless, this should help.

What do you do when somebody tries to manipulate you?

When I'm asked a question, my reply often is "Well, there are two answers to that question: a short one and a long one (or a simple and complex)..." And that is because there are indeed two types of answers to many questions. I would call them definitive and process oriented. For example, "how long will it take to complete this project?". The simple answer might be "we do not know", the complex answer will be "we do not know, but here is how we can control and manage schedule for our project and make it possible to make certain commitments on dates depending on your goals".

Another perspective on these answers is that one of them is like "here it is" and another one is "oh, here is how you get it".Remember that saying that professionals do not always know all the answers, but they always know how to find what they need.

The matter of fact is that process oriented answers are just as important as definitive replies. Of course, we should always starve to simplicity, but if there is no simple solution, we should not abandon looking for complex ones.

...People respond with heroic behavior. And when they act heroically, they stop improving. They just act heroically again, again, and again, and they stop learning.

David Anderson in interview for Software Engineering Radio.

I'm reading Garr Reynolds' "Prezentation Zen" and his points about efficiency of presentations, which can naturally be translated into efficiency of communication, resonated with my mind:

The presentation would have been greatly improved if the presenter had simply kept two questions in mind in preparing for the talk: What's my point? And why does it matter?

Now communication is more important than ever for me, since I work on-site with client and do not have luxury of face to face communication with my team. Should I be asked to generalize Garr's statement I would do it this way:

The communication would be greatly improved if the person speaking now would simply keep two questions in mind, when preparing to speak: Why my speech does matter? And what is my point?

I have heard dozens of perfectly made points, which unfortunately were not relevant and simply consumed the bandwidth. Alas bandwidth of communication is more limited than we usually think.

Keep that in mind and be an effective communicator.

Today I had an inspiring chat with one of fellow QA engineers about one of the systems we recently developed. I had a new requirement in mind that triggers complete re-test of the system.

Me: How long does it take to re-test our solution?

QA: Any new features or components?

Me: No, "just" another communication protocol.

[caption id="" align="alignright" width="180" caption="Great job!"][/caption]

QA: Give me 10 minutes, I'll consult with the Test Plan and Design.

Me: ...Ok.

And if initially I was going for really quick and dirty estimate, I just could not make myself ask for that. I've got my needs under complete control of a professional.

Professionals feel responsible for everything they say to you, their internal code of conduct just does not allow them to fool you or compromise quality of their advice, even if you ask for it.

Professionals, unlike amateurs, will always ask you for what they need to deliver you the best possible result.

They are near you, just look around.

Be reasonable with your requests. Be reasonable with your responses. Human actions (at least, in professional and business fields) are mostly driven by reasons. People never (or very-very rarely) do something out of spontaneous wish at work.

Yes, you can have a spontaneous idea, but it, anyway, will serve some particular purpose. Idea tries to solve a problem, and the is the reason why you do that - you want right the wrong or make something better.

Often times in order to do what you want to accomplish, you will need to request something from your fellow colleague. Usually, you will need to have it done by certain deadline. This is where the interesting part begins.

You know exactly why you want something to be done by certain date or time. But are you sure your fellow colleague, from whom you request, comes to know that by reading your e-mail? Does he get why this needs to be done today? Is it in any way more important than what he is working on now? Unless he is a powerful mind-reader the answer to all such questions is "No!". E-mail just does not bear with itself enough of  the mental energy to discover all of that!

Do you want you request to be handled in the best possible way? I bet you do. So, be reasonable. Write you request in a best possible way. Explain why there is a need to do something and why deadline is such as it is. Do not send unreasonable requests!

Same line of thought applies to responses. And even if you receive an unreasonable request - there is a reason why it went out. Help the requestor. Ask him questions. Unreasonable response will just turn into a dead-end. Often quickly bricked up behind your back while you drive there.

Do your best to explain your reasons and understand reasons of others. If you are not sure if you were understood correctly - follow-up your e-mail with a call.

And be reasonable with what you write and what you say.

When people communicate they exchange facts, ideas and opinions. When they hear something which is not a sure fact like "At present, Earth orbits the Sun" they will either agree or disagree. As Paul Graham suggests this is a natural behavior. But disagreeing itself is somewhat simple: nothing remains after the conversation except for changed or not unchanged mind of participants.

[caption id="" align="alignright" width="180" caption="Opposition"][/caption]

When people hear idea or proposal it is another beast. Something is going to remain after the talk is finished and that is a decision whether to proceed with presented idea. And that decision, be it positive or negative, is going to affect everyone involved in a conversation. As Paul noticed

Many who respond to something disagree with it. That's to be expected. Agreeing tends to motivate people less than disagreeing. And when you agree there's less to say.

Only very bad ideas will not ignite discussion. If the idea is worth at least something the conversation will start. The conversation will start with disagreement and critique and will revolve around the problem idea tries to address and the idea itself.

The worst form of critique which often can be a "discussion killer" is when the reply is "This is not going to work" and nothing more. There can be several cases why one would say that and actual meaning of that response can range:

• from "Hey man! You are so stupid to propose this. Your idea is not even worth discussing."
• to "Dude, I had thought this idea in and out and you really do not want to implement it" and "The problem you are trying to solve isn't really a problem. Let's move on to the next item."

No matter what the actual meaning is expressing it with "This is not going to work" is wrong. You must uncover reasoning for "not going to work". Such unsound responses kill all the constructive outputs that can arise as a result of conversation on the topic. Such responses create forces which oppose to development of better outcomes for the concern raised.

Good response would be something that will help arrive at conclusion that will be both acceptable and accepted by all the parties engaged in the conversation. Something that will prompt for further discussion is already good enough, e.g. "I do not clearly see the benefit of implementing this. Can you please explain in more detail?".

When discussion starts it is important to distinguish two things about the proposed idea:

• problem the proposal tries to address
• the idea itself

First of all there should be an agreement on why dealing with the problem is or is not important. With readiness to attack the problem you can move on to define a solution to that starting with proposed idea. Once the problem is revealed a solution should be found. The solution might be completely different from what is proposed now, but there should be one. And only constructive dialog that gradually improves currently proposed idea can deliver that.

Jim McCarthy calls this a "better idea" approach. To quote Jim:

An accountable "No" is respected, but it's got to be accountable.

You can say "No", but no, you can't go away without a better idea. Because if you don't have a better idea, then that's the best available idea and you always act on the best available idea. You can always change it tomorrow, or next week if better ideas come around. But, by definition, if you don't have a better idea, you have to vote "Yes". So when you stop the show you are expected to carry the next vote, which happens immediately. And this makes people say "No" much less.

Mind how you respond to ideas of your fellows and be accountable for what you say. Let ideas emerge and be implemented.

Leo Babauta of Zenhabits describes an interesting concept of pigeonholes in interpersonal communication. My personal experience with this suggests that there is always a hassle that stops people from changing for better. Changing for worse usually happens gradually and unconsciously; and when it is conscious (I can not imagine that, but still) you do not care how others perceive you anyway. Changing for better is in most cases a conscious action and involves a great deal of thinking. Here perception of you by others is important.

Unfortunately, often the first reaction to change in you (or in other words you trying to change a pigeonhole) is suspicion. Why would he wonna do that? Is he going to fool us? And you really need to get through this. One of the better options to do that is to get an alignment of a person you trust. With her belief in your new personality and her support it would be easier to convince rest of the world that it is not about them being fooled, but about you becoming better.

Beware that when you want to move something from one pigeonhole to another you need to pick it up first.

Many years ago when I was at school I was serious about orienting. Once I even was 3rd in national championship. And the trainer always told us "Stability is a sign of mastery". No matter how fast you are on the training you've got to be able to repeat this result in real competitions throughout a season. Also you've got to be proficient with basics of the sport - you can not succeed without consistent results in long-distance racing. And no one in your team is going to take you seriously if you say "This will be my showtime" when your results record is like a wave of highs and deeps. When you are developing a software product you, first of all, run against your competitors on quality. And you will only be able to succeed if you can deliver consistent level of quality. Consistent external (perceivable by your users and customers) quality can only be achieved through stable internal (visible to your staff) quality. Of course, miracles sometimes happen and you can get a decent quality product without maintaining internal quality metrics. But you will never able to sustain this quality before you get internal processes and practices right. (By the way, if you think you've managed to do that, drop me a note -  I would love to know how it worked).

Jason Yip got a great quote on this from The Practice of Programming:

Consistency leads to better programs.  If formatting varies unpredictably, or a loop over an array runs uphill this time and downhill the next, or strings are copied with strcpy here and a for loop there, the variations make it harder to see what's really going on.  But if the same computation is done the same way every time it appears, any variation suggests a genuine difference, one worth noting.

Master your skill and deliver quality everyday even if no one notices that. And once you need to do your best you'll do that as you always do.

If you haven't read Founders at Work, you definitely should. Reading this I've enjoyed every page. Probably this book is more about "experience sharing" than any other book. This book has 33 co-authors each sharing his insight into key components of success. I just could not resist posting these words of wisdom of Steve Wozniak:

Livingston: What is the key to excellence for an engineer?

Wozniak: You have to be very diligent. You have to check every little detail. You have to be so careful that you haven't left something out. You have to think harder and deeper than you normally would. It's hard with today's large, huge programs

By the way the whole interview with Steve is publicly available. Take your time reading it.