Have you ever been in a position where a project you were managing was late or over budget? Have you ever supported an application that had a customer impacting service outage? How did your boss respond to these issues? Did she say something like “I want a review of our quality strategy” or “I’d like to see our application rollout strategy”? Maybe they asked for something even more nebulous and less connected to the issue at hand like “Show me our site and product integration strategy”. Huh? What does that mean?

It’s easy for managers to react to incidents and problems by requesting that certain actions be taken by a person or team. The problem with such an approach is that it feels like a punitive action to the people from whom the action is being requested. Maybe the group or person needs to receive performance feedback, but by asking them to take an action you are not really giving them feedback. If your goal is to both provide feedback and ensure the underlying issue is corrected then provide candid performance feedback and explain the desired goal of the corrective action.

Great leaders understand intuitively that they should speak in terms of desired end states and then ask for plans to achieve those end goals or states. Another approach is to use the Socratic Method and ask your team what an appropriate end goal should be, whether they’ve achieved it and how they should correct their approach to achieve that goal. The first is probably the best approach when the team is overwhelmed or you are in the middle of a crisis. The latter approach is best for higher performing teams who have simply hit a “bump in the road”.

Now that we’ve completed one of our major writing projects and are on winter break from another writing-intensive project, I’ve spent the past few weeks catching up on some reading. I keep a both a pile of unread books/articles as well as a list of books that I want read. When the pile gets low I go to the list to replinish the pile. We often share reading recommendations amongst ourselves.

All of this reading has made us interested in updating our old recommended reading list with a new reading list. This time we’ve decided to use Amazon’s astore to do this since it makes adding, updating, and categorizing our list quick and easy. You can find the permalink on the righthand side of our blog. We’ll try to keep it updated as much as possible so you know what we’ve read and thought worthy enough to pass along. If you have suggestions of great books let us know in the comments.

NOTE: The purpose of this blog isn’t financial gain but given the new FTC requirements for full disclosure we feel obligated to state that the recommended reading list is an Amazon associate’s page, for which we get some incredibly small amount back in the event you do use our links. We are not really interested whether you use our links or not, we just want an easy way to recommend books to you. For those fellow bloggers that haven’t seen the FTC requirement, here is the relevant couple of sentences:

The revised Guides specify that while decisions will be reached on a case-by-case basis, the post of a blogger who receives cash or in-kind payment to review a product is considered an endorsement. Thus, bloggers who make an endorsement must disclose the material connections they share with the seller of the product or service.

One final quote to leave you with…

Outside of a dog, a book is man’s best friend.  Inside of a dog it’s too dark to read.  ~Groucho Marx

We probably all agree that the authorities had enough information to keep Umar Farouk Abdulmutallab off of the Northwest flight from Amsterdam to Detroit on Christmas day.  His father contacted the US Embassy nearly six weeks before the incident and indicated both his son’s presence in Yemen and his son’s extremist views, there was intelligence indicating that extremists in Yemen were discussing a plot with someone known as “the Nigerian” and additional incriminating information will no doubt become available over the coming weeks.  Given the comments on CNN’s blog, most of us also feel that the changes made to security procedures by the TSA, in reaction to this incident, will do more to hassle travelers and lessen their productivity than it will to make them more secure.  As unfortunate as this incident was, it does provide startups with examples of how bad culture and flawed process can lead to overall failure to reach our desired objectives.  In this article we will use the December 25^th events to illustrate the importance of culture and process on effective organizational learning.  We will also look at how the results of a learning and corrective action process can be used to determine if your process and culture are appropriate to your need.

There is a wealth of knowledge and data that tells us that we learn much more efficiently from our mistakes than from our successes.  As such, we need to make effective use of each and every mistake and failure to not only learn personally but force our organizations to learn.  Unfortunately, irrespective of the party in power, the government is unlikely to maximize its learning in the Abdulmutallab case.  While the administration no doubt actually wants to increase the security of travelers and the US defense against terrorism, it is also motivated to reduce administration blame and culpability in order to increase the likelihood of reelection. These two things are not mutually supportive and as a result the outcome will be suboptimal compared to a pure goal of simply finding problems and resolving them quickly and permanently.  In support of this statement, consider the President’s actions ordering a review of the system within five calendar days.  Given the depth and complexity of the organizations and systems involved, could such a review truly be comprehensive?  The organizations under review will no doubt believe that the administration is on the hunt for a fall person and as a result, information will likely be hidden and learning reduced.  The culture of “covering your ass” and “finding a fall guy” are counterproductive to effective organizational learning.

The preceding isn’t meant as an indictment of our government, but rather an illustration of a barrier to learning for all organizations. In order to maximize organizational learning from failures you must have the right goal of learning from and correcting all of the associated failures, not finding a “fall guy”.  This isn’t to say that people shouldn’t be fired for lack of judgment, dereliction of duty, or repeated failures to perform, but rather that the initial goal of the investigation isn’t to identify these people.  To be successful, and to repeatedly maximize learning, an organization must both have a culture of openly learning from mistakes and a process to maximize that learning.  Our book, “The Art of Scalability”, describes and diagrams our favorite Post Mortem (aka “Root Cause and Corrective Action” or “After Action Review”) process and a recent blog post highlights a lightweight version of this process for smaller issues or smaller companies.  One method of conducting a post mortem is to use the “5 Whys” initially developed by Sakichi Toyoda of the Toyota Motor Corporation.  The process, as we often modify it for our clients, is to ask “Why” at least 5 times to ensure that you get close to the true root cause.

Having discussed the culture of the organization and the process by which failures are reviewed, let’s turn to the expected results.  The response by the TSA to this incident was to post new guidelines for security procedures within 2 days of the incident.  Included is the statement that passengers may notice “increased gate screening including pat-downs and bag searches” and may be asked to “stow[ing] personal items, turning off electronic equipment and remaining seated during certain portions of the flight”.  Remember that this is in response to an individual who was reported by his own family as a suspect; the 5 whys would indicate that the failure is as much in a failure to react to information as it is in detection of the substance.  Testing these outcomes we can determine if our process led to the appropriate results.  Where are we correcting the failure of acting upon the appropriate information in a timely and effective manner?  Are our new procedures increasing security or simply an action to prove that we are doing SOMETHING?  Will the pat downs and stowage rules keep a terrorist from hiding explosives in their underwear?  Many believe the answers to these questions are “No”.

Admittedly a technology crisis is not anywhere near as critical as a terrorist attack but we can still draw some parallels.  In a technology organization this incident would be akin to determining that an outage was caused by a patch that was applied even though it was reported as buggy and not ready for deployment.  The reaction by the TSA would be like the organization’s management reacting by requiring even thoroughly tested and quality assurance approved patches go through extra testing.  Instead of punishing and delaying all patches, why not just make sure untested patches don’t get deployed?  You need the right process at the right time with the right culture and organizational mindset as we describe in detail in “The Art of Scalability”.

None of this is intended to take away from the immense job that our governmental agencies have protecting us from terrorism nor is our goal to make light of terrorist attacks by comparing them to technology crises.  However, as we’ve seen in many instances, such as with the popular books “Freakonomics” and “Superfreakonomics” where the authors take an economic approach to non-economic problems, it is appropriate to attempt to extend the learning from one discipline to another.  From this unfortunate attempt at terrorism we believe that technology startups can better understand how to learn from mistakes and how to modify process when attempting to prevent future problems.

As a frequent technology writer I often find myself referring to the method or process that teams use to produce software. The two terms that are usually given for this are software development life cycle (SDLC) and product development life cycle (PDLC). The question that I have is are these really interchangeable? I don’t think so and here’s why.

Under SDLC, Wikipedia doesn’t let us down and explains it as a structure imposed on the development of software products. In the article are references to multiple different models including the classic waterfall as well as agile, RAD, and Scrum and others.

In my mind the PDLC is the overarching process of product development that includes the business units. The SDLC is the specific steps within the PDLC that are completed by the technical organization (product managers included). An image on HBSC’s site that doesn’t seem to have any accompanying explanation depicts this very well graphically.

Another way to explain the way I think of them is to me all professional software projects are products but not all product development includes software development.  See the Venn diagram below. The upfront (bus analysis, competitive analysis, etc) and back end work (infrastructure, support, depreciation, etc) are part of the PDLC and are essential to get the software project created in the SDLC out the door successfully.  There are non-software related products that still require a PDLC to develop.

Do you use them interchangeably?  What do you think the differences are?

This year there are no New Year’s resolutions, technical prognostications, or wish lists, just a huge “Thank You” to all of our friends for making 2009 a terrific year and wishing everyone a happy and scalable 2010.