I Sense My Strength Being a Weakness

Today a person who works for me asked me how I made decisions.  His observation was that sometimes I seemed quite conservative, but he had also seen decisions which seemed quite bold.  As I listened I was glad to not be pegged one way or the other (conservative or a risk-taker), because different decisions are made within a context, and sometime the context dictates the amount of risk you can handle.  I asked for examples of bold and conservative decisions he had seen me make.  The example of a bold decision allowed me to give one of my favorite leadership quotes: “Don’t be afraid to take a big step if one is indicated.  You can’t cross a chasm in two small jumps.” – David Lloyd George. 

In trying to give an insightful answer as to how I make decisions, I explained that sometimes a person’s greatest strength can be their greatest weakness, and that is true for me and affects my decision making.  I have very good intuition.  I’ve know it for years.  I often have that blink moment when I quickly size up a situation and have insights that were unconsciously obtained.  By assessments are usually quite good.  My intuition is a significant strength of mine.

But it is also a weakness if I let it be.  Intuition is a great partner for data, but not a good substitute.  If a decision can be made with hard data, I’d rather use the data.  Because I have good intuition, I have to be vigilant to not make decisions as quickly as my intuition makes an appearance.  I have to slow down my decision making to collect data.  This is how I operate then, making data-driven decisions by intentionally muting one of my strengths.   By collecting data and then supplementing it with my intuition I make many more good decisions than bad, and would definitely rather be 85% correct relatively quickly than 98% correct at a much slower pace.  Head in the right direction and adjust.

Situation, Behavior, Insult

Giving direct feedback can be difficult, especially if the feedback is in an area to improve rather than affirming an area of strength.  When we give direct feedback poorly, what I have seen most often is either that it is rambling (“The other day were in a meeting and I know you are under a lot of stress and you probably didn’t mean it the way it sounded so I wasn’t offended but I wanted to mention it but it’s really nothing”) or it is accusatory (“Just wanted you to know I thought you acted like a real jerk in the meeting yesterday”).

The Center for Creative Leadership (CCL) has a tool for giving more effective feedback called SBI (Situation, Behavior, Impact).  The tool is intended to be a guide to help you give constructive feedback that is (hopefully) well received.  The Situation is a factual description of the physical context of the occurrence. There should be no embellishment or analysis – it is just the situation in which the even occurred.  The Behavior is a factual description of the observed behavior.  There should be no attributing motivation.  Adjectives are dangerous here.  Just the facts, Ma’am.  The Impact is where you get to describe how the behavior, in that situation, made you feel.  The idea is that by describing the situation and the behavior in a non-judgmental way, and by describing your feelings in a calm and clear fashion, you can help the SBI 

recipient grow, by helping him or her have a better understanding of how their words and action affect others.

An example of a bad SBI: “Tuesday at the status meeting you said ‘I, I, I’ about 30 times because you were taking credit for the team’s work and that made me feel unappreciated.”  There is intent and motivation in the situation - you were purposefully trying to take credit.

A good SBI: “Tuesday at the status meeting I heard you say ‘I’ much more than “we” and that made me feel like the team was not being acknowledged for our contributions.”

We have been practicing this on each other where I work.  We’ve done training, have shown good and bad examples and have practiced giving fictional SBI’s to each other before rolling out the real thing.  We also have a person assigned to keeping track of SBI’s (we ask that they be written until we get better at them).  We are finding that more than 90% cross the boundary into accusatory language.  9 out of 10 of them use those dangerous adjectives when describing the behavior.  And we are seeing defensiveness or sometimes anger on the receiving end.

I believe there is a pattern to these poor SBIs.  We have written them for ourselves.  We treat them as cathartic, as a way to get something off our chest.  As long as we write them for ourselves, we don’t care so much how they are received, because that’s not really the point.  But when we write them to serve someone else – to help them grow, to give them the feedback perhaps no one else is giving them, we are less likely to use the kinds of words that make people react poorly.  When we give feedback, we should think about our motivation.  If it is not to help the receiver grow, we should consider waiting until it is. 

To paraphrase Joseph Marie Eugène Sue, “An SBI is a dish best served warmly.”

I TOLD You I was Ineffective!

There are those among us who love to say “I told you so.”  We get great joy from those four words.  To us it means “I was right and you were wrong.”  It means “You should have listened to me.”  It means “I analyzed the information and reached the correct conclusion and you did not.”  “I won.”

When we are in a position where we could say “I told you so” (hopefully we don’t actually say those words), we should not view it as a success, but as a failure.  What it means is “I had valuable insight and I failed to convince you to listen to me.”  It is a failure of communication and one that, if it is a pattern, represents a critical limitation.

Our goal at work is not to be right, it is to be effective.  I don’t want to be right, I want to be successful.  That means both not needing to be right all the time being able to convince people the times when (usually because I have seen or done the same thing before) I know I’m right.

A mentor of mine used to say “my keys to success are hiring people who are smarter than I am and give them good tools.”  It’s not quite that easy, but his statement indicates he did not need to always be right.  He wanted to be effective.

If I am a person who regularly has “I told you so” moments, I should do a retrospective on the situation.  Talk to the people I was unable to convince and ask them these questions:

• Was I clear in presenting my opinion?

• Did I present the data in such a way that my conclusion seemed to follow logically?

• Beyond the facts, was there something in the way I communicated (my style) which presented a barrier to your agreeing with me?

• Was there some other factor which made it hard for you to agree with me?

The answers may help me advance from being right to being effective.

Revisiting an Old Adage

When I first started managing teams (top songs of the day were sung by Belinda Carlisle, Debbie Gibson, Tiffany and Jody Watley – those were dark days), I was told to always “Compliment in public, criticize in private.”  It was so intuitive to me that I did not question it.  It made great sense. 

Compliment in public to build one another up, to let the person and his or her coworkers know they are appreciated.  Compliment in public to motivate others to get such compliments and to help shape an overall positive culture.

Criticize in private to minimize defensiveness, to avoid embarrassment, to improve communication (it’s hard to listen when you are focused on how you are being perceived by coworkers).  Criticize in private to improve the chances of this being a teaching moment, and not just a complaining moment.  Sometimes the few minute walk from the site where the issue occurred to a private place to talk is precious, as it gives time for reflection, for tempers to ease, for getting a right attitude.

It all makes sense.  But I do not strive to adhere to this all the time.  Not anymore.  Sometimes I do criticize in public.  I try to be intentional and I pay attention to my prerequisites.  Here are some reasons for criticizing in public:

• Expand the “teaching moment” from the individual to the entire team.
• Model giving direct feedback to the larger group.  This is not only how to do it well, but having the courage to do it.  This is especially effective if the person on the receiving end takes it well.
• Ratchet up accountability.  The important balance is to make it OK to fail, but not OK to consistently miss commitments.  Freedom to fail is critical for innovation.  But in a product-based business, everyone needs to understand the strategic and tactical goals.

Below are my prerequisites.  When I am at my best, I am being intentional about going through this list in my mind.

• Assess the criticism.  If it is a personal matter like body odor or inappropriate dress, that needs to be taken care of in private. 
• Understand my motivation.  Why am I about to bring this out in front of the larger group?  Make sure I am not chest-thumping or acting out of anger or vengeance.  If I do not have the good of the individual and the team at heart, I should wait until I do.
• Have trust.  If the individual and the team do not trust me, we are not ready.  If the individual and the team do not trust each other, we are not ready.
• Know how to deliver the message cleanly.  Be specific, do not dredge up the past, talk about the action and avoid adjectives.

There is more than one way to build accountability.  I favor peer accountability as I think it leads most directly to high-performing teams, develops a positive culture and identifies leaders.  Bringing out issues in the public setting - when done intentionally and for the good of the team – can be an effective way to model peer accountability.

The Genius and the Vaudevillian

There are two quotes which, when considered together, give great insight into why we continue to make the same mistakes as past generations, and why we do not advance as quickly as we ought.  This stagnation and these missteps happen in management, economics, science, software development, testing, psychiatry and medicine.  One quote is from a scientific genius.  The other is from a vaudeville performer (although he was much more than that.)  One quote suggests a problem, the other states the implication of the problem. 

The first quote is from Max Planck, Nobel Prize winner and father of Quantum Theory:

“A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it”

Although he was speaking of "scientific truth", I believe this is insightful far beyond the realm of science.  

The second quote is from Will Rogers, an Entertainer at the turn of the early 20^th century:

It isn't what we don't know that gives us trouble; it's what we know that ain't so.

Each of carries around our set of “truths” (you have to start somewhere), and these form our world view from which we make our decisions.  Some of these truths we have arrived at independently through our direct experiences.  Other truths we were told and we accept.  Some of them really are true and some are not.  Mankind has never lacked for “experts” stating with great authority things that just “ain’t so”.  The more these falsehoods are accepted and acted upon, the more they impede progress.  There are obvious examples like believing that the sun revolves around the earth hindering astronomical advancement, and more subtle examples such as false belief in what motivates professionals hindering true advancement in management.

We all have our world view. We should take time to think about our core believes, and question them.  They impact us and those we influence; they are too important to be based only on what others have told us.  

On Heroes and Interviews

When I started my career in software development, “heroic effort” was a compliment.  It meant a developer went above and beyond normal hours and “burned the midnight oil” to get a task done.  It meant he or she prioritized work at the top of the list and let other options and responsibilities fall by the wayside in order to get results.  It was indicative of a “can do” attitude.

For years now, heroic effort in the context of software is not a compliment.  Or at the least it’s a back-handed compliment.  It usually comes with suggestions of poor planning, poorly designed code, of an immature development process.  It leads to poor decisions which lead to poor quality.  That’s one reason not to use the word “heroic’ to describe software development activities.  Another is the fact that with a war going on, we have real heroes in our armed forces.  They are involved in life or death struggles; I don’t want to cheapen the definition of a hero.

But there are software development activities we ought to celebrate.  The word that comes to my mind is noble.  Webster defines noble as “possessing, characterized by, or arising from superiority of mind or character, or of ideals or morals.” Examples I see of noble behavior:

·         The software developer who doesn’t settle for mediocrity, but strives to be a craftsman

·         The tester in waterfall environments who seems to always find her schedule squeezed at the end of projects but doesn’t let frustration affect the quality of her work.

·         The developer who always leaves the code better than he found it, but gets his work done on time.

·         The introverted tester who regularly steps out of her comfort zone to help her scrum team become self-organizing and effective.

The difference is attitude.  We all need to make big pushes sometimes and drive projects or programs to completion.  But when you are surrounded by noble people who are driven by the desire to be excellent and do excellent work, those big, last-minute pushes, which never produce the highest quality of work, become much more the exception than the norm. 

This is why technical competence is so important to assess in an interview.  Not because I care about coding trivia, not because the information isn’t readily available on-line, and not because it’s a measure of IQ.  It is important to measure technical competence because it is one indication of a person’s attitude towards excellence.  It is one measure of whether a person is limited by their own sizeable potential, or limited by their lack of passion.

BIBS

The following is a true story.  Anna Maravelas of TheraRising.com writes about in her book How to Reduce Workplace Conflict and Stress.

A man is late for a meeting and seems to be hitting every red light on his way to his appointment.  He gets to yet another red light and is behind a woman in a sedan.  While they are waiting for the light to change, she turns around and begins foraging in the back seat.  Perhaps she is looking for lipstick or a CD or who knows what.  But one thing is certain; she is oblivious to the light.  The light turns green.  The man taps his horn.  She ignores him and keeps searching the back seat.  He is now more aggressive on his horn.  She not only ignores him, she gets out of the car, walks to the back door, opens it, and continues foraging!  He is outraged.  He is now leaning on the horn, and has rolled down his window so he can tell her what he thinks of her lack of consideration.  Eventually, without any acknowledgement, she returns to her front seat and drives off.  Another self-absorbed, oblivious driver.

That night, the woman writes a letter to the local newspaper.  She wants to tell her side of the story.  Her story is this:  Today I was sitting at a red light when I sensed something was wrong.  I turned around and saw that my toddler son in the back seat was choking on something.  Frantically I turned to help but could not reach him.  I jumped out of the car, threw open the back door and – thank God – I was able to dislodge the thing he was choking on.  All of this took a minute or two.  I was fighting to save my baby’s life.  There was a man behind me honking his horn and shouting profanities at me.  He was indignant because I may cause him to sit through a two minute light again.  I could not believe how rude he was.

BIBS stands for Baby In the Back Seat.  It is an acronym to remember this story.  It is an acronym to remember that we have a strong tendency to attribute negative motivation when people behave in ways we do not like, or do not understand.  The stranger does not return our hello greeting because he is arrogant.  The supervisor is overly critical because she is petty and controlling.  The babysitter does not show up because she is a typical irresponsible teenager.  We don’t know why this behavior is happening.  But we tend to invent reasons, and the reasons do not show grace.  How strong is this tendency?  Even when you are aware of it you will still catch yourself doing it. I speak from experience.

Testers and developers have jobs that are converging, but their approaches still cause conflict.  The tester logged multiple low-priority defects because he is anal-retentive, or lacks judgment or is trying to make development look bad.  The developer  gave a demo of a new feature without inviting the tester because he does not think about testing, or does not think the tester adds any value.  This thinking makes a problem worse.  BIBS reminds us to deal with the problem and not the person.  Testers and developers don’t always understand each other well – the pressures, the thought processes, the motivation.  As leaders, BIBS is a tool we can use to remind ourselves and those we influence to show each other grace and focus on the why without vilifying the who.