Blog - Robert Bogue [MVP]

Saturday, January 19, 2013

Book Review: The Art of Explanation

I spend quite a bit of my time in the professional world trying to explain things. Sometimes it's to clients. Sometimes it's developers. Sometimes it's to the infrastructure team. Whomever it is, I know that sometimes my explanations work – and sometimes they don't. The Art of Explanation holds the keys to at least some of the problems I have when trying to explain things. I wanted to share some of the highlights from the book with you but before I do that I have to share a story.

Many, many moons ago. My guess is about 20 years ago, I was a LAN manager for a manufacturer. I was the guy that got to go solve the problems that others couldn't solve. In the age when the Internet wasn't commercial yet and email was truly store and forward. I got called to help the sales secretary with something – I don't remember what. I do, however, remember being very frustrated and coming back to my boss at the time. He said something that has never left me. He said "Rob, you were trying to teach her why it worked and all she wanted to know was how to make it work." For me, I really want to build the mental models that Gary Klein talks about in Sources of Power. I want to understand how the pieces work. However, many people just want to do whatever it is so they can get on with their "real" work. I can try to explain how something works – and the person I'm talking to doesn't want to know.

The book starts by describing that people who don't know much need to know "Why" and the more they know they cross over into wanting to know "how." That isn't new if you've ready about The Adult Learner. One of the clarifications that I believe is important – that the book leaves out – is that it's just the "Why I care" and not "why it works that way". Similarly, there's the "How do I do it" – and not the "how it works." For the most part, people don't care how it works – or why it works that way these days.

The Art of Explanation also speaks of how you can't really understand the trees until you've seen the forest. You have to have a context to place the idea in or you won't be able to remember it. That's one of the reasons why explanations are not facts. Facts exist without context. To be good at explaining, you have to provide some context.

Interestingly, Efficiency in Learning says that you should "Teach System Components before Teaching the Full Process." (Guideline 13). This would seem to imply that teaching the trees before teaching the forest is appropriate, however, the kinds of information are different.

Consider the movie the Karate Kid. One could say that "Daniel" was taught karate through the fundamentals. However, there's a difference. "Daniel" was motivated to work towards a goal. He understood the forest. He knew where he wanted to be. Once he had that vision and the desire to get there, he needed the fundamentals taught to him. In effect "Daniel" had already received the "Why" – he already cared because he didn't want to be bullied any longer.

From a learning standpoint, he was taught the fundamental moves – and then he was taught (very quickly in movie-time) how to apply those fundamentals to the appropriate situation. This hints at another aspect that the book makes clear, through a quote from Robert McKee's book Story. "Anxious, inexperienced writers obey rules, unschooled writers break rules. Artists master the form." This reminded me of my blog post Apprentice, Journeyman, Master. (In which I speak of another aspect of the Karate Kid movie.) In other words, we need to have a way to explain the basics. The rules. The foundation. Then we need to learn the principles behind the rules and know when to break the rules to stay in alignment with the principles.

Pervasive Information Architecture pointed out that we grasp the abstract through means of the concrete. That would seem to imply that we should provide concrete examples of everything – which is hard to do when explaining the forest, however, I believe they're talking about two different points in the learning process. The first point is where the person doesn't know why they need to know or why they care. (The learner's need to know from The Adult Learner.) In most explanations the audience doesn't know why they need to know – or at least they don't know why precisely. They key point is to help folks see the broad environment when they'll be working – before getting to the detailed specifics – the trees of the situation.

My point in raising potential objections to talking about the forest first is to show that they're less about objections – and more about just slightly different views of the problem.

The Art of Explanation talks about how context is important – if content is king then context is the kingdom. The funny thing is that it also talks about recipes and the fact that they don't need context. They're designed specifically to be context-less. That's actually the core idea behind the Shepherd's Guide. It's a set of recipes for getting things done with SharePoint. The context of the comments we read, the perspective they're coming from is a core part of the message. The information that applies to one person in their situation – their context – can be completely inappropriate to another person in a different situation.

Thinking, Fast and Slow talked to the way that people think – and how we feel. The Art of Explanation makes the point that you want to help people get their mind into the story of what's happening. You want them to feel the pain of the actor in the story. I know from my work writing marketing copy that only writing to the intellectual and rational doesn't work. We need to speak to the elephant as well as the rider. (See Switch and The Happiness Hypothesis.)

Then there is the curse of knowledge. That is, the more you know about something the harder it is to explain it to others. Of course Einstein said "If you can't explain it simply, you don't understand it well enough." I think he was talking about the folks who like to pretend they know something but then can't explain it – mostly the more you know about a subject the less that you can remember what it was like to know nothing. (Back to Thinking, Fast and Slow and what you see is all there is.)

Before getting to the concrete tips from the book (blended with my thoughts), I need to rewind one last time and talk about how the features of something aren't equivalent to its utility. Diffusion of Innovations makes it clear that the consequences of an innovation are difficult to predict. Similarly, it's hard to explain how a tablet will be used. Enumerating it's weight and battery life don't communicate to you that it's a great consumption device for browsing the web and reading books – the features (lightweight and long battery life) don't automatically convert to how someone can use it.

The Art of Explanation considers these the key components of a good explanation:

Context – The agreements and shared experiences we start with.
Story – The big ideas of the narrative.
Connections – Analogies and metaphors to connect the new concepts with what people already understand.
Descriptions – Details and benefits.
Conclusion – A summary of what was learned.

The book also talks about the different mediums and their suitability of differing explanations. I've adapted this information into table form.

Type	Time to Produce	Scanability	Communicating Concepts	Communicating Details	Ease of Replication
Text	(+) Quick	(+) Scannable with appropriate headings	(-) Difficult for people to see the forest for the trees	(+) Because it can be reviewed, good for communicating details	Excellent
Image / Graphic	(-)Difficult to produce, sometimes require specialized skills	(+) Can be scanned with relative ease due to the compression on to a single page	(+) Good for communicating high-level concepts	(-) Insufficient space and the large time to produce	Good
Audio	(-) Somewhat harder to produce, requires audio recording equipment and awareness about good quality levels	(-) Audio cannot be scanned and search engines don't index into the time when a word was said.	(+) The ability to hear intonations in voice or other-non word audio can enhance the feeling and therefore the overall feel.	(-) Lack of scanability and general retention of facts from audio will reduce usefulness for facts.	Good
Video	(-) Much harder to produce good video explanations. Requires equipment and skill.	(-) Video cannot be scanned and search engines don't index into the time when the word or concept was discussed.	(+) Allows for audio, text, visuals, motion graphics, etc. Extremely good at allowing users to grasp concepts	(-) Lack of scanability creates some level of challenge for communicating details. However, because of multi-modal communication (visual and auditory) it can be somewhat effective.	Good
Live Demonstration	(-) Preparation time can be large	(-) Only the materials are potentially scanable. See comments for the type of materials	(+) Interactivity allows you to adapt the message to the audience.	(-) If backed up with written materials. Used to create AWARENESS and use other methods to create RETENTION.	Bad

The Art of Explanation is a great book – if you want to learn how to explain things better.

Categories: Professional, Book Review | 0 Comments

Saturday, December 15, 2012

Developer-IT Pro Cage Match

While at the Microsoft SharePoint Conference in November, Dux placed a microphone in my face and asked what I'd be doing if I wasn't doing SharePoint. My answer is probably more than a bit confusing. I said "The same thing I'm doing now, refereeing developer-it pro cage matches." (Or something similar, I had quite literally just arrived.)

That sounds sort of odd on a couple of levels so I wanted to tear it apart.

What If There Were No SharePoint

I've made quite a bit of my professional career in SharePoint. I've had plenty of room in SharePoint to do infrastructure, development, end user adoption, workflow, governance, and tons of other things. Certainly if there were no SharePoint my world would be very different, however, at its core, I see SharePoint as a platform for solving business problems. If I wasn't doing SharePoint I'd still be doing something to help businesses recognize value out of technology. My guess is that I would have ended up at some large organization as an enterprise architect, putting together pieces to minimize problems – and make it easier for the organization to recover.

I'm a high challenge person as nearly everyone who knows me will attest. That doesn't necessarily mean that I'm challenging – it means that I will seek out challenges and try to conquer them. That's another way that SharePoint has been fertile ground for me. In the beginning we were facing technical challenges that hadn't been seen before. (SharePoint 2001 would continuously respond with HTTP 100 Continue messages – confounding most of the monitoring tools of the day.) We've been faced with scalability problems. I could go on about the technical challenges that we've conquered as a community over the years.

I believe that SharePoint is one of the most challenging applications to sell an organization because it's not an organization. It's a platform. It's infrastructure. Back in 1991 when I was first working with email, we didn't have a defined need for email. We didn't have a specific business purpose. It was just something people were playing with. I was lucky enough to be a part of Woods Industries at the time and with the overseas sourcing we did find a specific need and over time we began to develop an awareness of the benefits – but even with the spark of an initial need it was still a struggle.

In many organizations today it's difficult to explain how SharePoint can be helpful – even to those who already have it and need only learn to use it. The fact that there's not one thing that the tool does makes it hard to explain. It's a desert topping and a floor wax – and it will always be that way.

Why Can't We All Just Get Along

Why I describe what I do as refereeing a cage match is another mystery. The short is because I often act as a translator between developers and IT Pros that just don't speak the same language. I am not surprised by the conflict that exists between infrastructure and development – and you shouldn't be either. Infrastructure is goaled on keeping systems stable. Development is goaled on delivering new solutions for the business. New solutions mean change and change means instability.

It's no surprise that the conflict that's created with the opposed goals spills into other areas and the finger-pointing game begins. Developers believe that the performance is bad because of bad infrastructure. The infrastructure team believes that the performance is bad because the developers are writing bad code. I don't believe I remember an organization where development and infrastructure really got along.

The cage match bit is that developers and IT Pros can't get away from each other. In a regular match you can go away. However, if you're in an organization the idea that you can get away from the conflict isn't realistic.

Whether I'm doing SharePoint or not, I'm looking forward to bridging the gaps, improving understanding, and making the developer-IT Pro relationship feel a lot less like a cage match.

Categories: Professional | 2 Comments

Tuesday, November 27, 2012

SharePoint, REST, TypeScript, and the Library

For the Microsoft SharePoint Conference in Las Vegas I did a session on using TypeScript to develop for SharePoint and Office. In that session I demonstrated a non-trivial example of a library I built in TypeScript for accessing SharePoint's REST services. I did this because TypeScript is about building enterprise scale applications – something that JavaScript doesn't do particularly well (to be as kind as possible.) I got several requests by the other speakers at the conference and the attendees about what I intended to do with the library. And I'm happy to confirm that I'll be releasing the code as an open source community project. The intent is to create a library that can be used anywhere to build applications for SharePoint.

However, before I decide where to put the library, I need to know who would be willing to help with the enhancement of the library. I don't want to create a project on CodePlex to find I'm the only developer – if that becomes the case I'll just host the project here on my site. I'm really looking for who would be willing to contribute. I should be clear much of the code won't be super-technical, highly architectural. A lot of it is just slogging out support for various interfaces and following the pattern I've already created. Not that there won't be fun problems to solve but I also don't want to discourage folks who don't feel like they're architect-level developers yet. Before go into more details, let's talk about the library itself.

What is TypeScript?

If you missed it, TypeScript is a super-script of JavaScript that compiles down into regular JavaScript. The benefit is that it adds type safety through compilation time checking – and intellisense in Visual Studio. It's a great tool for those who are tired of debugging for hours to realize that they had a capitalization problem or a typo on a method that they just couldn't see while looking at the code. I believe that it's the future way to develop JavaScript. We'll develop in TypeScript and compile down into JavaScript as an intermediate language.

Who Can Use the Library?

Because the library is TypeScript based it compiles into regular JavaScript. That means anyone that has a platform that uses JavaScript can use the library. Whether it's Office and SharePoint applications like the library was built for or whether it's a Windows 8 HTML/JS application. The one requirement is the use of jQuery as a base library. It's also likely that the library will ultimately require the datajs library that's being developed to make OData access easier. Otherwise, the library is intentionally easy to use.

What Does the Architecture Look Like?

The primary challenges for most developers who are getting involved with JavaScript are the lack of type safety and the increased dependence on asynchronous calls to keep work of the primary display thread. Building the library in TypeScript resolves the concern of type-safety. The dependence on asynchronous calls is handled through the use of promises. jQuery includes a Deferred object. This object implements JavaScript promises.

The short is that a promise is a "publish-subscribe" object which allows you to subscribe to events you're interested in and get notified when they're completed (typically through anonymous methods). Once the event occurs your code is run. The beauty of this is you can write code that looks something like:

Obj.DoSomethingAsync().done(function () { alert('success'); }).fail(function () { alert('oops'); }).then(function () { alert('next?'); });

This will cause the right methods to be called when the async method completes. This approach keeps the async response code together with the code that started the async event. The beauty of this is that the deferred object can be held and if other code wants to subscribe to the event later it can. If the event is already completed the code that is subscribing to the event will run immediately. This allows you to do caching internally in your objects to minimize repeated calls.

With this as the basis the objects mirror the objects in the server side object model. The methods are intended to mirror the way that you deal with the objects on the server. There are a few differences because of the way that JavaScript works when compared to .NET/C# -- however, the differences are designed to be minimal. A developer who knows the SharePoint object model should be able to use Intellisense in Visual Studio to see what's happening.

Why not the JavaScript Client Side Object Model?

A rather obvious question is, "Why would I write a totally new library to access the REST services when there's already a JavaScript client side object model?" The short answer is that the JavaScript Client Side Object model doesn't always work. It works just fine if you're in a SharePoint hosted application. However, in situations where you don't have an app web the SharePoint JavaScript library won't work. Even when it does work – outside of the SharePoint hosted app – it's quirky. I wanted one library that worked whether I was working on remote server, a Windows 8 application, or on the SharePoint server itself. I didn't want to have to do things fifteen different ways.

Developers Needed

At the beginning I mentioned that I wanted some other folks who would be willing to help me flesh out the scope of the model. That work is something that doesn't require a huge amount of skill – it's something that's good exercise for developing against SharePoint remotely. If you're relatively new to development – I absolutely can use your help here.

In addition, I'm looking for some folks who are willing to help me keep an eye on the architecture of the library as it grows. I've got a long background in building architectures and libraries – but JavaScript isn't my native world. I'd love someone who can help with the finer points of architecting enterprise scale JavaScript. For instance, techniques for managing cross-domain calls.

If you feel like you can help (even if it's only a few hours a month) please email me. If you don't feel like you can help – but you want to see the library to see if it would be useful to you, send me an email. I'll send you the code for your educational use. Yea, it's send me an email and I send you a response. I want to track the number of folks who are interested in it so I can notify them where I end up posting the project.

Categories: Professional | 1 Comment

Sunday, November 25, 2012

Book Review: The Advantage-Why Organizational Health Trumps Everything Else in Business

I heard Patrick Lencioni speak at the Willow Creek Global Leadership Summit and that prompted me to pick up his latest book, The Advantage: Why Organizational Health Trumps Everything Else in Business. I've been a fan of Lencioni's work for a while. In fact, one of his previous books, The Five Dysfunctions of a Team loosely inspired my blog posts in 2009 chronicling the top four most common corporate delusions, and then the fifth and sixth most common corporate delusions.

Note: Most of the ideas in this post are Lencioni's, however, in some places I've extended concepts he started with my own thoughts or thoughts from other books. I've made every effort to delineate what came from The Advantage and what came from elsewhere.

The Advantage lays out four key ideas that Lencioni believes lead to organizational health. They are:

Build a Cohesive Leadership Team
Create Clarity
Overcommunicate Clarity
Reinforce Clarity

Over time Lencioni believes that these will eliminate wasted effort – in other words reduce friction – and will allow the organization to learn more quickly. (Which reminds me of The Fifth Discipline which I read a long time ago and the drive to have an organization that learns.) While I wholeheartedly agree that the types of organizations that Lencioni describe are better – by multipliers not mere percentages – but I'm not completely convinced that the book lays out everything that someone needs to transform their organization into the high-performing organization they want, I believe there's a level of personal transformation that is required which I don't believe Lencioni fully addresses. (Don't stop reading here, it's a great book, I just believe it assumes a level of emotional intelligence that I don't believe every leader has.)

Building a Cohesive Leadership Team

One of the prerequisites for a good organization is for it to have a good leadership team – and that isn't to say that each of the members must be good at their roles – that is an assumption. Having a good leadership team is to say that they have to be in sync with each other – willing to accept each other as whole human beings and also willing to challenge each other. This is where I believe the challenge lies. The level of personal strength of character that it takes for a leadership team to be both open and vulnerable to one another is strikingly uncommon in my experience.

One of the points in the book, which appeared in Switch too, is the idea of a fundamental attribution error. That is that we tend to justify our own behaviors based on circumstances and tend to attribute behaviors to another person's core makeup – rather than realizing the situation they were in. This creeps in to drive a wedge between members of the team. It's just one of the small factors that often lead to a leadership team becoming a group of leaders working in the same company (not a team.)

Lencioni lays out a set of five behaviors that he believes will build a cohesive leadership team – which I agree that if these things are done, you'll get a cohesive leadership team. I'm just not sure that there's not still a point of "and then the magic happens" where the caterpillar is transformed into the butterfly. In other words, it's easy to say and hard to do.

Behavior 1: Building Trust

I'm no stranger to learning about and writing about building trust. My previous book review was Trust Me and before that I reviewed Building Trust in Business, Politics, Relationships, and Life and Trust & Betrayal in the Workplace. I boiled down the foundations of building and rebuilding trust in my blog post Building Trust: Make, Renegotiate, Meet. Lencioni believes that most folks think of trust as competency based trust. That is you believe the other party is competent to do their job. His belief here is that it takes vulnerability-based trust to be really effective. His vulnerability based trust might also be called authentic trust. And it's more about trusting the whole person to behave relatively consistently. (As a sidebar, if you find that people are not behaving consistently you may find that two or more of their values are in conflict.)

Lencioni shares his approach for rapidly improving trust amongst a leadership team. He leverages standardized psychological profiles like the Myers-Briggs Type Indicator to help the team learn more about themselves while maintaining that everyone is good – just people are different. This is important because it helps people understand and accept who they are in both their strengths and their weaknesses. (Sidebar: I heartily support the use of the MBTI, but if you're looking for an alternative approach you can look at using the Enneagram.)

In fact one of the exercises that Lencioni discusses – an exercise where the entire team talks about one of the best things about a person – as it relates to the team – and then shares one of the most challenging things about every other staff member. The hope is that everyone realizes they are imbued with strengths and weaknesses. Lencioni discusses how this exercise must begin with the leader and their willingness to accept their strengths and weaknesses – so that the rest of the team will understand how to respond.

So fundamentally I'm in agreement about the approach. Building trust – not through some fluffy rope exercise but real trust – is critical to a leadership team. Much of my consulting time is creating pockets of trust in an otherwise distrusting organizations. Where I believe that Lencioni and I may differ is that I don't believe that a two day workshop can build trust between managers. I believe that a two-day offsite can sow the seeds of trust in an organization, but I'm not convinced that anything short of a long-term coaching engagement can really transform a leadership team and help them to realize their deep need to trust each other and the great lengths that they go to in order to avoid trust.

In short, my experience has been that most folks aren't comfortable with themselves enough to really trust others. Because they don't trust themselves how could they trust someone else? This may be a rather dim view of the state of leadership in organizations, however, I believe it's born out in news stories every day.

Behavior 2: Mastering Conflict

Some people are conflict avoidant. Other folks are instigators – always looking for a conflict. Always looking for a fight. Some folks, like myself, are conflict apathetic. That is to say that we're not really deeply troubled by conflict. As a truth, no one really likes conflict not even the conflict apathetic. It's always a bit unsettling, however, sometimes conflict is necessary. Said differently as the lyrics from an Alanis Morissette song, the only way out is through.

There are, however, some things that can be done to improve the results of a conflict. Perhaps the most effective way to have a good conflict is to really listen to the argument on the other side. Most folks get stuck in trying to justify their position and as a result rather than empathetically listening to the other party they're trying to develop the next part in their argument. This tends to escalate the conflict because neither party feels like they're heard (because they aren't.)

Behavior 3: Achieving Commitment

In my experience most organizations that conflict is avoided like the plague. I see people nod their heads in meetings only to do nothing later – or occasionally sabotage the actual initiative. One of the techniques that I've seen good project managers do – and is called out in The Advantage is actively asking each person in the meeting for their agreement with the decision. Another technique mentioned to get everyone talking is that the assumption will be disagreement – rather than agreement – if someone stays silent.

One of the challenges I often see in business conflicts is people who hold onto a position well past the point that the position appears silly to everyone in the room –including the person who is supporting it. The result is frustration sets in because someone isn't able to accept that their position wasn't the "right" position. Achieving commitment is predicated on the need for professionals to abandon their positions when they no longer make sense.

Achieving commitment is built upon resolving conflict but extends this to reaching a consensus about the right course of action – that everyone is agreeing to take.

Behavior 4: Embracing Accountability

Few organizations that I've worked with really embrace accountability. In fact most of them have a form of commitment cancer that's insidious. I first mentioned commitment cancer in a post about running users groups back in 2010. Commitment cancer is the failure to hold other folks accountable for their commitments. I see it everywhere.

I "grew up" in publishing. With author credit on 22 books and editor credit on numerous others, I got to know how technical publishing works. However, in some ways, it doesn't really work. It just appears to work. The schedule for publishing a book is notoriously a matter of fiction. Every acquisitions editor knows that whatever schedule that you start with won't be the one your end with. It's routine for authors to be weeks, months, and sometimes years late on when they say they're going to be done. Everyone in the industry simply expects this to be a truth and therefore there's only the most trivial level of wrist slapping when an author is late with a chapter – or the whole book. There are a lot of down-stream impacts with editors, printers, etc., but this is just accepted as a cost of doing business.

However, a healthy organization is one where commitments that are made are commitments that are honored. I should say that they don't have to be met every time – but they should be renegotiated when they're not going to be met. That's great in theory, however, most business people don't operate with this high a level of personal integrity. They instead hide when they miss a commitment. They don't really hold others accountable when they miss a commitment either. Everyone has entered into a tacit agreement that if you don't point out when I miss a commitment, I won't call you out when you miss yours. The problem with this is that it complicates the process of getting anything done because you never know whether something will happen – or not.

Holding everyone accountable, as Lencioni points out, is something best handled directly by peers. When a manager has to force accountability there's an internal resentment that builds based on the confusion about who "ratted them out." When peers are free to professionally challenge each other and hold each other accountable the leader doesn't need to step in and the team will function more effectively. Ironically to get to this state the leader often has to start by holding people accountable so that everyone knows what to expect.

Behavior 5: Focusing on Results

Over the long term, a team that isn't producing results isn't a good team. I understand that there may be market factors, there may have been insufficient budget, there may be force majeure – but over the long term if a team isn't producing – it's not a good team. Some would argue that good teams can be put in bad situations. I'd agree – but then again good teams will get themselves out of a bad situation eventually. Ultimately the effectiveness of the organization will be based on results – and so too should everyone inside the organization.

In a sense, the focus on results is the natural outcome of accountability. Ultimately someone has to be or become accountable for the results just as the CEO is accountable for the overall performance of the organization.

Create Clarity

Most folks see the key change that lead to the industrial revolution was the development of the steam engine – however, I see the situation a bit differently. I see a situation where the standardization of parts. Suddenly we started to have consistent bolts, nuts, etc., which could be used relatively interchangeably. This may seem like a trivial, insignificant thing and in some ways it was. However, in other ways the clarity of having a set of standards allowed people to work together who didn't know each other – and that lubricated the economy in ways that couldn't be expected before.

Having a common standard or a way to communicate precisely between a set of people has a dramatic impact on the amount that can be done. We've all had situations where we have had misunderstandings with someone else. Where the word that you were using meant something to you – and something different to someone else. It was probably comical when you discovered the source of the miscommunication. However, that didn't save you from the time it took to find the miscommunication.

In many of the leadership and change books that I've read such as: Switch, Good to Great, Leading Change, and The Heart of Change there's a common thread of resistance to change. And a common message that sometimes things which on the surface appear to be resistance to change aren't really resistance to change as much as it's a lack of understanding about the change and when folks aren't sure what to do by and large they simply stop and wait for clarity. However, when clarity doesn't come it's rare that they'll seek out clarity or spontaneously start taking actions.

Even a small amount of fog in an otherwise clear message can add up to a big change. For a moment imagine a point with 360 lines radiating from the point in one degree increments. When the lines are very close to the point, the amount of separation is minute. It's quite difficult to determine one line from another, however, as the lines project out further a great deal of space will exist between two lines even if they're only one degree different. This is how clarity works. Even a small degree of lack of clarity can lead in an infinitesimally small error – until that error is projected out through the weeks, months, and years.

Ferreting out where there is a lack of clarity can be a daunting challenge. It involves not only the obvious work to address language differences and differences of interpretation but also the conversion of the generic agreement to a specific agreement. The old saying that the "devil is in the details" is true here as it takes time to think through even a subset of the different ways that an agreement will impact various departments – and to verify that those impacts are truly intended. One technique that Lencioni uses is the creation of a playbook which answers six questions.

The Playbook and Six Questions

When a football team takes the field they've got something that most organizations don't have and that is a playbook. They know what the plays are that they'll run and how to identify them. While it's not possible to script out every part of every play on a football field any more than it is possible to script every part of a business, the playbook forms a common language and a standard set of operating procedures for how the team expects to operate before improvisation needs to happen.

In the book Heroic Leadership there was the concept of "our way of proceeding" – a set of guidelines and a worldview shared by the Jesuit team. This was described as a compass and not a checklist. That's exactly what a playbook should be inside of the context of a business. It should describe the operating principles and approaches without attempting to be an exhaustive catalog for every decision.

To create the playbook Lencioni recommends that organizations answer the following six questions:

Why do we exist?
How do we behave?
What do we do?
How will we succeed?
What is most important, right now?
What must do what?

The answers to these questions form the basis for a playbook. In other words the core purpose of the organization – and it's "way of proceeding." Lencioni acknowledges that you can frame the purpose of the organization – the why do we exist question – in several different contexts and suggests these six categories:

Customer
Industry
Greater Cause
Community
Employees
Wealth

The second question, how do we behave, leads to a question of values. Lencioni breaks values into four categories:

Core – These are the unchanging values upon which the organization was founded. They're essentially immutable.
Aspirational – These are the values that the organization wants to cultivate because it believes that they are necessary for the long term success of the organization
Permission-to-play – These are the values that they believe the market requires for any organization to participate. These are the values that every organization says that they have. In consulting it's generally hiring only the best people, etc.
Accidental – These are values that just happen to be a part of the organization and may – or may not – be helping the organization.

There is guidance for the other questions as well – but ultimately the goal is to create a clear vision of where everyone is going and what they're doing.

Overcommunicate Clarity

How many times should you tell your employees about your mission, values, and current goals? One more time than you've already told them. While leaders have had the benefit of working through and refining the vision the employees of the organization have not. They're experiencing it like they would experience advertising. And in advertising you have to deliver a message seven or more times for folks to recognize it. Guerilla Marketing quotes Thomas Smith from 1885 which speaks of needing to see something twenty times before taking action. Whether it's seven, twenty, or two thousand – it's more than the once that leaders want to communicate it.

In an organization part of the need for repetition is simply to demonstrate commitment. Employees hear so many initiatives, goals, decisions, etc., that they are challenged to sort out the noise from the truly important pieces. Leaders on the other hand, driven by efficiency, hate the idea of having to redeliver the same message over-and-over again. Delivering the same message over-and-over again frustrates leaders who are always looking for a challenge. However, as Diffusion of Innovations pointed out, knowledge isn't the same thing as changing someone's attitudes, much less practices. Repetition is a part of changing behaviors – because the learning becomes more ingrained into the person. Repetition alone won't drive a change in practices for everyone, however, repetition coupled with the innovators that can be changed with simple repetition can bring along the rest of the organization.

One way to create the kind of intimate connections necessary to drive behavior change is to leverage what we know about the diffusion of innovation. That is that people's attitudes – and practices (behaviors) are driven differently based on the kind of communication. Mass media communications create awareness, however, close personal communications are often needed to push people into attitude and behavior changes. Lencioni recommends a practice he calls cascaded communications. This relies on managers communicating a message to their direct reports orally – that is person-to-person or over the phone. This attaches the message to someone closely connected with each person and therefore is more likely to influence their behavior. (I don't know that Lencioni understood or didn't understand the diffusion of innovations, however, the approach aligns well with that research.)

Reinforce Clarity

You can communicate and overcommunicate clarity, however, these require that there be continuous effort on the part of the organization to keep communicating the message. A better approach is to systematize some of the reinforcement of the communication so that it becomes woven into the fabric of the organization and requires less effort. That isn't to say that you should stop communicating. Rather, Lencioni is saying that you should weave the communications into the fabric of the organization – and continue to periodically communicate clearly to the organization. Perhaps the most common – and least effective way of systematizing clarity is creating a corporate mission statement.

The Grand Platitude – The Corporate Mission Statement

Lencioni laments that in the 1980s organizations were sold the idea of creating a corporate mission statement and how hollow that mission statement was. It was so lofty and disconnected from the organizations' real operating practice that it was a laughable exercise. Most mission statements despite their flowery words and generally positive positioning, are interchangeable with other corporation mission statements.

In my talks I speak of platitudes – dull, flat trite remarks especially one uttered as if it were fresh or profound – I use the corporate mission statement as the penultimate example of a platitude. So on the one hand, the recommendation is to systematize the continued communication of corporate values, on the other hand they cannot be encapsulated in a way that is seen as fake.

Hiring Practices

Even in the best organization, there are times when an organization will need new people to take up the corporate banner. This need not be due to people leaving for other organizations. Spouse's jobs moving and retirements will still remove employees from the organization. On the positive side growth of the organization typically means hiring additional people. Thus the best long-term game for all organizations is to create a set of hiring practices that emphasize finding folks who share the worldview of the organization – who are ready and able to become committed to the values that the organization holds dear.

It's all too easy to have hiring practices which are neither effective at screening for talent nor effective at screening for attitude. Lencioni discusses hiring practices – which I've seen myself – which are more like dating than they are like an organized process for identifying good candidates. Instead of focusing on the core beliefs and skills that the person will need to know, interviewers sit across the table from someone and talk to them about their background.

Developing a set of hiring practices that are designed to effectively filter people into those who can help the organization move forward both financially and on its values is a critical way that organizations can systematize the kind of organization that they want to be.

Refinement

Refinement is my own addition – not something you'll find in the book. It's been my observation that continual tinkering with the message -- while keeping it stable at the core – is an effective way to continue to keep the message alive. The process of creating the values isn't a one-shot thing. Instead it becomes a part of the culture to continually evaluate and reevaluate who the organization is. This in and of itself forces a consistent focus on what the organization is – and isn't about. This is a way of converting what all too often becomes a one-time or periodic activity and converts it into a "way of proceeding." Instead of big course corrections every few years everyone is all the time learning about what the values of the organization are – and what must be done to stay in alignment to those values.

Meetings

Perhaps it's because one of Lencioni's previous books was titled Death by Meeting or perhaps it's just because most organizations are victims of how well, or poorly their meetings are run that he includes a section at the end of The Advantage on meetings. Having been involved with so many organizations over the years, I've seen a great number of styles of meeting. And despite some truly spectacularly run meetings, the par is – well – uninspiring. Even in good organizations the results of meetings are not very good. Lencioni offers a few clues as to why meetings are run so poorly.

Advocacy and Inquiry

Most of the time spent in meetings feels as if it's a person lobbying for their position. They want to make their approach known. As was mentioned above in the mastering conflict section, people sometimes spend their time preparing their next argument, instead of listening to the other folks in the room.

However, healthy meetings are filled with people inquiring as to what the others in the meeting mean. They seek to fully understand what others are saying with inquiry. Not just the hollow and simple questions but ones that seek to fully understand the position of the other person. Learning reflective listening by restating what you heard the person say in your own words is an excellent first step leading to inquiry. Once you've reflected back what someone has said, you can ask if your assessment of the meaning is correct. In other words, the questions ask what does the impact of the idea look like.

Too often meetings are filled with advocacy and snoring. Another quick meeting tip is to actively engage every member in the room.

Meeting Types

Lencioni recommends meetings be broken into categories like this:

By having different kinds of meetings with different lengths and frequencies you can maximize effectiveness of the meeting time – if you have a strong leader to keep the meetings on track.

Big Company and Small Company

One of the things that struck me while reading The Advantage is how focused it is on large organizations. The problems described in the book are largely not problems that smaller companies have. In Lencioni's defense, these are the kinds of clients he deals with – larger organizations who struggle with large issues of alignment, trust, and organizational health. I bring this up because if you're running a small organization – or even a mid-sized organization – you may find that some of the advice here isn't completely applicable to your situation. While the ability to identify unhealthy behaviors, to run better meetings, and systematize your operations are things that organizations of any size should consider, much of the content is targeted for larger organizations – which from my experience are much less healthy than their smaller counterparts.

My caution is that if you're in a small organization without a hint of politics, you may find that this book is aimed for a different audience.

Converting Strategy to Tactics

At the start of this book review, I mentioned that it felt like there were still places in the book which were "and then the magic happens." One of the areas, for me, that I felt like was sorely missed was the process of converting the vision and strategy into meaningful tactics. Having worked with organizations on alignment of actions to the strategy and vision, I can say that there's an art to converting strategies into a set of interlocking tactics that lead to the strategy and that many times managers don't have the right kind of mindset nor the level of clarity needed to get to the right tactics.

I'd love to see more about how others approach the strategy to tactics conversion.

Wrap Up

A practical framework for building a healthy organization is hard to come by so The Advantage wins with its framework for creating a healthier organization. Pick it up and get better alignment in your organization.

Categories: Professional, Book Review | 0 Comments

Saturday, November 17, 2012

Book Review: Trust Me – Four Steps to Authenticity and Charisma

It might seem odd that one of my most recent book reviews was Humilitas and focused on humility and now I'm reading about charisma. Perhaps your thinking is that the humility thing was just a phase. However, my favorite thought about humility is "power held in service of others." One of the things that I've realized is that my intent is good. I really do want to help folks get more value out of technology, but sometimes the message doesn't come out right. I'm like the awkward teenager at a dance, unable to make what's in my heart come out clearly. I realize that we have all had at least one of these moments – even if it wasn't at a dance. The thinking for me is to minimize the number of times when I'm not able to authentically communicate my intent to others.

To that end, and at the mention in Fascinate, I read Trust Me. While structured practically into "do this and you'll get that" holds a great deal of wisdom and challenging questions. Unlike the previous two books that I've read and reviewed dealing with trust (Building Trust in Business, Politics, Relationships, and Life and Trust & Betrayal in the Workplace ), Trust Me is less about one-on-one trust and more about one-to-many trust.

First among the challenging questions is which conversation people believe. Do they believe the conversation you're having with your words? Those well thought out, well-reasoned arguments about why your solution is right may not be what they're paying attention to. In fact, it may be all of the non-verbal cues that they're picking up on. The book eloquently makes the point that when your non-verbal language is in conflict with your verbal language your audience (of one or one thousand) will believe your non-verbal language.

This leads us to two important questions. First, whether our words control our gestures or vice versa, and whether we make decisions emotionally or rationally.

Words Leading Gestures

It's common knowledge that we gesture to support our words. However, that common knowledge may be wrong. Ekman (see Social Engineering) is known for his work on micro-expressions and teaching folks how to read what's happening inside of the mind of another person. These expressions occur very quickly and are then quickly suppressed by our higher level brains. So it seems like we move before we form the words – or even 'think.' If that's true then how can it be that our gestures are formed by our words? Research has shown that we're always trying to rationalize our world. That we'll come up with an excuse for something we're doing if we don't know why we're doing it. Patients with split-brain disorders will rationalize their choice of words when shown two different images that don't relate. So perhaps our words come after our feelings and after our gestures.

If you're a dog lover like I am, you might be fascinated by the research that was done about how dogs look at human faces. The uptake is that dogs look at the left side of our faces first, why? Well as it turns out, that's the side of our face that tells our emotions slightly quicker and slightly more strongly than the right side of our face. It's scary in a way that dogs have adapted to watching the left side of our face to get a slight head start on knowing what to do next.

So, are you still certain that our gestures follow our words? I'm not, or rather I'm certain that they don't. It is right that people look at my gestures – my body language to see how I really feel.

Emotional or Intellectual Decisions

Gestures are one thing but surely, our reason is in control, or is it? I mentioned the split-brain disorder patients above and their propensity to explain so we know it's certainly natural that humans will rationalize. However, who's really in control? If you rewind to my book reviews of The Happiness Hypothesis and Switch you may realize that in the Rider-Elephant-Path model the rider only appears to have control. The rider can exert control for short periods of time but ultimately only within the limits of the emotional elephant – and only when the rational rider isn't tired or inattentive. Coupled with the knowledge that we are fantastic rationalizers, is it so farfetched to believe that we decide emotionally that we want something and then we justify or rationalize our emotional decision? Well, that's what Thinking, Fast and Slow seems to say. We're slaves to our emotional (system 1) thinking.

The Nick Morgan's point in Trust Me is not so much that we should give up well-reasoned, rational arguments – in fact he shows a framework for doing this. Instead the point appears to be that we all too often ignore the emotional conversation that's happening in the midst of the intellectual argument. Much of the emotional context of the conversation comes from five scales on which your audience (of one or many) can be measured:

Open-Closed – Is the person open to your ideas or walled off from the possibility of reaching common ground?
Sincere-Insincere – Are they simply humoring you to get what they want?
Allied-Opposed – Are they in your camp or forming embattlements to lay siege to you?
Powerful-Subservient – Do they view themselves has having more power in the situation, or view you as being the powerful one?
Committed-Uncommitted – Are they committed to what you're saying or merely interested?

Morgan encourages that everyone practice what he calls empathetic listening. It's also been called reflective listening. The basic premise is that everyone wants to be understood and that by restating their information – in your own words – you've indicated that you do understand. The in your own words is important because a tape recorder can replay he words – by changing the words you indicate that you've assembled it in a way that makes sense for you.

There's a subtlety in this as well, by carefully reflecting back what they're saying you can establish the frame for the conversation. You can slightly shift what the person said into a frame that makes the outcome that you're looking for easier. For instance, if your spouse says that she's displeased when you don't place your socks in the hamper, you can respond with "I hear that you're happy when I put my socks in the hamper." The meaning is the same but the rephrasing takes on a positive frame – and therefore is more likely to lead to better outcomes. (Framing is also covered in Thinking, Fast and Slow.)

Ascribing Intent

One of the challenges that often comes up when you begin to pay attention to the second conversations is determining the meaning behind what you're seeing. Ekman was fond of saying that you can tell that someone is suppressing an emotion – such as anger – but you can't reliably predict the reason. Said differently, you can determine that they had a flash of emotion and that they're suppressing it but not the intent of the suppression. You could accuse me of something and see a flash of anger which could indicate that I feel like I'm going to get caught at something – but it could just as equally mean that I'm frustrated because I seem to be always accused of things I didn't do.

One of the things that we do naturally is to ascribe intent to the things we observe in the world around us. If we go back to Thinking, Fast and Slow, we're always on the watch for things that may be harmful to us. Predicting intent – no matter how poorly – is what we do. The problem is that we get this wrong so often that it's laughable. That is it would be laughable if it weren't so sad.

Consider a meeting of subordinates and two of them square off on an issue. One may be thinking that the other is trying to grandstand, to demonstrate how they're better, or one-up the other. However, the intent can be completely the opposite – to prevent a respected peer from embarrassing themselves. Based on our perception, and trust, of the other person we'll assign whichever intent we believe closely matches our expectations of them but who's to say what the intent really is? In most cases I find that the person who was speaking rarely recognizes what their intent was themselves.

Four Steps

Morgan believes that there are four steps to creating authenticity and charisma. The four steps in Morgan's plan are:

Being Open – Be comfortable as you would be with a friend.
Being Connected – Establish a rapport with your audience to make it easier for them to hear you.
Being Passionate – Express your emotions
Listening – To maintain your connection with the audience you'll need to listen to them.

While I believe this is the right path, there's an aspect of this that feels like "and then the magic happens." To some extent Morgan leaves the "how" of some of these steps as exercises for the reader. This makes sense given that each of us is a unique creature and we've got different issues that we need to work through. However, I can see how it might be frustrating for someone looking for a recipe to realize that there isn't a recipe as much as there's a philosophy of cooking being covered.

While these rules are about communications in general, Morgan does have specific feedback about the verbal conversation – the rhetoric.

Rhetoric Rules

Morgan doesn't ignore the written or spoken language – it's an important part of the overall communication. Here are Morgan's rules for persuasive rhetoric:

Persuasive rhetoric is about phrasing your arguments so that your listeners can hear them.
Persuasive rhetoric has a clear goal in mind and is usually transparent about it.
Persuasive rhetoric deals with problems and solutions
Persuasive rhetoric deals in stories, facts, and tropes.
Persuasive rhetoric passes the test of four critical questions:
1. Is it articulate?
2. Is there a real alternative?
3. Is the idea consequential?
4. Do the words shock but not surprise?
Persuasive communication cuts through the clutter of information overload by dealing with safety issues
Authenticity and charisma in content require self-revelation in this confessional age.

In some of these I feel like I do a good job – and others not-so-much. I've been a consultant for a very long time so I'm very focused on listening to clients and trying to reflect back their language in our communications. That's quite directly the way that I try phrase my arguments so the listener can hear them. The more I can get into their lexicon, vernacular, or language the better.

Where I sometimes struggle is where I'm trying to shock – but not surprise. The difference here is subtle and it's something that I remember from my comedy training. You can get a laugh by misdirection – it is the classic way to get a laugh. Make someone believe you're going someplace and instead end up someplace else. However, there's another way to get a laugh – a Duchenne laugh – tell a universal truth that's undiscovered. For instance, in the SharePoint space most folks have either a governance problem – their environment is out of control – or the opposite problem they don't have anyone using it. So when you put those two together – If you don't have a governance problem then you must have an engagement problem – you'll probably get a laugh because while people understand these things and it makes sense, they've never connected the two. The point about surprises is that any idiot can be different – the trick is be different in a meaningful way. (See Brand Is A Four Letter Word.)

Morgan also notes that intimations – not directly saying something – often have a magnetic or comedic effect. That it's great to experience people who are able to communicate their idea without directly saying it. This is something that the misdirection of comedy teaches.

A final important point about rhetoric is about the tone of your voice as you speak. There's two components resonance and presence. Presence is the nasal quality that makes the voice easy to be heard. Resonance is the reverberation that allows you to connect with others. By speaking at your maximum resonance point (Morgan explains how) you can more consistently connect with your audience.

Principles

Morgan's principles for authenticity and charisma are:

When the verbal and nonverbal [communications] are aligned, you can be an effective communicator. When they are not, your audience will believe the nonverbal every time.
We interpret body language unconsciously in terms of intent.
In the nexus between the verbal and the nonverbal conversations is persuasion, and that's concerned with leading someone else to make a decision. This is the essence of leadership communications.
Decision making is largely an emotional, and therefore a nonverbal, process
The source of our nonverbal conversation is deep in the oldest part of the brain in emotions, survival relationships, and the other fundamentals of human connection and our connection with our surroundings.
To become a persuasive communicator (and leader), you must first consciously master and then control your second conversation.
To master the second conversation, you must make yourself aware of your own unconscious behavior and that of others.
To control the second conversation, you must focus on your emotional intent rather than your conscious awareness.
To be perceived as an authentic public person, you must align your nonverbal and verbal conversations. This means aligning your emotional intent with your conscious thought.
Authenticity and charisma derive from becoming open, connected, passionate, and listening with and to your audiences.

Postures

Before I end, I have to share three postures that Morgan discusses in Trust Me. These postures start from a fully upright position as if the top of your head was being lifted by a string and from there small differences change the way that people will interpret your stance.

Submissive, Intellectual, Uncertain, or Deferential – Head forward of perpendicular
Sexually charged – Pelvis forward
Authenticity, trust, heart – Shoulders back but not tense, head high, small of back forward and stomach in

It's been a while since I've watched old movies of Elvis performing but it is pretty clear that he had at least one of these postures perfected.

Spaces

I want to leave this review with one final piece. That is the impact of space. How close you're allowed to get to someone demonstrates how much they trust you and connect with you. In the diagram below (which is to scale) you'll see different levels of closeness and connectedness based on whether you have a social, personal, or intimate relationship with the other person. It makes a difference – Trust Me.

Categories: Professional, Book Review | 0 Comments

Saturday, November 17, 2012

Book Review: Brand is a Four Letter Word

On one hand I don't expect my audience to be trying to brand a company and in that sense I expect that some of my reading on marketing is uninteresting. On the other hand, I realize that many of my readers are trying to brand intranets or are working with clients that are branding intranets. Not having a solid understanding of marketing can be frustrating as the marketing department will try to convince you that something is essential – when there's no research to support that position. This has led more than one of my colleagues to exclaim four letter words while working on branding and that's why I believe Austin McGhie's book Brand is a Four Letter Word is so appropriate.

I should say that most of the time when the word brand comes up in the SharePoint context it's followed by "ing". We tend to think of branding the portal. However, as McGhie points out, branding is the prize. It's the goal that the market (or your market of employees) offers up to you once you've positioned yourself. Marketing, he claims, is the art of positioning. Brand is the badge that states that your market places a higher value in you than the utility you provide.

Those are strong words. Branding has been confusing to me since I couldn't quantify what it was – and wasn't. As I've been working on the branding for the SharePoint Shepherd's products I've been playing with web site designs. I've been trying to define the visual interface of the web site but my greatest struggle has been clarifying my thoughts around what the brand should be about – or rather how the products should be positioned in the market. McGhie defines the real work as "defining, clarifying, targeting, capturing and holding your position." In other words, the problem isn't the web site (well it might be partially the web site) but it's the clear understanding about what the positioning is.

Positioning

McGhie spends quite a bit of time talking about ways to think about positioning including how to understand your market both through research and through the development of insights. Along the way he knocks down the idea that you have to be "out of the box" to be successful – including sharing the perspective that any idiot can be different – the trick is being different in a way that's relevant to the audience.

Positioning is designed to make the unique benefits of your product or solution stand out so profoundly that no one can miss it. Consider those folks who are in the unfortunate position of job hunting. They approach their friends with a response like "I don't know what kind of job I want." As a result the friend has no way to help because they don't know how to connect the job seeker with something that might be interesting to them.

The end goal of positioning is that the market reward you by calling your positioning a brand.

Shorthand

Branding is simply shorthand. It's your message encapsulated into a neat package that the consumer understands. If you read Starbucks you think coffee. If you read McDonalds you're going to think about inexpensive fast-food and golden arches. So doing the positioning for your brand is all about creating the result you want to see of the shorthand.

The ultimate shorthand is when you become the stand-in for the product category that you're in. Facial tissue is called Kleenex based on the strength of the brand. That's serious shorthand.

Attention and Persuasion

There was a time when marketing meant persuading your market to take an action. You had to convince your market that you were the right choice when standing in comparison to others. However, the problem is no longer a problem of persuasion – of comparison. We're now so saturated and overwhelmed with information that the key isn't persuasion it's attention. We're constantly under assault by advertising, by too many options, and an overwhelming ocean of information. If you want to build a brand in today's world you have to get attention.

You have to break through the filters that every consumer has created to keep their mind from becoming hopelessly overwhelmed with all of the information that is available to them every moment. That isn't to say that there's no distance between someone becoming aware and them taking action. The book Fascinate told us that you had to first get attention, then remembered, and finally acted on. Similarly, the book Diffusion of Innovation talks about the difference between knowledge, attitudes, and practice. That is while our focus needs to be on attention rather than persuasion, we cannot forget that attention alone isn't enough – it's just the scarcest resource in today's economy.

Karate and Judo

Over the years I've had the opportunity to watch markets evolve. I can remember early into the enterprise search game the players and their challenges. It generally wasn't hard to sell someone who understood the value an expensive solution – but when the same companies who were commanding high-dollars for their solutions tried to broaden their market they quickly faced issues. They quickly got mired in the process of educating the market as to not what they do – but what the market is and why it's important. Once a person understood what search was and what was possible, selling the actual product was easy.

McGhie makes the point that you don't want to have a karate fight with your market. Karate is meeting force-with-force. Instead you should be fighting with Judo, which focuses on redirecting the existing force. You're not going to win an all-out battle with your market by using your force to fight the force of the market. You'll win by directing the market forces in the direction you want.

U is for Utility

We believe that today people are more me-focused than ever. They'll step over a dead body to get a free trinket. Speaking as someone who has done a free book signing at a conference, I can tell you with certainty there's a certain pull to the idea that it's free. However, there's also the other side of the coin. What does it do for me? Speaking for me personally, I'm encouraged to upgrade to the latest gadget. I'm certain I'll be encouraged to purchase a Windows Phone 8 device. However, just as I did with the Windows Phone 7 devices, I'll probably apply very little effort to getting one. Why?

Well, it's primarily a question of differential value. What will the new phone do for me that the iPhone that I carry now doesn't do? It's got a cool new interface (which I'll have to learn) and it might do some things better than the iPhone but at the end of the day what new utility will it provide? Speaking as someone who wrote a book on Windows Phone 6 devices (Mobilize Yourself!: The Microsoft Guide to Mobile Technology) I'll tell you that the core features I need – making/receiving calls, sending/receiving text messages, and sending/receiving emails have all been solved for some time now.

Consumers are more focused on the utility than they have been in the past. What will it do for me? Am I willing to pay the price for that utility?

Disrupt or Be Disrupted

The book Demand quoted Jeff Bezos as saying "If anyone is going to destroy our online shopping business model, it's going to be us." Brand is a Four Letter Word encourages you to realize that if you're not acting disruptively – it's likely that disruption will be visited upon you by a competitor.

The market is going to change – because that is what markets do. You can choose to be in control or at least in the lead of these changes or you can choose to react to them once they've already happened. If you fear disruption, if you're unwilling to try new things because you're fearful about how they will impact your business, then all you need to do is wait because disruption will be visited upon you. Whether you're in the package industry and FedEx comes along and makes shipment tracking easier, you're in the book shop business and Amazon comes along with an online model, or you're in the watch business and you're realizing people use their cell phones for the time now.

Designing for a Core Customer and Taking Your Target Market

When motorcycles became associated with unsavory characters there were numerous companies that tried to distance the images of bikers from the gruff and tough image that had become coupled to the biking culture. However, one organization – Harley Davidson – embraced the image. They focused on the man who was trying to live out his rough loving persona. As a result, they've been very successful at selling their motorcycles but more importantly they've created a following and culture. They've identified that their core customer is a rough and tough person – realizing that by having this as the core customer they'll take a much larger target market.

McGhie uses the example of Nike and their focus on their core customer – knowing that they'll be successful by taking the larger target market that wants to identify themselves with the core customer.

Move the Undecided

The final point I want to elevate from Brand is a Four Letter Word is the concept that you're not trying to move the people who have either decided for – or against – your product firmly. You're trying to move those folks who haven't made a firm decision on where to go. You're trying to move the undecided. You should spend little time convincing those who have already decided to purchase your solution. You also shouldn't fret about those who've already decided to do something else.

If you're frustrated by the marketing and branding process, you may want to read Brand is a Four Letter Word for yourself.

Categories: Professional, Book Review | 0 Comments

Thursday, November 15, 2012

Article: Size and Scale of SharePoint 2013 in the Desert

At the Microsoft SharePoint Conference 2012 being held in the desert in Las Vegas, NV, there's a lot of talk about how SharePoint has grown up. At 11 years (77 in dog years), SharePoint's grown older and wiser. Instead of being seen as a departmental solution to collaboration needs it's an enterprise-scale platform for creating content solutions.

Secret SWAG

Next week at the Microsoft SharePoint Conference in Las Vegas, I'm starting a new giveaway – and I want you to be a part of it. I had a custom coin made. The coin shows Thor Projects on one side, and The SharePoint Shepherd on the other – more or less the two different sides of my world and personality. It looks like this:

This is intended to be a giveaway for folks who interact with me during presentations. If you ask a question, I want to give you one. I won't explain what it is in the session. I plan to hand it over and keep moving on. Clearly, as I've said, it's a coin. I found myself flipping a coin like this over and over in my hands on calls and while I was bored and decided that you should be able to get one as well.

Because you're reading my blog, I want to extend a special offer to you (and to your friends you want to disclose the offer to) – if you come up to me and hand me a business card, I'll hand you one of the coins. I'm only going to do this at the SharePoint Conference. After the conference you'll have to interact during a presentation to get one – here's why.

Anyone who has one of the coins can mail it back to me for a $25 discount off of any of the DVDs that we sell. That's right, $25. Why would I do this? Well, I value people interacting in my sessions more than you know. It makes the presentations fun for me – and everyone else. I also value you because you are reading my blog and keeping connected. By the way, if you're not signed up for the SharePoint Shepherd newsletter – you should do that. We offer some sort of a special offer every month through that list. I'll make an even more impressive deal to that list in a month or two – so you'll want to make sure you get one.

One other detail, coins are heavy. I'm only bringing a few with me to the conference, so you'll want to hit me up early to get yours. My session – "Using TypeScript to Build apps for Office and SharePoint" is Wednesday morning at 10:30. I follow that up with an AvePoint theatre presentation at 12:45 and then two book signings. I don't expect that I'll have any coins left by the time I'm done, so look for the Shepherd's staff earlier in the week and get yours.

Thanks for your continued support

-Rob

Categories: Professional | 1 Comment

Monday, November 05, 2012

Why JavaScript Makes Bad Developers

I've bumped into JavaScript from time-to-time through my professional career and up until recently I've been able to keep a relatively safe distance from it. I always had a developer who I could assign to do the JavaScript stuff. It was generally a relatively small amount of the overall framework and it was easy enough to assign to a junior developer to work on. However, more recently it's become a more "real" part of the overall development experience. Therefore, I felt like it finally became something that I had to get neck deep into. What I've found is that it's changed a lot over the years and it's picked up a lot of scars.

My goal for this post is to help the developer to help development managers understand what they're asking their developers to do, to talk about how the techniques for writing JavaScript teach bad habits, and address that history is repeating itself.

Rewind: Object Oriented Programming and Agile

When I was first starting development object oriented programming wasn't an assumption. We were working with non-object languages like FORTRAN and COBOL. We were dealing with C – before the ++ was added. In fact for years object oriented programming was treated with skepticism. I can vividly remember doing a full object architecture for an ecommerce site when the project manager/engagement manager came back to me freaking out that the performance was bad. By the way, bad was some pages at 5 seconds to load. Anyway, he was all up in arms that we were going to have a slow site and that it would never be responsive. The discussion ended with me upset – knowing that it was trivial to address the issues – and him insisting that I prove that the code could perform. It took me about 2 hours to insert the caching and list-object generation into the framework and to reduce our page load times to sub-second. His skepticism was removed – and I turned off all the caching so that we could do the rest of our development and debugging.

The initial reports with object oriented programming was that it was a better system. The initial research seemed to show that switching to an object oriented approach improved developer productivity. However, the push-back on these studies was that the developers who were doing the object oriented development were better developers. Given that Fred Brooks in his classic work The Mythical Man-Month quoted developer productivity rates can vary by up to 10 times between two developers, the improvements in object oriented development could easily have been explained by better developers.

I should say that I don't believe that a language causes better development practices, rather, I believe that it encourages them. Back in 2004 I wrote an article "What does Object-Oriented Design Mean to You?" talking about how the language doesn't make you do the right things. However, it can encourage the right things. Kurt Lewin, a German-American psychologist, said that behavior is a function of both the person and the environment. That is that behavior can be explained by some interaction between the person and their environment. You can put a good developer in a bad situation and they'll succeed. You can put a bad developer in a good situation and they'll succeed – and the reverse is also true. So while I'm making the point that languages influence good or bad behavior, and later I'll make the point that our habits are formed by our behaviors, I should say that our goal is to encourage the right behaviors to develop the right habits.

A similar argument about improvement was made in the early days of agile development practices. It was 6 years ago when I was investigating how agile was supposed to be done. (I read and reviewed numerous classical software development books and agile development books: Agile & Interactive Development: A Manager's Guide, The Rational Unified Process Made Easy: A Practioner's Guide to the RUP, Peopleware, The Psychology of Computer Programming, Agile Software Development with Scrum, Agile Software Development, Dynamics of Software Development, and Software Craftsmanship – The New Imperative) The arguments against agile fell into two basic categories. The first was that agile was just an excuse to not document things. Numerous teams wanted to try agile by following the steps without understanding the principles and did end up floundering and putting a bad taste in the mouths of large organizations. This lead to the second argument – we don't' believe it works. This was placed in opposition to research that seemed to show that it did work. Teams wrote more code, had fewer defects, and the customers were happier with the end solutions. However, the argument was that the best developers worked on these projects and therefore they would have done better whether or not the methodology was better – or not.

Let me flip this argument around and say that I'm convinced that there are some truly gifted developers who will be able to make any technology, methodology or approach work. I believe that it's absolutely possible for development in JavaScript to be done well by a select few developers. I'm just not sure that these magical developers are either plentiful nor do I believe they are in your organization. (Present company excluded, of course.)

So by drawing parallels to object oriented programing and agile methodologies, I'm not saying that JavaScript is a better approach, in fact, I think you'll find by the end of the post that I believe it's not a step forward but rather a fairly large step backwards – I'm simply illuminating that I'm aware of history and how change is necessary to make improvements – however, it has to be the right change. I know where we've been in this craft we call software development and I believe I know a step backwards when I see it.

Centralized, Decentralized, and Back

One of the subtle shifts that's been happening for a long time is the move of processing power from a centralized authority to the client and back again. We started with "dumb" terminals. Whether you were working in an IBM world and knew the numbers 3270 (mainframe terminal) and 5250 (mini-computer terminal) or whether you were looking at a terminal starting with VT (Unix, VAX, etc.) you were staring at a very simple device that did little more than relay keystrokes and receive character updates. The shift came when PCs started landing on users desks. While they were being used to access the host computers they started running applications locally –and those applications seemed more responsive and more in-tune with the way that the user wanted to use the machine.

So we started to pull applications off the centralized processing platform on to the relatively immature PCs. We got ISAM databases like Dbase and FoxPro. We started developing "trivial" applications from the point of view of the central processing host but invaluable from the users point of view. As the PCs got connected to local networks we started the client-server revolution. In this time we used the PCs to do the processing and interaction and had centralized data storage.

It wasn't long, however, before we discovered that some operations are best done right were the data sits. Enter databases like btrieve and the start of SQL databases. Ultimately the pendulum was swinging back from the client to the server as we moved more and more logic back to the server side for reliability, consistency, and stability. By the time the Internet was becoming popular we had moved most of our development back to core servers. We had intelligent interaction on PCs but all of the meaningful processing happened on the central server.

Internet browsers were created as a way to navigate information that was linked together. Over time users began demanding richer experiences from the web and over time we started enhancing what we did on the client again. We developed plug-ins that operated like mini-operating systems running in the browser. Flash is perhaps the most profound example of this. We moved back into a model with central storage and distributed processing.

For better or worse we oscillate between centralized processing and distributed processing. It's the latest move for more processing to be done on the client side – without the need of specialized plugins that has driven the demand for JavaScript. However, I'm ahead of myself. We have to talk about what JavaScript even is.

What is JavaScript?

JavaScript is a scripting language which was designed to be used for lightweight applications and scripting. It was designed as an alternative to the strongly typed, compiled, and "heavy" Java language. That was more than 15 years ago. Since then it's evolved into a tool that folks are using to solve enterprise class problems. As a language JavaScript is supported in nearly every browser on the planet. It's a scripting language that is dynamic. That is JavaScript doesn't rely on well-known types. In fact, at least one of the primitive types that we expect in languages – the integer – is completely missing from JavaScript.

Really, JavaScript is all about collections. A collection may be an "object" meaning that contains name-value pairs with the name being what people would consider to be a member of a class. The trick here is that the value portion of this equation can be anything – including a function. In this way, you can have a collection of name-value pairs that act like we expect a regular strongly typed object to behave. Arrays, the other type of collection, is simply a collection of nameless objects. The final thing to realize is that a value may be another object – and therefore you can have deeply nested hierarchies of objects.

JavaScript as just being collections may seem like an oversimplification – but it is a really helpful simplification because you realize that you can dynamically add and remove items from a collection at any time and thus it's pretty different than a traditional typed language.

Why JavaScript is Good

There are some really great things about JavaScript. Because there isn't a rigid type system you can do things in JavaScript that are difficult to do in a strongly typed language. You can slip an extra member into an object and use it deep inside the bowels of the code. You don't have to refactor your methods between the top of the application all the way to the bottom to accommodate additional information – or even recompile. Conversely, without a definition of what you're passing around it's difficult to know if you're passing in the right things. Let's take a look at a few of the things that make JavaScript a useful language.

Cross Platform and Cross Browser

Perhaps the chief benefit of JavaScript is that it truly runs anywhere. Sure, Java -- to which JavaScript has effectively no relation -- claims that it runs everywhere but JavaScript actually does. It's hard to find a web browser or operating system that doesn't have a JavaScript interpreter. The interpreters have been getting better and better over the last 10-15 years. The result is that we have good interpreters of the language that are fast and mostly reliable.

The list of plugins that have tried to gain ubiquitous support and have failed is long and distinguished including Flash, Java, Silverlight, etc. Having achieved the goal of ubiquitous availability is an impressive accomplishment indeed. As a development manager it means that you're going to be able to build once – well, almost.

The unfortunate problem is that much like the HTML standards, teams interpreted JavaScript slightly differently. They added access to browser specific features through the object model for the browser that would be supported on one browser or platform – and not on another. As a result there was time spent detecting what browser you were in to determine the browser specific way to approach the problem.

Libraries

The good news is that a set of JavaScript libraries began to emerge to allow for the developer to ignore the browser specific quirks. Chief among these libraries is jQuery. jQuery abstracted a way many of the differences and simplified many of the common – but complicated things that developers needed to do. jQuery handles everything from selecting items in the document object model (DOM) to making AJAX calls. All-in-all it's the libraries like jQuery that dramatically improve the ability to develop with JavaScript.

With libraries for nearly everything that you might want to do, JavaScript's functionality has been greatly enhanced. The problem is that you have to download and learn these libraries to be effective at them. It means gathering up bits and pieces from different sources and trying to patch them together into a meaningful quilt of code. Sometimes that works well and other times not so well.

Why JavaScript is Bad

If you ask most professional developers (as compared to a Hobbyist, see "What's the Difference between a Hobbyist and a Professional") about JavaScript and you'll likely get non-positive responses. Most professional developers – that is those that get paid – don't like JavaScript because it's hard to make a craft of developing when you're limited by your language. Most professional developers have come to expect a set of tools to help them develop more reliable code and to create the code faster in the first place. JavaScript isn't bad for tying a few loose things together, however, developing enterprise scale applications is not what it was designed for.

Language and Library Richness

Unlike Java and .NET, JavaScript isn't out of the box equipped with an array of libraries to call into. This means that you're always on the search for a third party library that may be helpful to you. Simple things, like converting a play position from a video file and getting it to a standard text string expressing hours, minutes, seconds, and frame can take a hundred lines of code or so. (I just wrote this so this isn't an arbitrary number.) The simple – like leading zeros for numbers – isn't simple. Without the concept of an integer, integer division means grabbing the modulus of 1 and subtracting it from the number to truncate the number.

Professional developers who are used to ignoring some of the low-level functionality will be continuously frustrated by the need to develop their own library of routines to do the things that they've taken for granted in other languages. Sure I listed libraries above as a good thing for JavaScript –and it is. However, it's filling the fundamental void which exists because the language doesn't have a library of useful functions that it is built upon.

The problem is that libraries and operating environments clash with one another from time-to-time and because of this you find yourself working on getting code to work together. Consider a situation where two libraries require two different versions of jQuery, how do you get each of the libraries gets the jQuery that they need?

Static Typing

I remember writing code in C and C++ eons ago. I remember that my development environment was a glorified text editor. I remember needing to put print statements in my code to see what is going on – and that the idea of interactive debugging was a dream. Today because of strongly typed languages and better development environments we've learned to rely on our ability to interactively debug and more importantly we've learned to rely on the feature that Visual Studio calls Intellisense.

Hit a period and you're going to get a list of things that you can do with that class. You don't have to remember the method name or property name. You can browse from the list of items and simply select the item you need. From a cognitive load/instruction perspective this dramatically reduces the amount of mental processing required and makes it both easier and quicker to work on code. (You can look at my article for TechRepublic "Squeeze more out of the construction phase of application development" for a historical perspective on improving developer productivity.) In my book reviews for Efficiency in Learning and The Adult Learner, I speak more about the impact of cognitive load on learning – the same applies to development. The higher the load the lower the developer productivity.

A quick sidebar to realize that the primary constraint for developing code is the amount of workload the brain is doing. Developers are running mental simulations of how the code will run, they're tweaking the code in their heads before they type it in. (See Sources of Power for more on mental models.) The in-head compiler doesn't care about method names, it cares about operations and actions. Having to remember the exact method name is an overhead that distracts the developer from their primary job of making the logic work. In this way our new development environments have made development quicker – but that requires that the development environment know what options there are. When you're dynamically putting in your own name/value pairs the environment may not know what is and isn't expected.

The Intellisense functionality is really an extension of compile-time checking. That is a static analysis of the code to determine if there will be a problem. This isn't possible in a true dynamic language. As a result not only do you not get intellisense, you don't get the protection of the compiler telling you that you're making a mistake. We know that the sooner that defects are discovered the less costly they are to resolve. If it's resolved by Intellisense it's really small. At compile time larger but still small. When you discover the problem in a developers debugging session it's getting large enough to be called something other than small. If you have a problem that only occurs sometimes and is data/execution path dependent, it becomes expensive to locate. That means more development costs.

Code Structuring

Software development is still struggling as a profession to become professional. Exercises like the Software Engineering Body of Knowledge (SWEBOK) have attempted to catalog what we know about software development. As we attempt to dig our way out of the primordial soup of software development practices we've found that there are some things that are helpful. Like object oriented development mentioned above, we've discovered that there are techniques that simplify problems for our feeble human brains and therefore lead to better software. Some of the things we know aren't effective in software development are the default behaviors in JavaScript.

A long time ago we learned that global variables are bad when used incorrectly. They led to spaghetti code that was difficult to debug and difficult to maintain. In JavaScript, by default, all variables are scoped at a global level. Without the concept of classes, or modules, we're left with the default that everything has to be a global variable – or a local variable inside of a function. In order to mitigate the impact of this, we've built patterns to isolate the scope of a variable inside of JavaScript – but those patterns are working around the default behavior of the language.

Further, without a formal concept of namespaces, modules, or classes we find ourselves fighting to create structure where no structure is implied. It means that the default path for writing JavaScript is a bad path. Structuring code requires even more thought and focus because the language doesn't lead to the behaviors of isolation that lead to structured code – and better developer productivity.

Clear Text Code

One of the other issues when talking about JavaScript is that the code is all clear-text. While this is good from a debugging perspective, it's bad from an intellectual property perspective. It means that it's trivially simple to look at someone else's implementation of something in JavaScript and copy it. This reduces the competitive advantage for developing a solution to a problem and means that sensitive or proprietary techniques for processing aren't great fits for JavaScript.

Having source code for someone else's library may seem like a great thing in terms of helping developer productivity, however, from a corporate standpoint where they're building their business on the competitive advantage of the code – through better operations or through the sales of licenses to use the code, the idea that your code is just hanging out there for all to see is very concerning – and potentially a barrier to development.

In my practice as a software developer it's the standard that the client will own the intellectual property that I develop, in other words the code is theirs and they're not going to share it. In some cases I've had clients who have allowed me to share this code with other clients – however, only in cases where the second client didn't compete with the one who had paid for the work.

Development time

If you get to it the most precious resource in any development project is the developer or perhaps the architect. Developer productivity is absolutely essential to getting projects done – and on this score, JavaScript doesn't do well. If you read the classics of software development like Peopleware, Code Complete, or The Mythical Man-Month, you're realize that we've been fighting for developer productivity for a long time. I've not seen any formalized research on developer productivity in a strongly typed language – like C# or Java compared to JavaScript, however, in my informal conversations about it and in my experience with development teams, I find that developers are roughly 2 to 10 times faster at developing in a strongly typed language than in JavaScript. I'm willing to attribute some of this time to learning time, however, much of it has to do with the inability to build good tooling to support the development process.

Compositing

Many development scenarios today involve compositing. That is taking pieces from different places and getting them to work together. As mentioned above getting two libraries to exist in the same space can be challenging. If you load two different versions of the same library – jQuery for instance – how do you ensure that the most recent version is the one that is being used? Similarly, if the JavaScript is using targeting to find the elements – what happens when you include two sets of the same code on the same page – as might happen on a portal?

While these challenges are not insurmountable, they're problems for which there aren't great – generically applicable – answers.

Client Performance

The cliché answer given by a software developer about what's wrong with code is "It works on my machine." That's probably true. However, it's also equally likely to be true that the developer has a faster, better machine than most of the users who will be using what is developed. Developers get faster machines to be able to do their job. What happens when their JavaScript takes a reasonably long time on their computers? Eric Shupps was speaking about jQuery performance in his initial and follow up posts on the topic. Basically, Eric was sharing that jQuery walks the document object model – and thus is sensitive to larger pages and slower machines. By moving to JavaScript we can decentralize the problem and therefore make it easier to scale, however, we also make the problem sensitive to the remote machine.

If the JavaScript interpreter is broken then the page is broken. If the remote machine is underpowered then the site will appear to be slow. In most cases we'd prefer to have a great deal of control over our performance – and JavaScript is at the mercy of the users' machine. The user-side problems can create a bad perception of our site.

Debugging

Perhaps the most frustrating thing about JavaScript has to be the debugging experience. It's not quite back to the days of print statements to be able to see what's going on. Development tools in FireFox – called FireBug – and in Internet Explorer – called Developer Tools – do allow you to interact with the JavaScript and see what is happening – but you do so disconnected from the authoring environment. Once you've determined the source of the problem you've got to go back into your development environment (Visual Studio?) and make the change then reload the page. This is certainly not the most developer friendly workflow – even if it can be used to accomplish the goal.

How JavaScript Makes Bad Developers

The title of this blog post may be slightly provocative. How can a language make someone a good or a bad developer? Well, the answer is really found in Kurt Lewin's description of behavior being a function of person and environment. Many of us would probably agree that if someone behaves badly they would appear to be bad. And that's really what I'm saying here. If someone does development behaviors (global variables, etc.) then we would label them as a bad developer – and since JavaScript makes this the default behavior, how could we do anything but say that JavaScript makes bad developers. But let's explore this more deeply.

Making the Bad Easy and the Good Hard

If we accept that bad behavior is a function of the environment then why does it matter? Well, it matters because we're establishing "norms" about how development should be done and establishing bad "norms" will create bad habits – and habits are hard to break. So if you're used to neither having to think about how you're structuring your data nor the scope of variables then even when in another language – you won't get this the appropriate amount of thought.

I once had a developer who had grown up doing ASP development. In those days it was VBScript that was being used to build pages and just like JavaScript you could declare variables on-the-fly. That is you could just start using a token and it would become a variable. The problem with this – like with JavaScript today – is that you would make a typo (we're back before Intellisense here) you would accidentally declare a variable and create problems for debugging. They added the ability to put 'Option Explicit' at the top of the files which would require that you explicitly declare variables. My developer wouldn't do it – and would call me for help.

After numerous rounds of telling him to use 'Option Explicit' because I had found a simple typo in his code that created a problem I eventually had to tell him that if he called me over to debug his code again without option explicit at the top I'd have to fire him on the spot. This is not one of the brighter spots of my management career but I got his attention.

The discussion that followed was that he felt like it just slowed him down and that it was a polish thing – the thing that you did to make the code "right" at the end. The problem with this is that wasn't a ceremony thing (Ceremony is a word used in agile to talk about activities that don't generate results.) It was discipline to get him to think the right way about problems so that he could reduce defects. I wanted him to think about his variables and what they were being used for. I should say that JavaScript now has a similar concept "use strict".

The point here is that we establish what the normal are – and pattern our thinking based on what we expect out of a language. So if we expect all variables to be dynamically declared at a global scope, we'll design that way – despite the research that says this is a bad idea.

You'll note that here I'm blaming the system not the developer. Nothing is accomplished by saying that they're bad developers. Fundamentally I believe they have the potential to be good developers, if not encumbered by the language or system. I mentioned briefly in my review of Diffusion of Innovation that blaming people means you can't solve the problem – blaming the system means you have something you can fix.

Bad Behaviors lead to Bad Habits

If we take the developer out of the language and put them into a language that requires strongly typed variables and offers them a local scope won't they just change because of the environment change? Yes – and no. In the clear-cut cases, sure. They'll default to the specific knowledge they have but in the less clear-cut cases those who are used to and accept global variables will leverage them more often.

Take for instance the case of a global logging class. It's used just to log things out in case there's an error. In 2002 I wrote an article "Focus on Functions" for Developer.com. In the article I talk about method (function) signatures. My strong bias is to pass in everything that is needed to function with the smallest objects possible and make the methods static. I do this to minimize unintended consequences. (It drives my testing friends nuts because static methods are hard to test.) So I'm more likely to include a logging class as a parameter to my methods than someone who's comfortable with a global scope.

I purposefully provided a case where the right answer may be a globally scoped variable (or more appropriately property so it can self-initialize). However, what about passing around a SQL connection – or not. There's greater testability when you can easily and consistently establish context.

The bad behavior that was learned through no fault of the developer will continue on into new languages simply because it has become the "norm" for how they develop.

An Argument against Being an Ostrich

I need to end with a call to continue to learn and grow. Whether JavaScript is the right answer for you – or not – exploring new techniques, tools, and approaches are a good thing. In another old article, "The Great Divide", I talk about how people get stuck by not seeking out new and better ways of doing things. I'm not suggesting that you don't do JavaScript development or you ignore the changes that are happening in our marketplace. Instead, I'm advocating that you go in eyes wide open – and that you look for ways to minimize the pain. Right now, as it comes to JavaScript the way I'm looking at this is through TypeScript.

Categories: Professional | 0 Comments

Wednesday, October 31, 2012

Book Review: Humilitas-A Lost Key to Life, Love, and Leadership

If you've been reading my blog – or even just the book reviews for a while you may have realized that I'm on a voyage of self-discovery – and it's a voyage that isn't even close to its end. I'm constantly trying to improve my understanding of psychology, sociology, and leadership – among other skills. My backlog of reading on these (and other topics) can feel overwhelming to me at times. I bring this up because I can already hear some of the potential comments about reading the book Humilitas – "So now that you've read the book you probably know everything there is to know about humility." Um, no. The truth is that this the third book that I've read about humility. The other two, Humility and Humility: True Greatness, didn't speak to me greatly enough to write a full book review on them. Not that they're not good books – they just didn't speak to me clearly.

I read these books because I realize that a lack of humility has been a barrier in my life. It's like the pervasive smell that is in your clothes, in your hair, and in your world after going to a bon fire. Every time you believe you've rooted out the smell there's another whiff of it. Humilitas ends with a quote from CS Lewis, " If anyone would like to acquire humility, I can, I think, tell him the first step. The first step is to realize that one is proud. And a biggish step, too. At least, nothing whatever can be done before it. If you think you are not conceited, it means you are very conceited indeed." In short, the moment you believe you've obtained humility, you haven't.

I remember years ago I was playing a game Ultima IV: Quest of the Avatar the goal of which was to accumulate eight virtues (honesty, compassion, valor, justice, honor, sacrifice, spirituality, and humility). I was asked a question in one of the dialogs. "Are thou the most humble person on the planet?" (My apologies if the quote isn't exact.) I can remember pausing and thinking that this was an awful question (which means it was brilliant). I had already earned the humility portion of the avatar, so I was humble. Being at the time 13 years old or so I answered yes. The game responded with "Thou has lost an eighth" a few times because I lost humility and honesty, which in turn caused me to use several of the other eighths that required the 'truth'. It was profound because I had been working quite hard to complete the game and in one moment I had lost half of the progress (four eighths). For all the evils that people find in roll playing games – this was a very memorable moment for me about humility (and still not enough to teach it to me.)

Since then I've been accused of arrogance more than once by a variety of people – and I'll accept that it's a struggle particularly when someone challenges what I know. (Strangely enough, this happens more frequently than one would expect.) That's why I was surprised to see the book very early on say that contemporary western culture often confuses conviction with arrogance. While by no means an excuse for the lack of caring in my responses at times, it softened the blow for me. If I know that the technology is configured wrong, it won't work or it won't work right, it may not be arrogance to share this belief – in a caring way.

One of the really difficult things for me has been trying to rapidly establish my credentials in front of new audiences and clients. Conventional wisdom says that you have to introduce yourself to a client with your certifications, achievements, and accolades in an environment where you're selling. At a corporate level, look at how nearly every technology company has their "brand name clients" slide that lists who they've worked with. On a personal level nearly every conference I've spoken at suggests or requires a bio slide. It's the "about the speaker" slide that is supposed to help the attendees realize why the speaker is someone to listen to – and by extension why the conference organizers did their job correctly by selecting such great speakers to speak to you.

In a lot of ways, I'm a slow learner. It's been relatively recently – and at the specific suggestion of some friends (thank you) – that I've stopped doing the "about me" slide. I sometimes have a slide that shares my background – but it does so for the purposes of establishing how I think about the topic – not for the purposes of sharing my credentials. My audiences deserve to know where I'm coming from – but they don't need to know about my certifications.

I've been "taught" this in many different ways. Back at the NSA Conference (click for my experiences) I attended a session by Connie Podesta where she said something simple and profound "the privilege of the platform." Her talk was about how she made her business work. She was talking about her openness to learning, and how she was grateful for the privilege of speaking to another group of people. She never used the word humility – that I can remember – but she did demonstrate it.

Humilitas is the root of our word humble and the one word with two meanings "to be humiliated" and "to be humble". The book makes a point that being humble is not self-effacing. It's not a solitary virtue. It's not something that forced on you. Humility is others-serving and a choice. Humility is more than modesty or dignified restraint (modesta is its root word.)

I find it somewhat humorous that John Dickson spends so many words iterating and reiterating that his perspective – that Jesus the Nazarene dramatically changed the course of human events without asserting Christian beliefs. As a student of history he asserts that the change happened whether Jesus was the Christ, a profit, or "just" a carpenter. It's humorous to me because without any belief there is historical evidence to indicate the impact of Jesus.

It seems like nearly everyone struggles with humility. Thomas Gilovich did a study of 1 million (million!) high school seniors and 70 percent thought they were "above average in leadership ability." I don't know these students but I do know that at least 20% of them are wrong. It's not just students who struggle with humility. Gilovich found that 94 percent of college professors believe they are doing a "better-than-average job". Hmm, again at least 44% of these processors have to be wrong – statistically speaking.

Dickson makes the point that humility is a useful virtue. That it serves not only the community at large – because humility is defined as using power to help others – but also helps the individual. Humble individuals know that they don't know everything and so they're always trying to learn from others, to understand someone else's expertise.

Sometimes while presenting I have students in the classroom that want to demonstrate their knowledge by the questions that they ask. They ask about some specific situation that they already know the answer to. When I can't answer their question they provide their own answer. The humble person doesn't sit quietly and shy away from asking questions, rather they ask questions from the perspective of applying the talk to their situation – and to integrating the presentation into their way of thinking.

One last random thought, which comes by way of Amanda Gore. I was sent a link to one of her YouTube videos by a colleague. She was talking about a concept in Australia called tall poppies. Basically it's a negative way of talking about those who have high merit. This is connected in that if you hold your head up high – deserved or not – you may have someone come try to cut your head off. Not that you shouldn't own what you know but just that humility may be the right answer at times.

I invite you to join me on this journey by reading Humilitas.

Categories: Professional, Book Review | 1 Comment

<< Previous Next >>

Categories

Links

Archives

Other Blogs

What If There Were No SharePoint

Why Can't We All Just Get Along

What is TypeScript?

Who Can Use the Library?

What Does the Architecture Look Like?

Why not the JavaScript Client Side Object Model?

Developers Needed

Building a Cohesive Leadership Team

Behavior 1: Building Trust

Behavior 2: Mastering Conflict

Behavior 3: Achieving Commitment

Behavior 4: Embracing Accountability

Behavior 5: Focusing on Results

Create Clarity

The Playbook and Six Questions

Overcommunicate Clarity

Reinforce Clarity

The Grand Platitude – The Corporate Mission Statement

Hiring Practices

Refinement

Meetings

Advocacy and Inquiry

Meeting Types

Big Company and Small Company

Converting Strategy to Tactics

Wrap Up

Words Leading Gestures

Emotional or Intellectual Decisions

Ascribing Intent

Four Steps

Rhetoric Rules

Principles

Postures

Spaces

Positioning

Shorthand

Attention and Persuasion

Karate and Judo

U is for Utility

Disrupt or Be Disrupted

Designing for a Core Customer and Taking Your Target Market

Move the Undecided

Rewind: Object Oriented Programming and Agile

Centralized, Decentralized, and Back

What is JavaScript?

Why JavaScript is Good

Cross Platform and Cross Browser

Libraries

Why JavaScript is Bad

Language and Library Richness

Static Typing

Code Structuring

Clear Text Code

Development time

Compositing

Client Performance

Debugging

How JavaScript Makes Bad Developers

Making the Bad Easy and the Good Hard

Bad Behaviors lead to Bad Habits

An Argument against Being an Ostrich