Introducing the Skills Canvas for Defining Roles

Recently a old friend of mine from India, CEO Navin Kumar of iPRIMED, approached me about helping him bring his company’s services to the U.S. from India. iPRIMED is led by people from the IT industry and academia who are focused on enhancing workplace skills of graduates / entry / junior level professionals (for the IT and ITeS industry) by driving intrinsic transformation.

What he has done is nothing short of genius. If your company wants to offer up a way for your employees to grow some serious professional skills, Navin has what you need.

Inspired by his taxonomy of different skill sets, I came up with this canvas as a means for discussing a person’s growth areas. I share it with you: Navin gets the credit.

Download the Skills Canvas.

Scaling Agile Doesn’t Necessarily Lead to Business Agility

What we now call “the Agile Movement” seems to have gone mainstream around two years ago. When it did, late adopters showed up and started trying to do what they always do… re-define a concept in their own image. Well, if that image is big, fat, ugly and slow, I would rather they just “opt-out” and go extinct (aka allow market forces to let their companies die, thus freeing-up resources and people for higher purposes.) The irony is that the organizations that came late to the agile game tried to “adopt and scale agile.” In most cases they have not seen the gains they expected.

My hypothesis is that most are simply missing the point. Here is a review of the background context.

  1. Agile is an adjective, not a noun. Defining “Agile” as a set of processes won’t make an organization more agile in the market.
  2. Being able to give the market the product feature it wants when it wants it and for the price it is willing to pay while at least covering costs plus a profit that offsets inflation is THE only thing that matters. Any other focus and the organization will become extinct…and they are, at an ever growing pace!
  3. You can create reinforcing “double loop learning” structures that may create a culture that enables the right team dynamic in multiple teams; however, because corporations are complex adaptive human systems, you cannot scale a team dynamic.
  4. Being agile doesn’t mean automatically lowered costs of new product development or product operations and maintenance. Nor does being agile mean delivering the entirety of a product’s features to market faster than more traditional methods. It just means delivering the product features the market wants close to when the market wants them.

Based on these basic market precepts, I say the following not simply to be critical but to engage in much-needed critical response for the purpose of opening up rational conversation.

You don’t scale agility. You create a business-market fit with adaption capability.

Yes, you can adopt a framework that allows the organization to scale agility-enabling practices. The first attempt at large scale agility that I was aware of was the Scrum of Scrums pattern. The second was Scott Ambler’s Agile@Scale model while at IBM (later renamed Disciplined Agile Delivery due to branding/trademark issues). The one that has garnered the most attention as of late is the crowd-sourced, Dean Leffingwell-owned, Scaled Agile Framework for the Enterprise (SAFe). All three of these are good frameworks, each with their appropriate context and limitations. None of them enable business agility by themselves.

Consider this example:

The SAFe framework talks about quarterly release planning. It talks about release trains of Potentially Shippable Increments(PSIs) of product features in the form of releases.

This is good… sorta.

You see… the way that most organizations have adopted SAFe, the PSI/Releases end up codified into release cycles. The SAFe materials talk about an 8 to 10 week time box. Most folks I’ve talked to have turned the quarterly release planning cycle into a quarterly release cycle. For those organizations, generally this has been a huge improvement. It doesn’t mean that the organization is adapting to the needs of the market quickly enough to remain a viable concern.

The 8 to 10 week release cycle and quarterly release cycle are remnants of the dysfunction of big delivery thinking. I keep seeing releases larger than one or two features, or enough just enough features to be able to deliver an experiment of the business model to the market. This implies the organization hasn’t figured out how to get their releases small enough to build-measure-learn what the market actually will pay for. This also likely means companies are delivering product features that won’t increase revenues, acquisitions, activations, customer retention or referral business. In other words, the market is still evolving faster than the organization and thus at some point in time in the future, the organization’s product will no longer be viable. For some companies this is just for one or a few products. For others, it means the entire business model is no longer relevant.

Speaking of business models, I also don’t see where companies adopting scaled agile frameworks are also learning to evolve the business model with each release cycle. There is this assumption that the business model is correct for the entirety of the product development release cycle, when in reality, there are very few ways beyond business model experimentation using the build-measure-learn cycle to even test that the business model is correct. So businesses get really good at delivering a product that the market may or may not want using a business model that may or may not completely work. Again… the business is ultimately doomed because it cannot adapt to the market fast enough.

In order for a business remain viable it must:

  • Manage its cash flow, maintaining generally a positive cash flow (I know… duh! It’s surprising how many people forget this, though.)
  • Release a functional product that contains only the product features that Kano analysis would call “must-have” and “exciters”, leaving off as many neutral/indifferent features as possible.
  • Release product features at a rate that the market demands as user-expectations shift as a reaction to the Minimum Viable Product (MVP).
  • Understand and attempt to out-deliver new product features at a rate faster than your competitors can react to each product feature release. Sometimes this is a feature-per-day. Sometimes this a unique feature-set per quarter. Either way, it means the company must be able to…
  • Understand the market demand cycle and adapt just before or at the point of inflection in the adaptation cycle.

Again, merely scaling “agile” (noun) won’t make a company agile (adjective). For most organizations, especially those late-adopters and laggards, it means fundamentally transforming to continuous, adaption of the business model for market-fit.

Special thanks to Elinor Slomba of Arts Interstices for the kick-in-the-pants to get this out and for being the other set of eyes.

The Awesome Singh Estimation Technique (TASET)

Introduction

I spoke to the DC Scrum Users Group this topic around a year ago and wanted to unleash this virus on the world. The Awesome Singh Estimation Technique (TASET) is a technique learned from Alex Singh and honed over the course of two years while working with BigVisisble’s clients and recently while working with my own clients at ResultLinq Associates.

The Problem

Managers in every business and from every walk of life always ask the same questions when it comes to Product Development and IT projects: How long is going to take and how much is it going to cost?

When teams are learning relative sizing (estimation) of work items (user stories) it takes some time for the team to get good at estimations. {> Horrible sentence structure <} Traditional methods of estimation consistently fail teams in the early stages of adopting Agile product development practices and are often abandoned in the absence of managerial support. Intellectually, managers understand that it takes a team a while to develop the skills that enables accurate forecasts of feature delivery. {> I should write a blog about the futility of attempting to forecast more than 3 months into the future without having a large enough data pool to use for estimation. <}

There are several approaches to answer this question when employing Agile product development techniques, but at the heart of every approach are two principles:

  • Humans are terrible at estimating effort and complexity of work products [^1]:
  • Teams can only predict once they have a consistent record of estimating effort and complexity [^2]

I’ve run into the problem of estimating time and again when working with organizations adopting the Agile way to product delivery.

What I’ve tried

Many teams adopt the concept of story points and use Mike Cohn’s approach of planning poker. This works really well for a lot of people, but I’ve struggled with teams needing to get “stable” with their estimations as quickly as possible due to management pressure to answer the above question in the absence of mature adaptive management of product delivery and lean thinking.

Techniques I’ve tried are:

  • Using Story Points and Planning Poker
  • T-Shirt Sizes (Extra-Small, Small, Medium, Medium Large, Large, Extra Large, etc.)
  • Using Ideal Man Days
  • Using 3-Factor Hour Estimation (PERT): Optimal, Normal, Pessimistic
  • Story Point estimation + Hourly Estimates on Tasks
  • Using Scrumban’s Cycle Time, Lead Time, Lag Time estimates

Alex to the rescue

Unfortunately, none of these techniques helped me get a team stable at estimating very quickly. Fortunately, my BigVisible colleague, Alex Singh, shared a nice derivative technique that allows me to focus the team on execution while taking care of the problems associated with relative sizing using story points.

Estimating using TASET

The person facilitating the estimation session starts by creating cards as column labels and placing them horizontally on a wall to be used for the estimating exercise. The labels are:

  • Piece of Cake
  • Easy
  • Moderate
  • Somewhat Hard
  • Hard
  • Very Difficult
  • Extreme But Known, and
  • Extreme and Unknown 

At the same time, the person responsible for User Story creation and elaboration (typically a Business Analyst or the Product Owner) should have the stories in order of priority from highest business value to lowest business value.

TIP: Place a small number on each card to indicate the prioritization relative to the other cards (e.g. BV1 BV2, .. , BVn).

When the session begins, starting with the first story, the person responsible for the first story explains the first story to the team members who will be performing the work. Using the round-robin selection approach, the first team member places the user story in the column matching the size most closely matching their estimate for the story and then explains the rationale for their estimate. Then the next team member takes the same story and either agrees with the estimate or moves it to the column most closely matching their estimate and explains why they did or did not move it. In a similar manner, each team member repeats this process until all team members have had a chance to re-estimate and explain their rationale. You now have a baseline story to use relative estimation sizing.

The next story is explained by the Product Owner.

Estimate the size of a user story relative to similar stories in previous products and releases with each person by first explaining which previous product and release they are using for comparison and then placing that story under the appropriate column heading.

This should be specfiic for each of the delivery groups in the room. The Business Analyst or the Product Owner then explains the stories in order of priority from highest value to lowest value to the business. The track/team lead then facilitates moving the first story to the appropriate column heading (estimate) based on relative size to some previous story from either the previous iteration, is there was one, or previous release, if there was one.

Applying the Technique

  1. Build the Estimation Wall
  2. Find the Smallest Story
  3. Find a Representative Story for Each Relative Size
  4. Walk Through Each Story, discussing as a team the acceptance criteria, the approach to solving for the Acceptance Criteria, and Risks/Dependencies
  5. Poll the team which representative story already on the wall the Story belongs with
  6. After placing the story in the estimation column, ask the team for a confidence vote (Fist of Five) that they got that right.
  7. Adjust the estimation based on the Team’s response
  8. Repeat until all Stories are estimated
  9. Ask for a final confidence vote by the team
  10. Adjust the estimation based on the Team’s response

Why it works

Using relative sizing is to use a scale that activates two levels of the brain, the pre-frontal cortex where we make relational decisions and the basal ganglia where previous experience exists. Often sizes and number confuse a team as it is difficult for a team to pin-down what a size or number really means. This method uses yesterday’s weather in a meaningful and adds a Plan-Do-Check-Act feedback loop so that teams can get to good, reliable estimates within the second or third iteration.

Some other ways to do it

I often have to work with disbursed or distributed teams. When I do, I’ve used a spreadsheet where we collaborate on finding the relative sizes using columns in the spreadsheet. It takes time and patience. I’ve had better luck using Google Sheets where everyone can work on a Sheet at the same time. I’ve heard rumors that Microsoft is working on something similar, and there are plug-ins that are being added by the moment to Rally, VersionOne or Jira.

Why I predict the 2013 Mac Pro will be DOA

Mac Pro, Mac keyboard, Mac cup, Mac iPod Class...
Mac Pro, Mac keyboard, Mac cup, Mac iPod Classic, Mac iPod Nano, Mac iPod Shuffle, (Photo credit: Wikipedia)

Apple gave us another look at the 2013 Mac Pro this week at the update release announcement for the iPad line. Today another person noted what I’ve been mulling over for some time: the interesting design is missing two major features that will keep it out of the hands of a lot of video, audio and graphics professionals. You know… the target market for that machine?

The three big features are:

  1. Upgradability: If I can’t put the video or audio cards that I already have in it or can’t install newer versions of the same cards the the system has no use to me. Examples are:
  2. Rackmountable: If I can’t put the workstation in a server half-rack, which most studios and live production crews use, then the workstation will need a custom installation in a space where space is a premium and there are already standards for such things.
  3. External storage: SAS Drive array cards to connect to MiniSAS and SAS Desktop Video Drive Arrays for HD and 4K Video editing. Examples are the PROAVIO, Sonnet and Promise desktop and rackmount solutions.

My point. Apple’s Mac Pro looks pretty, but professionals don’t buy machines to look pretty. We all bought Macs because they were the best functional machine I never had to think about. It just worked and anything designed for it just worked. It may be that Apple is banking on the expanded use of the Lightning Bolt port, but most professionals, self included, don’t need more cables and junk lying around. Also, there are limits to the Lightning Bolt port that can only be overcome with Bus Speeds. Live rendering all those pretty graphics you see in sports shows is a perfect example.

This may be the end of my journey with Apple hardware for a while until Apple realizes how badly they are alienating the Pro Media community.

Enhanced by Zemanta

Lessons Learned From Five Years of Agile Implementation Failures – AgileDC 2013 Presentation

<

p><img class=”size-thumbnail wp-image-1142″ alt=”Picture of me taking a picture of Sprint Zero of the Wikispeed workshop courtesy Elinor Slomba of Arts Interstices.” src=”http://test.devinhedge.com/wp-content/uploads/2013/10/2013-10-08-09.58.52-150×150 Picture of me taking a picture of Sprint Zero of the Wikispeed workshop courtesy Elinor Slomba of Arts Interstices.

Well, another year of AgileDC is in the can. This year was another winner. Even though the flavor at AgileDC is always biased towards the Federal Government, it was strange that the topics seemed to be diverse and more engaging than those at the Agile Alliance‘s Agile 2013. I confess that the topics at Agile 2013 were so non-interesting that I didn’t even go this year. This is not to say I didn’t miss something. I did. First of all I missed hanging out with old friends. There was also a few sessions that I would have liked to attended. For the money, though, AgileDC was a much better deal. Additionally, we raised some $14,000 for a cause I’m deeply passionate about, the Juvenile Diabetes Research Fund.

Wikispeed Keynote

This year, the keynote was just as engaging as last year. Joe Justice of Wikispeed filled in the gaps between Agile 2012 and today. Always willing to put others before self, Joe brought J.J. Sutherland* of Scrum Inc. to talk about how he used Scrum to manage NPR’s coverage of the Arab Spring in Egypt. According to J.J. the situation was so fluid that rather and unifying the reporters, it had a tendency to put reporters at odds with each other, causing missed deadlines and misinformation. J.J. spoke of being reminded of a technique his father forced him to learn by attending a Certified Scrum Master course: Scrum. J.J. talked about pulling out sticky notes and pulling the reporting team together twice daily. It worked and NPR’s coverage remained some of the most relevant and comprehensive. ( Transparency: I contribute funds to NPR so it is good to hear that my money is being managed well. )

Finished product after three one-hour Sprints.
Finished product after three one-hour Sprints.

Another thing from Wikispeed is the phrase “eXtreme Manufacturing”. I like where Joe and the gang are going with this. It has all the makings of changing the world in the same way that Demming did. Yes… I just went there. Expanding beyond building a car that is posed to reinvent how cars are designed and built, Wikispeed is starting to focus on another one of my passions, solving the problem of involuntary homelessness using eXtreme Manufacturing to build MicroHouses. One application I could see of this refugee camps, displaced peoples from natural disasters, and a way for cities to set up transition programs for those placed in involuntary homelessness situations. (NOTE: I probably should talk sometime about what we are learning about why these programs fail and how Habitat for Humanity has overcome these obstacles to success.) Throughout the day, Joe and the folks at Scrum Inc. used the Wikispeed eXtreme Manufacturing workshop to teach pairing, eXtreme Manufacturing, Scrum and Kanban.

Personal Experience

Ballroom B where my session was at AgileDC.
Ballroom B where my session was at AgileDC.

My session went perfectly. I’ve never had that happen before so I thought I would make note of it. I was presenting on the topic of Agile Failures, something no Agile Coaching account manager or business development person is likely to ever talk about. I expected the session, Lessons Learned From Five Years of Agile Implementation Failures, or… What NOT to Do When Becoming Agile, to have about ten people show up. Ten minutes before the session, it was full. Five minutes into the session, it was standing room only.

Needless to say, I was nervous. This was also my first public appearance under the ResultLinq Associates monicker.  Would the audience get the message? That will still remains to be seen, but the feedback was overwhelmingly that I hit home. The feedback told me exactly what I expected. Everyone liked the format. The opening blew everyone’s mind. A lot of people were stuck in deterministic thinking headspace so they wanted a one-size-fits-all checklist when all that could be had are certain principles. Oh… and I thought the projector/screen combination was terrible, too. It made the smaller text unreadable and I was standing right in front of it.

I have to confess that I lied on one slide. The picture of an Agile adoption coaching plan was actually a release planning session. I couldn’t find my coaching plan pictures and had to substitute with something worked and looked the same as a coaching plan. I openly apologize and ask for forgiveness. I found the pictures today after some creative searching through my Dropbox history. I’ve updated the slide so that you can actually see what my coaching plan wall looks like.

Several folks have asked for the slides. I did one better this time around. Below is a corrected recording of the session and a link to the PDF of the corrected slides.

[vimeo 76835486]

PDF File

Feel free to ask questions and challenge some of my hypothesis and theories.

Enhanced by Zemanta

Review of Writing Kit for iPad

Writing Kit for iPadI’ve started using Writing Kit for writing on the iPad a lot more often these days. It supports Markdown, Dropbox sync, has an integrated Browser with DuckDuckGo as one of the integrated search engines. It is distraction free. All-in-all, it is as close as I’ve came to having the perfect on-the-go, in-the-moment everywhere writing tool. It even includes limited integration with Instapaper and Readability. There are three key features that prevent this from being THE perfect writing tool. They are:

  • Two-way integration with Evernote
  • Integrated Zotero client
  • Ability to write sections of documents and stitch them together, re-organize them, and compile them into a final document.

The work-arounds that I have used so far have been as follows:

For Evernote references — I either hot-swap to Evernote for iPad and use the “share link” feature to grab a reference to a specific note, or using the browser integrated into Writing Kit to navigate to Evernote’s web client to grab the link to an Evernote entry. Then I paste the link into my document using Writing Kit’s Markup or Insert Link tool. It is a pain in the neck and still doesn’t give me what I want. What I want is to be able to open an Evernote window in a side-tray (Blogsy style), high-light a section of text and insert the text into my Writing Kit document with the link to where that text came from automatically generated for me.

For Zotero — This would be the holy-grail of iPad functionality. What I would like is to open the integrated browser for researching a topic, highlight text in web pages or pdfs, send the bibliographic information along with the captured text to Zotero, be prompted for a description and note about the reference, AND capture the web reference in a specified Evernote note. Then inside my Writing Kit doc, be able to open a Zotero Client in a side-tray (Blogsy style), search for a find a reference, insert the quoted text, insert the note I made about the text, and maintain a markdown link to the Zotero record so that it can be compiled into an inline reference and Bibliography section when I’m ready to compile the document for “print” (usually a blog post or PDF white-paper).

For writing sections and document compilation — I’ll just say, I want to mimic a watered down version of the functionality of Scrivener for Mac and leave it at that.

Overall, though, I am really happy with Writing Kit. I’ve tried Pages, Plain Text, Plainnote, iA Writer, TextTastic, WriteRoom*, and others. I’m looking at Editorial next, but you can only throw down so much bank before you realize there should be a way to get a “free 30-day trial” before being required to buy an app in Apple App Store. That, of course, is a topic for another time.

*NOTE: I really love WriteRoom and OmmWriter for Mac. My favorite of the two is OmmWriter because of the Zen-Like interface, inspirational backgrounds and meditative music. I once got up from writing using OmmWriter and was in deep pain because I had been sitting for over two hours “in-the-zone” and hadn’t realized my back and legs were numb.

Further Reading on the Topic:
*10 Awesome iPad Writing Apps
*Make Your iPad A True Writing Tool With These Notebook Apps
*The art and science of writing on an iPad
*8 iPad Apps for Brilliant Writing
*Review: “Writing On The iPad: Text Automation with Editorial” is a textbook for iOS automation
*The Novelist’s iPad: 10 Apps for Writers
*The 10 best writing apps on the iPad
*Why I’m writing on the iPad
Editorial, iPad Writing Re-Imagined

Enhanced by Zemanta

Story Mapping – So Easy a 7th Grader Can Do It

Grooming the Story Map
Building out and Grooming a Story Map

As she was thinking about how the user interaction would go, I explained that we needed to capture this somewhere so we could make it her 7th grade project. When we returned home, I was messing around with upgrading Parallels on my Mac when she walked up with Blue Tape, Post-Its, and a Sharpie. She simply asked, “How do I do this?”

Off to the races we went.

In explaining the story wall, I never used terms that were techie, geeky or anything but the language she was using. The result was she came up with a term called “a Story Map”. I have to believe she has heard me use that before, but I am most definite she has never seen one. I just asked two questions over and over:

  1. If you were playing the game, what would you do?
  2. What would happen as a result?

Those are two key ingredients for a Story Map.

All too often I spend hours and days un-teaching decades of “software engineering analysis and design” just to get to the basic two questions for starting a software engineering endeavor. I wonder why a 7th Grader can figure this stuff out in 15 minutes and adult professionals with four years of formal education, and typically two to seven years or more of professional experience can’t “get it”?

Are we such creatures of habit that our former experiences render us incapable of thinking about “HOW TO THINK” about a problem? I’m beginning to wonder. I feel another human behavior experiment coming on.

Enhanced by Zemanta

Pareto’s Principle and that Sucking Sound in your Organization

No matter how many mistakes you make or how sl...
No matter how many mistakes you make or how slow you progress, you’re still way ahead of everyone who isn’t trying. -Tony Robbins (Photo credit: deeplifequotes)

Think about this statement: 80% of the people that need your help don’t know they need your help.

Here is another statement: 80% of the people that need to read this blog post will never search for it.

Another: 80% of the people that actually find this post and read it won’t actually believe it. :-/

And another cookie: 80% of the people that don’t know they your help and will never search for this blog post, aren’t even online, don’t search online, don’t subscribe to Internet feeds, read Internet news or otherwise engage in anything online.

Finally, this 80% of 80% (64%) uses 80% of all resources of your organization and only produce 20% of the results.

Not surprisingly, Tony Robbins points out that 80% of businesses go out of business in the first three to five years. Of the the remaining 20%, another 80% will go out of business in the first five to seven years in business. The primary reason is product to market fit… planning and development. That 64% sucking up all those resources at work has a name. It’s name is Mediocrity and it is killing your company.

I’m going to follow this up with a post about where this phenomenon comes from (mostly not the 64%), how to curb and kill mediocrity, and how you can’t kill mediocrity but only contain and minimize its effect.

I’d love to know what aspects are important to the 20% of 20% (The 0.04%) that will read this post. What are your thoughts?

SOURCES:

 

Enhanced by Zemanta

NFL and ESPN leaving money on the table?

Continue reading NFL and ESPN leaving money on the table?

Overcoming the role of cognitive bias in critical decision making

Folks attending Agile 2013 got a treat this yesterday. Former colleague Manoj Vadakkan and Agilist Bob Payne are going to address how cognitive bias plays a role in Agile Adoption

English: GCOM Cognitive Schemata
English: GCOM Cognitive Schemata (Photo credit: Wikipedia)

. In researching and garnering feedback, Manoj and I were swapping anecdotal stories of cognitive bias. I’m going to share two here. If you happen to be at Agile 2013, try to catch this session as I know it will be great.

The two examples I want to share where I have seen cognitive bias preventing Agile Adoption are what I’ll call Hourly Estimation Bias and Risk Adverse Homosocial Reproduction. It sounds fancy, but your see it is just a situation we take for granted not knowing its adverse effects in catalyzing necessary changes.

HOURLY ESTIMATION BIAS

This bias can be defined as the need for managers who have not fulling embraced “The Agile Way” of Empirical Evidence in planning and tracking. In Agile practices we tend to shift away from hourly estimation of way, relying instead on relative estimation based on NUTS and Throughput Account measures such as Velocity, Cycle-Time and Lead-Time. While it is often dangerous to apply Lean Manufacturing metrics to Product Development due to the vast variation in effort from Product Feature to Product Feature, when sufficiently broken-down into work units that can be completed in 2-3 days, the law of averages in large datasets takes over giving you a nice Guassian Curve.

The anecdotal story I’ll share here is that managers, being unfamiliar with empirical evidence and having relying on vanity metrics so long, they suffer bias towards the vanity metrics even when we have proven that the Paredo Principle applies to these estimations and metrics… they are only correct ~20% of the time. Or stated another way, vanity metrics of Scope, Schedule and Cost in a complex human system are invariably WRONG roughly 80% of the time.

So why would a manager bet their bonus and possibly their job on something that it WRONG 80% of the time? Familiarity. The brain naturally filters and reduces the world around us into simples terms in order to perform sensemaking. This works when you need to know if a Lion is a threat while walking across the Serenghetti. It works poorly in estimation of complex systems and complex human system. Yet, time and again I have managers that ask: “What is your percent complete?” and “How many hows do you have left?” Why? Cognitive Bias towards the familiar. It turns out we favor five-to-one something we are familiar with over something we are unfamiliar with. Paredo’s Principle strikes again (One-Fifth = 20%).

So how can Managers overcome their natural bias towards the familiar? Managers should be required to read and peer-review two books that span a large body of knowledge about neuroscience, critical analysis and decision making. These two books are, “Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long” by David Rock, and “The Power of Habit: Why We Do What We Do in Life and Business” by Charles Duhigg. In both books the skills of mindfulness (understanding when your brain is reacting again reason in its need for the familiar), and how to form new habits so that the unfamiliar becomes familiar.

RISK ADVERSE HOMOSOCIAL REPRODUCTION

The second cognitive bias I’ll discuss is a phrase I’m hijacking and twisting, called Risk Adverse Homosocial Reproduction. In a study about diversity in the workplace and the hiring habits of managers, it has been found that managers subconsciously hire people that act and look like themselves (homosocial mirrors), and that they favor candidates that are homosocial mirrors over candidates that are more qualified.

I have seen this behavior present itself in the following more times than I am even aware of. For example, say a manager needs to fill a position with someone that has Agile skills. Together, we look to hire someone internally first because it is seemingly less risky as a person is likely to already understand the political landscape and challenges facing the position. But, what often happens in a command and control environment shifting towards a collaborative environment? We look around the company for a likely candidate and don’t find the right mix of technical skills, domain knowledge and soft skills. We have to hire someone from outside. However, when faced with a marginally competent internal candidate and strong external candidate, managers favor an internal candidate over the outside candidate. Thus, the command and control culture is further cemented into place and change becomes that much more difficult if not impossible.

Soft skills (people skills) in an Agile environment are typically the more important than technical skills and domain knowledge. That is not to say that a person should not have a base competency in the requisite technical skills or domain knowledge; however, we have found that a person with the soft skills of mentoring, servant leadership and lifelong learning can overcome not having strong technical skills or domain knowledge.

So why would a manager purposely choose the lesser qualified candidate?

It’s called Risk Adverse Homosocial Reproduction: a cognitive bias that favors hiring people that are “just like me” in order to make you feel good. This feeling of comfort comes from patterns of familiarity in the Superior Parietal Lobe combined with the fear of the unfamiliar in the Amygdala overriding our ability to reason using logic in the Pre-Frontal Cortex.

Unfortunately, knowing this is mostly useless. Typically, the people that need to know how to steer around this Cognitive Bias the most, are the least likely to know that they need to steer around this Cognitive Bias.

Русский: Cognitive Hazard by Arenamontanus
Русский: Cognitive Hazard by Arenamontanus (Photo credit: Wikipedia)

It is also the single, most-challenging, and most-obvious “problem to everyone but the person suffering this bias” that I face when coaching.

We all naturally suffer from it in some small way because it is a natural defense mechanism built into the brain against wild animal attacks. It is also the root of racism, prejudice, and class (Caste?) politics.

The bias is that strong. There is one way to overcome this bias, but it is quite ugly.

Generally, the only way out of hiring bias is through judicious use of external recruiting, allowing internal wannabes to apply for the position through an external vetting agency. Corporate recruiters hate this strategy because they feel they don’t have control over the vetting process, so a certain “make HR feel part of the process” tactic has to be employed. Properly engaged, HR becomes your strongest ally in the process.

I’ve successfully used this technique for overcoming my own bias. The result was being able to work some of the most brilliant people in the business.

What examples of cognitive bias in decision making have you seen?

Enhanced by Zemanta