Category Archives: Leadership

Some thoughts on leadership in technical environments.

Knowing-Doing Gap

In one of my leadership minute videos, I mentioned the knowing-doing gap. It was a concept I learned from a former boss, and I happened to see it in print today, referencing an article in HBR from 1999: The Smart Talk Trap by Jeffrey Pfeffer and Robert I. Sutton.

The article makes some great points, including that Leaders learn to talk well, but may never actually do things, mostly because they are rewarded for talking. Talking is given more weight than doing, and ironically, more pay. It mentions that people tend to see criticism as more intelligent than praise. That organizations are driven to complex plans because simple ones are presumed to not be viable.

In many organizations, sounding intelligent takes priority over doing, and that has the effect of uninspiring others. Eilieen Shapiro, in Fad Surfing in the Boardroom, called mission statements “a magic talisman, hung in public places, to ward off evil spirits.”. In other words, mere words can be uninspiring and may actually inhibit performance.

Their solution is multi-pronged, and is basic blocking and tackling.

  • Leaders who do the work, rather than just talk about it, help prevent the knowing-doing gap from opening in the first place.
  • Plain talk and simple concepts are marching orders.
  • Create informal rules governing discussion — focus not on faults but on overcoming them.
  • Close the Loop—following up to make sure something actually happens after it has been decided on—isn’t a very complicated idea. But it is a potent means for preventing talk from being the only thing that occurs.

Virtual and Remote teams

This post is also the subject of a Leadership Minute video.

In 1996, I was working for a subsidiary of Cray Research in San Diego which got acquired by Sun Microsystems. We knew that the company was Bay Area focused; if you weren’t in the Bay Area, you were a second class citizen. In early interactions it was very clear that neither group had the skills to collaborate remotely, so we decided we better get good at it, and we would have to drive the development of remote collaboration skills from San Diego, because the Bay Area contingent wasn’t going to care.
13836475024_f2993a19c3_b(hover over image for attribution)
We first made sure the audio equipment was good. We did have video conferencing, but decided for the most part that was a distraction, and was too expensive to put in every meeting room. If the audio quality is poor, you might be able to work through it, but it will be inefficient.

The most important thing after being technically able to hear each speaker in a room, was to change behaviors. When you are present in a room full of speakers, you can see who is speaking, and who is not speaking. You don’t have the luxury remotely. At the start of a remote meeting, someone has to make sure that each person present introduces themselves on all endpoints. That enables remote leaders to ask for input from others who have not spoken.

If a speaker has any doubt that someone may not know who is speaking, they should announce their name when starting a new dialogue. It may seem tedious, but it’s important to know who said what.

If a listener doesn’t know who is speaking, they need to ask. If listeners do this enough times, the proper speaker behavior eventually comes around naturally. In general, they will be a little embarrassed that they assumed the listeners knew who was speaking, so they’ll change to avoid that.

If any remote listener can’t hear, they need to ask the speaker to speak up. In an in-person meeting you might be able to augment the mumbler by reading lips and observing body language, but remotely, don’t let them get away with sloppy communication.

The reason this problem exists is that the ability to speak remotely is relatively new to humans if you look at it from an evolution standpoint. It’s why we think telepresence is so compelling. Until telepresence is the norm for remote communication, we have to use “new” skills. Because so much of our work is done remotely now, we better get good at it on a much larger scale.

The end of the Sun Microsystems story is that we became good enough at it that it enabled a company wide initiative to reduce the real estate expense. The objective was to put 1.5 people in each corporate-paid seat, by letting them work from anywhere.

Severely Annoying

This post is also the subject of a “leadership Minute” video.  When I became a director at Sun Microsystems,  I got to go to “Director School” to teach me to be an executive.   There were multiple teachers but unfortunately I have forgotten all of their names.   The concept that I remember most vividly is that of the SAPWAGI (săp-WĂG-ee).

I have asked scores of other people if they know what a SAPWAGI is, and the reaction is always perplexed bemusement.   SAPWAGI stands for “Severely Annoying Person With A Good Idea”.   The acronym and concept works in my mind because it’s funny and therefore memorable, and embedded in its seven words is the lesson itself. I’ve remembered it some thirteen years later and try to live by its lesson.

The lesson is not too dissimilar from the “Insane Dude Problem“.   The point is that there are many people for whom it takes effort, sometimes extraordinary effort, to understand.   The difference is that a SAPWAGI is simply annoying, whereas the “insane dude” might be subversive. The approach for a SAPWAGI is generally patience and perseverance; it’s totally under your control.

I have worked with a number of SAGWAGIs in my career, far more than “insane dudes”.   There are multiple reasons they may be annoying; for me, the worst is condescension.   Maybe the SAPWAGI is smarter, more seasoned, more capable, more accomplished.   You’ll have to assume they might be, and let them be themselves, in order to engage them. Ask them to tell you more, and don’t be afraid to drill in. They might be annoying because they are hiding their fear that they really don’t know more than you.

As a leader, you are probably more capable of bringing people together, getting them to change things, do things better, and work together.   The SAPWAGI, generally,  does not have that capability. You can keep that in mind as you take the high road and look for the benefit.

What the teacher at Sun taught us somewhere near the year 2000, was that we would reap enormous rewards by bucking up and engaging the SAPWAGI.  Since Sun, at the time, had a Darwinistic organization full of a lots of really smart people, I think someone figured out that we had to engage the SAPWAGI or go home.  It didn’t work out perfectly for them in the end, but that wasn’t because we weren’t able to work together and harness some incredible talent.

The Insane Dude Problem

This subject was covered in Leadership Minute #9 – The Insane Dude Problem. This phenomenon is extremely common. You see it in divorce cases all the time. It happens when it’s too hard (or inconvenient) to understand someone else’s perspective, so a person gets labeled as “insane”. When a “sane” person describes the “insane” person’s behavior or perspective, they are often seeking affirmation from the listener. The reality is that this is generally a cop-out. According to the National Institute of Mental Health in 2006, about 1.1% of the US population had schizophrenia. So, sorry, your coworker is very likely sane; statistically, schizophrenics don’t work at your company.

What’s really going on is that that the accuser has given up on understanding the perspective of the supposedly insane person. There may be motivations on both sides, but for now we’ll focus on the “insane” person. The common reasons this might occur are that the insane person:

  • Is a poor communicator
  • Has a different set of facts than others
  • Is trying to hide fear or an objective that would not be acceptable to others


This HBR article, Rethinking Trust, by Roderick Kramer, is a great read regarding trust. The reason it’s relevant here is that improving trust can help with all of the above issues. It talks about a number of things, but most importantly for the insane dude problem, you can gain trust of the other party by trusting them and being empathetic. If the dude is hiding information because of fear, improving trust will get them to disclose reality. If he is failing to communicate (or you are), simply talking more may eventually uncover a difference in factual understanding; if two people differ on the facts they will almost surely differ on the solution, and sometimes a person’s chosen solution is what earns them the “insane” moniker.

So, dig in. Listen well, repeat what you heard for understanding, share stories from your experience that shows that you understand and empathize. If he has a hidden objective, that might never come out overtly. You can ask directly why he has certain opinions or prefers certain solutions over the “sane ones” you and your colleagues devised. Hopefully, if it is subversive, it’s not pervasive in your organization. If it’s localized, he’s probably not insane, just insanely selfish.