Government concept of emergency

This really shows the difference between business and government. In this story in the San Diego Union-Tribune, Schwarzenegger is getting ready to declare an emergency. But we don't want to rush this emergency or anything:

Schwarzenegger will not declare an emergency until early next month, when the Legislature is scheduled to return from its annual fall recess that began in September.

Software Engineering Institute and Software Product Lines

SEI has a certificate program in SPL, and I decided I'd take the leap all the way across the country to check it out. If SPL works, it addresses a problem we've wanted to solve for decades: reuse of working code. The first course is basically a high speed tour through the book, Software Product Lines, by Paul Clements and Linda Norththrup. The book is excellent, covering all 29 practice areas with details regarding what you might want to think about for each of them. Moreover they include real world examples, which the two-day class discussed.

A Product Line is not about ad-hoc re-use, which is what most of us do. It is about strategically putting the pieces in places so that a set of core assets are developed that will be re-used by virtue of the decisions made along the way. The core assets are more than re-usable components, and include things such as documents. But the key is that they are defined such that they are usable by all members of the product line. The trick is to choose the scope to make that viable, and do a good job predicting the future of technology.

In 2001, I was leading an effort to try to create an architecture that would be usable across multiple products in a product line; it would have been helpful to have these tools. I have also worked with clients who desperately need to architect their products so that they focus their development efforts on adding value. I am cautiously hopeful that these tools will add significant value.

Innovation Management modeled like the Internet

The Nov 15 issue of CIO magazine interviews Gary Hamel about innovation management. He says that our management skills are mostly tuned for efficiency, and that isn't what we need to focus on any more. Efficiency is about conformity, whereas innovation is about diversity. He also says that what management needs to do now is model the Internet: amplify and aggregate human capabilities. Moreover the best skill we can encourage for innovation is that of being a contrarian - challenge industry dogma. He's got a book he's promoting, The Future of Management, which undoubtedly goes deeper in these area.

Sounds promising, and I like the thinking. My only caveat so far is that if you don't have your efficiencies under control, eventually you won't have any resources or assets to spend on innovation. So don't lose sight of the blocking and tackling.

Requirements and Capabilities

I attended a presentation yesterday which was intended to help people understand how to do Design for Manufacturing when offshore manufacturing is the objective. Unfortunately the presentation fell way short of its target, and the crowd even got a little annoyed. The presenter was talking about models that have worked before:

• Document well
• Follow the process exactly
• Manufacturing team has ultimate veto on readiness
• Company level approval policies

which break down perhaps completely in an offshoring environment. Often, a US based firm contracts with multiple manufacturers, in different countries, with different language skills. The capital equipment these vendors have can be very expensive, and what they have will dictate what they can do. The old models won't work.

After hearing the crowd banter, it became clear to me that this is an inexact science. Nobody at this venue deferred to an authority on the subject.

I'm going to spend some time on this, but it seems to me that what we need is a best practice of identifying inviolate requirements (like no lead in the paint) and assumptive requirements (like we assume this component will consume less than 40W), and then somehow mapping these onto the inherent and acquirable capabilities of the offshore manufacturing group, before agreement is reached. Inherent capabilities are those that are constrained by resources including capital equipment and labor, and acquirable capabilities are things like skills that can be learned. The idea is to be able to understand the fit and risk of the product being properly delivered by the manufacturing team.

This is really a half baked concept at this point, but I would be very interested in what practices you may have used to deal with this. If you have an interesting methodology that you can articulate, or better yet one you have used with good results, there may be a speaking opportunity for you here in San Diego.

Information hiding

The August 2007 Communications of the ACM has an article called Offshore Outsourcing: The Risk of Keeping Mum. In it they discuss factors that contribute to information hiding. They reference a model developed by G. Hofstede, which breaks down cultural differences into 5 factors, and then combine it with work done by Keil and Robey [ACM 44 Apr 2001] which identified fear of being punished as the principal cause of the mum effect. They conclude that the mum effect has higher probability in Asia than in the west due to these factors, but also wonder why there have not been examples of spectacular failures attributed to information hiding in offshored projects.

It also states that communication gaps occur when employees feel their views are not valued or taken seriously. That's really the point of my post today. Trust develops when we genuinely listen to views of others, and demonstrate that we understand. Understanding doesn't mean agreement. What it means is that you can use your own words to express their view, and if you disagree, you are able to articulate why. Ultimately both parties express and listen until they agree or agree to disagree, but both have the same information. Trust is necessary to be able to express potential failures and risks in a completely open and truthful manner. It doesn't have to be an offshore team or a team with a different culture, but with those factors, you will have to work that much harder to develop trust.

Without trust, your team may not tell you what is going wrong until it is too late.

Exit Strategies

Many people have asked "What's your exit strategy?" when discussing my startup. Initially, I found this offensive, because in my mind if you build a viable business, you will have exit possibilities, should you desire one. Moreover once you are successful, you'll have a better idea of exactly how it should be done. Isn't building a business that has long term value what starting a business should be about? Eventually I gave up and decided this is one of the things I can't change, I was too idealistic, and found ways to articulate how and why the business would be acquired.

However, there really is a difference, and I don't think it's a good one. We're being blinded by the success of "easy money" stories like YouTube, where with the right secret sauce, there might be a lot of money to be made. Business is hard, and to focus on getting things right for the long term takes a totally different mindset. Seriously, do you think YouTube will be here in 20 years? 10 years? 2? It is not a long term value add to the world or society. It doesn't make my life better. It does contribute to the flow of information at near zero cost, but that isn't anything unique to YouTube. Yet YouTube is a VC's model of success.

This week, an insert in the San Diego Business Journal included an article by Robert K Weiler, CEO of Phase Forward. Weiler did a $41M IPO in 2004 and a $90M secondary public offering in May this year. Weiler writes:

Many times I've seen management teams focus on the IPO event, so they're making short term decisions. They're taking contracts and business to bring in revenue without building a service organization to support the business.

This supports my concern. We should be building businesses that provide long term sustainable value to customers. If we don't, we risk losing a lot, if the rest of the world finds us irrelevant.

Open source practices even if you aren't using open source

At High Regard Software, we're trying to make it easier to "onboard" new developers for our startup, RideGrid. We are using some open source, notably pieces of Apache Commons. Even if you are not using any open source, there is a lot that can be learned from Open Source to make it easier to do development. The argument for this is straightforward: if the tool set works for collaborators around the world, who by the way generally are working for free, it has to be really low friction. If it's too hard to volunteer their time, they'll find something else to do. These tools are awesome and only getting better. We have been using SVN for a year, and we are just starting with Maven. I'm going to discuss these two tools and their benefits for you, based on our personal experience.

SVN, or subversion, is a version control system. It runs on Mac, Windows and Linux. There are different ways to configure the server, but the way we chose to do it is using SSH. All of our developers generate an RSA public/private key pair, and email us the public key. Once they can login successfully to the mac server using SSH, they can download the source code using SVN's ability to tunnel through SSH. Therefore we end up with a very easy and secure distributed version control system. We don't have to run a VPN into our servers, nor do we have to maintain a web server with access to the code.

Maven is a build infrastructure. It is a higher level tool than Ant, it does not replace Ant. To really appreciate it, you have to try it. Without Maven, we were getting third party libraries by downloading them and checking them into our repository. Because we are using NetBeans, we then were declaring libraries differently in every developer's workspace. Each developer had to declare the installation path to these JAR files, making the onboarding process tedious and error prone. We tried some hacks around this with limited success. With Maven, we simply declare these dependencies including version numbers, and the Maven gets them for the developer and installs in their workspace. But the larger benefit is that once we are converted over to Maven, we are IDE independent in a couple of dimensions. Prior to Maven, the only way to build and deploy an instance of our product was to fire up and properly configure NetBeans. Once our conversion is done, the entire product can be built, deployed and run from the command line; the only reason to fire up Netbeans is if you need to make a change or debug the product. Moreover, if we bring someone on who prefers Eclipse, they can load the projects into Eclipse. This is because both Eclipse and Netbeans have Maven plug-ins, meaning they can read and write the Maven configuration files. I haven't used Eclipse, but in Netbeans you simply create a project as a new Maven project; some of the operations (like the Library Manager) are no longer relevant when you do this, so there is a learning curve.

These two tools are helping reduce the startup time of new engineers. If your team is doing Java development, I'm sure they can help your team too.

Software Development and the Environment

What can software leaders do to help improve the environment? Reduce the footprint we leave in the process of doing our work. Each of you may have unique ways you can do this, but there are some that could be nearly universal and I'll cover those here. The areas I've actually been involved with are listed below, followed by more details about each in terms of what to expect and the challenges you are likely to have. Each of these specifically reduces consumption of energy, and in the process, lowers production of GHGs (Green House Gases) and a collection of nasty, poisonous compounds including VOCs, CO, SO2, and NOX.

1. Work remotely.
2. Encourage alternative transit.
3. Turn off the servers.
4. Run virtual machines instead of deploying more servers.

Work Remotely: reduce trips to and from the office. To do this, your organization will probably require the development of new skills for you and your department. Don't bet on videoconferencing - it's not the same. Make sure your entire team has quality headsets so you can conference call and everyone can hear and be heard. Don't try to mix remote meetings and in person meetings - you want equality in the handicap - otherwise the local meeting takes precedence and you'll lose the remote attendees because they can't hear as well and don't have the benefit of the non verbal in person communication. Get a good conference calling service that has mute capability both for the organizer and for individual lines. Your team will probably need to prepare better for meetings - which is a side benefit. They'll need to prepare and distribute relevant material in advance. You will benefit by acquiring a remote collaboration tool; I haven't found one that is perfect yet, suggestions solicited. If you are going to try to draw, get a tablet.

Encourage Alternative transit: increase efficiency of per passenger commute. Don't get me wrong, I'm not saying this works for everyone, but when it makes sense, promote it -- people won't generally think of it on their own. Most places I've worked implicitly discourage anything but driving - they would rather know the person can stay the extra 15 minutes when necessary rather than catch the shuttle/train/bus. This is really counterproductive, because what it is doing is causing more people to use a system that has horrible scaling properties, so you end up wasting your employee's private time - thinking that this doesn't come out of your time is naive. The federal government has a program that enables you to get a tax benefit for sponsoring your employee's use of public transit or vanpools. It's a tax free bonus to the employees, and a tax benefit to you. Think about alternative transit when you lease that new building (I interviewed once with a company who was located one block from a METRO station near LAX, and the leaders didn't even know that). Make it easy for employees to get to and from the transit location.

Turn off the servers: lower electricity use. Those servers at 200W or more each, really add up. I've worked in environments where each developer's office has a row of servers on the floor, and for the most part they are powered up. Assume an average of 3 such servers per developer, and that is
3 x 250 x 24 x 365.25 = 6,500 KWH
per developer per year. If you have 100 developers, that's 600MWH. At 1,100 pounds of CO2 per MWH, this is 330 tons of CO2 annually. Staggering. Turn them off. This should be easy to make happen.

Use virtualized servers: lower electricity use. This will be easy to sell to your CFO, your safety officer, and the IT department. Those many configurations of developer test machines you need - convince your developers that they need to help the environment and your IT and energy budget by virtualizing (e.g. VMware or Parallells). You'll can probably sell this by telling your developers that this way they can always have the highest performing servers instead of the old and dusty ones that are often relegated to test. By hosting multiple configurations in one machine, you don't have the capital risk nor the energy consumption of a large number of test machines. The challenge will be that developers often don't want to deal with the extra layer of software; maybe IT will provide some help to do installs for the developers in exchange for the lower maintenance provided with fewer machines.

You can't "make it up later"

When you see a schedule challenge, followed by words like "but we'll make it up", you should be seriously suspicious. When the plan isn't working, the idea that things will magically get better in the future simply strains credibility. My inspiration for this post is Boeing's announcement today of a six month slip of their new airliner, the 787. The kicker here is that they've known about the problem for some time. Apparently it's due to a shortage of titanium fasteners. I can totally respect this challenge because it probably wasn't viewed as one of the major risks to the program. (We used to do the same thing with power supplies in our high end computer system design -- we spent a lot more time on the protocols, cache consistency, memory latency.... "easy" stuff like power was overlooked and often where we got in trouble). In fact, Boeing knew enough about this in June that it was written up in the WSJ. Then, they reported they don't need a lot of fasteners, and that they had reduced the production quantities to be able to avoid "over promising and under-delivering". Yet, a mere four months later, that's exactly what is happening. Moreover they say that it won't affect their earnings guidance. Do you believe them?

The good news is, it sounds like they came up with a new plan to try to adjust to the risk - but it wasn't enough. So it wasn't simply that "we'll make it up later", they did change the plan. But they failed to factor reality into the equation. What you'll often see is an abundance of optimism and wishful thinking. "We'll make it up".

No. You very likely won't. What will probably happen at a minimum is that some corners will be cut. Often, as in the Boeing case, the customer pays. It's a great way to lose customers, ironically, by trying to make them happy.

Focus

I saw this story this morning, about Columbus Day protests in Colorado. At the risk of being insensitive, this seems like a complete waste of energy. You can argue the relevance of the federal holiday I suppose. It was 500 years ago, and Columbus didn't really discover America, he simply introduced Europe to it. But what's the point of the protest? Draw attention to behavior we no longer tolerate?

Sometimes your employees may get emotional about past behaviors and decisions. Focus on the present, and commit to a better future with your actions, showing that you will never compromise the integrity of that future.

Teaching engineers

What do we want our Universities to teach computer science and computer engineering students? I've lamented that teachings are sort of bipolar: flip-flopping between minutiae associated with implementation (and attendant lack of attention to design), and interesting but in the long run nearly useless theory. This week's New York Times Magazine describes a new university, Olin, which graduated it's first class last December. The article says they focus on teaching engineers to do the right thing, not just do the thing right. The description would have sounded way too artsy for me when I went to school, but from my current perspective, I think it would be a refreshing change. Engineers have a strong bias towards saying "yes" - they are taught to solve problems within given constraints. What I haven't seen as much of, is identification of which constraints are unreasonable and creative thinking about how to get better solutions by changing the constraints. We need more of those engineers.

Moral Hazard

It's fascinating to me to read about whether lower fed discount rates cause inflation, and even whether it's good for the stock market. I wish I'd blogged on it last week, because there was great article that basically said we have no idea how the economy really works. We understand some things, for example, a smaller discount rate immediately increases the value of stocks. When the discount rate was lowered, the NPV of all stocks immediately rose, if you assume that the value of a stock is actually correlated to the company's ability to generate free cash flow (if it isn't, then the stock market must be a form of gambling). But we don't understand the long term effects of such changes. There is no shortage of experts willing to write about whether this is good or bad. But I really enjoyed this one: http://online.wsj.com/article/SB119025102955233333.html, which has some great quotes and concerns. If indeed, past irresponsible behavior could lead to pain for millions of people, the discount rate simply had to be cut. The question is, how do we know that is the case? We may very well have increased our risk.

Another negotiating tool: WIFM

You may have heard WIFM in the context of managing others. WIFM stands for "Whats In it For Me?". Sometimes you'll hear it as "WIFM radio". (Ironically, there is at least one real WIFM radio station). WIFM doesn't mean look out for yourself - rather it's a reminder that others will be looking out for themselves. So put yourself in the other's perspective, and then answer the question of what's in it for them, without them having to ask. You can use this in managing others, but it is essential in negotiation. I finished my little negotiation yesterday, and we are both happy. This is at least partly because I looked at it from her perspective, and thought about how both our needs could be met. I structured a deal which lets her get what she wants if I get what I want. Conversely, if I don't get what I want, she doesn't either. It's fair, and it puts us both on the same team with the same objectives.

Negotiating

I'm currently doing a little negotiating, so it was timely that this month's HBR has an article in it about negotiation. Entitled Investigative Negotiation, it resonates with me because it is loaded with examples and techniques about understanding the motives of the people you are negotiating with, rather than trying to "win". It somewhat reminds me of advice on selling by Jeffrey Gitomer, and consulting by Jay Conrad Levin and Michael W. McLaughlin. They all advise: quit talking and start listening. People may not be forthright in telling you what their needs are; that's your job, to learn those needs. The HBR article even gives examples of how you can make simultaneous multiple offers and use the response to learn about their motivation. One of the techniques is to offer information first, but make sure the other party knows you want them to provide information in return. I think this article helps define negotiation as a cooperative and even fun undertaking, as opposed to a competition. Good stuff.

Measurement Constructs

I've been learning about the methods used by the PSM group, which is detailed in their reference book here. One of the concepts is what they term a Measurement Construct. It's a graphical structure that shows how you go from an Attribute to an Information Product. At first the whole thing seemed very intuitive, but the structure helps you consider all the aspects of metrics. What are we trying to learn, how should we present what we know, how we should gather the data, and in what ways can combine data for more information.

The relevant terms are:

Attribute: a property or characteristic
Base Measure: a single independent measure of an attribute
Derived Measure: a function of two or more base or derived measures
Indicator: a measure for presentation which enables evaluation of an attribute

It's kind of a dry read but I think most software and system organizations I have worked with would benefit from some of its discipline.

Geeking out

My excuse for not blogging recently is that I have been totally geeking out on the technical details of my startup. We're using windows, mac and ubuntu, NetBeans 5.5.1 with the visual webpack and the mobility pack, Sun's Java Application Server, asterisk (via asterisk-java), a third party routing library and SAS, mySQL, some Apache Commons stuff, svn and a bunch of free tools. We share our code via svn's tunnel through ssh using public key cryptography, making it very secure, and low maintenance.

The NetBeans environment is impressive and occasionally oppressive. One thing that is amazing is that this is all free, and you can find help on all these components, although it can take you a while to sort it out sometimes. I had a lot of trouble trying to test J2EE services on my Mac - the behavior was very inconsistent. Eventually I gave up and am using Ubuntu.

The use case the NetBeans team really missed big time is the use of third party libraries. If you do this the natural way, it ends up being part of the user's environment instead of what gets put back with your source code to your repository. There is this nice hack which works, assuming you don't have erroneous dependencies in your hierarchy (if you do, it totally tanks NetBeans and the working copy - you have to start over! Total disaster).

Anyway it's been fun and I made a lot of progress. We now have a prototype of a voice client to our service, built using some of the patterns I learned about a few weeks ago (notably the command pattern - I used it to structure the menu system). Now I can get back to more management stuff.

Confused about Open Source?

I found this excellent reference from O'Reilly, which compares various licensing mechanisms including GPL, LGPL, Apache, etc. The entire book is online in PDF format, and it walks you through the important legal language of each type and then explains it to you in english. You don't have to read the entire book to get to a good understanding of how they differ. I recommend this for any manager whose department uses open source or free software and obviously if you are considering putting some of your code into open source this is an essential read.

Blog Action Day: the environment

On October 15, blog action day, thousands of bloggers will blog normally, but include something regarding the environment. If you blog, check them out and register! If you read blogs, October 15 should be interesting. The promo video is here:

"Buying Back" risk

In the September 2005 issue of the Communications of the ACM, Philip Armour touches on a method to keep two plans: the work-to plan, and the commit-to plan. He says that if an organization chooses not to intentionally manage the risk due to uncertainty, that either the customer (through lack of quality) or the development team (through overtime) ultimately pays for the risk as it materializes into problems and issues. I would like to add that the third possible payee is the organization itself, through missed commitments.

I've worked in environments where we had a buffer, but not quite the way he describes. Most places I've worked felt that the buffer would be spent because with lack of pressure, people will work less hard; therefore you will still miss your dates and you will produce less output. However, Mr. Armour talks about a way to consciously manage the buffer which I think alleviates such concerns.

When the initial plan is built, the team puts together a "Management Risk Reserve". If you have metrics from your history, you might be able to do this in a way that scales with the complexity of the project in a very meaningful way. In exchange for regular attention to this reserve by management, the team agrees to try to work to the "work-to" plan, which contains all the things that the team knows they need to do. As work progresses, some risk is reduced, and other risk is realized. It's a short article and not particularly operational, but you can imagine doing this quantitatively on the risk reduction as well as the realization of new work that must be done.

I contend that this is totally doable within an iterative/agile environment. Most organizations still have a long term commitment they want to manage to. Agile development helps you quantify the risk better.

Harmony and Apathy

In a 1997 article entitled, How Management Teams Can Have a Good Fight, Eisenhardt, Kahwajy and Bourgeois make the case that the absence of conflict is not harmony, it's apathy. They talk about healthy conflict versus interpersonal conflict. Healthy conflict explores options and leads to better understanding. Interpersonal conflict involves emotions which block efficient and effective resolution.

They note a number of attributes that executive teams with good conflict management skills have; first and foremost is management with data. In the absence of good data, they point out, executives waste time in pointless debate over opinions. I have personally seen such a spiral; it is difficult to break free from that, especially when the opinions are strongly held, because then gathering data is perceived as a waste of time.

They also point out that humor is strikingly absent from teams which demonstrated high interpersonal conflict. The natural question here is whether this is cause or effect. I am a large fan of humor, it tends to defuse tension, even if contrived. People appreciate it. However, once your environment is plagued with high interpersonal conflict, it might just be that it is no longer fun, and therefore not funny either.

The factor that led me to the article, is what they refer to as balanced power structures. To minimize interpersonal conflict, they say, the CEO has to wield ultimate power, but the executives all participate in strategic decisions, and each has power over their functional areas. The opposite of this is a "power vacuum".

I really like their advice on how to build a team that deals with conflict well. It seems like it could be almost as effective with management of peers in the case of a power vacuum, or from above. Their last line: "often, what passes for consensus is really disengagement".

Don't let your reports or peers off too early or easily, and work to remove the emotion.

Metrics: avoiding pitfalls

Karl E. Wiegers, who wrote a great book I've used called "Peer Reviews In Software", published these ten traps to avoid when implementing a metrics program. Anyone who has implemented a metrics program likely has experienced every one of these. It's a handy reference to put on your wall. Most are self explanatory and intuitive, once you see them.

The one I'm not quite sure I'm on board with is Trap #7: Using Metrics to Motivate, Rather than to Understand. Since an objective of measurement is to make data driven decisions, this is indeed, providing motivation to act. If the metrics show you spend a lot on rework, or it is trending up, then you and your team will be motivated to do something to improve. Conversely, if the metrics are trending down at a rate that is acceptable to you, you won't be motivated to do more. Maybe I am being picky here, in that you clearly don't want to punish with metrics (c.f. trap #6), and maybe "motivation" is along this same line. I'd be more in line with the trap if the word "Manipulate" replaced "Motivate", but maybe that's just plain obvious.

If we must have ten traps, I would replace #7 with "Automate everything" - a bold statement but once automated there is little to no long term cost, and the metric can be gathered even once it stops being useful - in case a change causes it to me meaningful once again.

There is no magic.

That's the conclusion of Terry Coatta's writeup on the demise of CORBA:

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=491

We think of SOA as being a paradigm shift; it's actually an improvement which provides greater flexibility than CORBA and others, but the old rules still apply. Distributed computing is still hard, in general.

Deliberate Practice`

If you Google those two words, you'll find the term ascribed to Dr. K Anders Ericson. His research indicates that expert competence in an area is learned, not gifted, and that it requires special attention to what a person doesn't yet do well. He quotes Sam Snead:

It is only human nature to practice what you can already do well, since it's a hell of a lots less work and a hell of a lot more fun.

He says that practicing what you do well doesn't lead to extraordinary performance; this makes sense intuitively. He must be a golfer since he gives lots of golf analogies, and these do work for me. Apparently I might be a better golfer if, instead of trying a single shot for each opportunity, that I was able to try multiple shots and compare the results.

My problem with his advice, is that in business, as in golf, there are very few "do-overs". In particular if you are leader and you mess up, not only do you forgo an opportunity to fix that opportunity, but you may give up other opportunities as a consequence. That is often true with your customers, your board of directors, your boss, and your employees.

It's great to know that research indicates that you can learn to become great with deliberate practice, but it's disturbing to note that in so doing, you may not be able to practice any longer. His recent article in HBR talks about simulations, such as reviewing past histories of medical information with proven outcomes, and attempting to reach the correct conclusion based on the evidence. Unfortunately I can't think of an analogy for business decisions.

Disruptive Change

Clayton M. Christensen, author of The Innovator's Dilemma, along with Michael Overdorf, wrote a paper in 2000 about why companies succeed or fail at disruptive innovation. They argue that established companies by definition can't do disruption - the processes and values of the organization keep them on a track of evolutionary changes, which Christensen calls sustaining innovation. The idea is that the very things that make a company successful are at odds with creating a disruptive innovation. The combination of values and process determine what decisions will be made in the organization, at every level. They point out that a key metric to good management is whether distributed decision making can be made consistently with the strategic direction and business model of the company. That behavior is what makes up the value system -- the answer to why we do it this way; the processes are how we do it. To be disruptively innovative, why and how have to be free to move.

They show a simple 2x2 table which indicates various ways of separating innovative work so that it is most likely to succeed, with value and process change as the axes. Where there is little change to either, go ahead and keep the formal team together. All other changes they recommend factoring the team out for success, so that it can break free from the constraint.

Another dimension in innovation measurement

Morten T Hansen and Julian Birkinshaw describe yet another method of analyzing and improving a company's ability to innovate. They describe an "Innovation Value Chain" which gets evaluated in its ability to Create, Convert and Diffuse innovation. In other words we often just think about the ideas, but many great ideas go un-monetized because they get lost in the shuffle, are not properly funded, or not properly socialized.

• Create means to generate ideas.
• Convert means to focus on the right subset of ideas to convert into practical products/services.
• Diffuse means to line up the rest of the organization and customers to adopt the new product or service.
  

They have a fairly simple tool to gauge an enterprise in the three blocks of the chain, and give some reasonable examples and remedies for what to do for your "weak link" in the chain. They make a compelling case that a company will tend to under invest in the weak link, but continue to invest in areas where they are strong, and how that might ironically crush the innovative spirit.

Great Reading: Patterns

I'm reading a book that software executives can use to understand Design Patterns. After going through this book you'll be able to ask better questions about the architecture of your OO software. So far I've only gone through the Strategy, Observer, and Decorator patterns... but suddenly I understand them and can talk at a much higher level of design than ever before. The book is well written and engaging, it is called:

Head First Design Patterns

by Eric and Elizabeth Freeman. The style is credited to Kathy Sierra and Bert Bates, creators of the Head First series. Good stuff.

Arrogance

I was discussing Arrogance last week with a colleague; we noted some really smart people who have changed professions, who think they know so much more than those who have studied the profession for decades.

Peter Drucker wrote, in an article entitled "Managing Oneself":

Far too many people—especially people with great expertise in one area—are contemptuous of knowledge in other areas or believe that being bright is a substitute for knowledge. First-rate engineers, for instance, tend to take pride in not knowing anything about people. Human beings, they believe, are much too disorderly for the good engineering mind.

For some reason I assumed Arrogance was on the list of "seven deadly sins"; Wikipedia says it is not. Generally, Arrogance is something you lose with maturity; in particular with a successful management career comes an understanding that you need the views and analysis of others to be successful. But I have observed in others that the reverse is true - they have developed Arrogance as a consequence of their success.

This to me is the ultimate failure of management; if you enable or tolerate the increase of Arrogance in your employee, you have failed. It is our job to teach, by example and by coaching, that others have something to offer and it is the employee's job to seek out and discover that offering. I believe this can be taught without damage to the ego. Humor works - and is a good teaching tool.

My assumption is that many potential teachers overlook this sin if the sinner is a high performer. I suggest you never do that. We don't have that luxury if we are to stay competitive. The world is different, incredibly complex, and changing; we must respect and learn from others. Creating leaders who don't have this property can only lead to failure.

Problems and Solutions

Dr. Arthur D. Levinson, CEO of Genentech, is quoted in the Wall Street Journal today:

I have a philosophy -- I invite criticism. But don't ever come to me with a complaint without saying, here is what we might do to make it better. I am happy to hear Part A if I hear Part B.

I have tremendous respect for the man; he's built a successful business in an industry he describes as the "biggest money losing industry of call time". But I think that the philosophy he describes is one that will lead to trouble, and in any case is not my philosophy.

First off, let's distinguish between problems and complaints. A problem is a situation deemed potentially harmful. A complaint is a statement about dissatisfaction with a situation.

I contend that all leaders want to hear about problems in their business; complaints are one way a leader will hear about them. If a leader requires that a person bring a solution to any problem, that means team members will be working on solutions that individuals perceive as problems. The leader wants to be able to distinguish between real problems that are worthy of finding solutions, perceived problems that are not problems at all but perception and communication issues, and problems that are real but not worth working on. If you adopt a policy like Dr. Levinson's, you don't get to make that distinction. Moreover if it becomes part of your culture, it gets pushed down to the next level and now management in general doesn't get to understand and make that decision.

I certainly understand where Dr. Levinson is trying to go with this; it might be a necessary policy in a company where people don't step up to find solutions. Given what he says about Genentech, though, I find it hard to believe that is the case. I can see adopting the policy on an individual basis when you have an employee who wants to put monkeys on other's backs instead of solving problems; but as a general policy, I don't get it.

Measurement of Innovation

I found a reference for developing innovation metrics that I find useful. It breaks down factors that one needs to be innovative and gives suggestions for measuring those factors. Specifically, how to measure the resources, capability and leadership factors that might collectively be predictors of innovation.

Is innovation easier to measure than quality? Typically we measure what quality is not, and we assume that in the absence of proof of low quality, we have quality. This is apparent in software's measurement of defects: rate, density, resolution time, severity: these are measures of non-quality. I'm sure you've worked at places where that assumption turns out to be false. Perhaps quality itself is not measurable. Or perhaps it is simply that we can't definitely state what quality is, but only what it is not.

Can we make the same claim for innovation? If we measured a failure to innovate, would a low rating indicate a good innovation environment? It hurts my head to think about that. But it shares with quality the property that it is easier to measure what is not innovative. Whether something is innovative is subjective; there is no quantitative measure for whether it is or not. The reference above measures some things that are pretty concrete, such as the number of innovative ideas that become successful products. And I definitely agree that if you do not have enough resources, the right capability and leadership (culture) for innovation, it won't happen. At it's core though, how you decide whether something is innovative or not will have a huge effect on that metric, so I don't think the benchmarks they provide in the paper are really useful. But what you can use this for is trending over time in your organization as long as you can find some consistent way to evaluate the "innovativeness" of an idea.

Emotions

I had a new experience this week. One I hope not to repeat. The simple version of the story is that I needed $200 in cash, and ended up at one of those non-bank ATM machines. I asked for $200, it only dispensed $100, and I managed to pull another $20 out that was stuck in the output slot. This isn't what we've come to expect from these machines... at least not after we've used them hundreds of times. This was at Costco, and it happened right next to the person at the entrance door, so she knew I didn't make this up. It took about 30 minutes to figure out what to do, none of which resulted in me having the $200 I needed.

I was chatting and joking with the Costco employee most of the time. She said to me "you sure are patient", and that is the inspiration for this post. I asked her, what would be the upside of me getting impatient? If anything that would result in people less likely to help. Moreover, that would simply hurt me; nobody else will care. She understood; the surprising thing was that she expected something else. My behavior was not the norm.

So I thought about emotional intelligence, and looked up some old articles. It turns out that the behavior I demonstrated is just one of many emotional competencies which make up "Emotional Intelligence": self awareness, understanding emotional influence on objectives, staying cool under stress. I found this reference at the "Consortium for research on Emotional Intelligence in Organizations". I'm not making this up. You'd think they'd call themselves the CREIO or something. In any case it lists a variety of competencies which is significantly larger than might be intuitive. It's worth taking a look at the list and then doing a self audit to decide where you might improve.

Speaking Up

Maybe I'm a consultant because I say things when I shouldn't. Frankly, that's what you want in a consultant - you pay them to tell you the truth. There are surely engagements where you get paid to tell someone something they want to hear - probably mostly as a subject matter expert in a legal proceeding (I'm sure I have offended a lot of experts now). But really, wouldn't the world be a better place if everyone just told you what they think and feel? Perhaps that is naive.... but it's what I think.

I'm not sure exactly why people confide in me; perhaps it is because people learn that if they ask me something I will tell them what I think. I won't be offensive or suicidal, but if it is relevant, I'll answer honestly. If it is different than the party line, I'll explain the party line and it's rationale, and I'll support it and commit to it, but I won't express a point of view as my own that isn't.

James Detert at Penn State writes in the May HBR that employee's failure to speak up is a result of their risk/reward perception. Perhaps this is obvious but it means that they have to believe that saying something might result in a positive change, and that they won't be harmed by it. You can reinforce their confidence by being a change agent on their behalf -- step out, take the arrows for them, and stir things up - make something happen, even if you burn some political capital along the way. If you are successful and you shield them from any consequences, they'll use you for their sounding board. As an employee in some organizations, you might get shot for doing this. But if the change is worth making, and it's good for the organization, how can you not do it? If your organization can't do the right thing, is it where you want to stay anyway?

The other thing Professor Detert writes is that organizations develop implicit untested assumptions. I have seen this as well and it is the leader's job to seek these out and be the "myth buster". I had a management coach, Alan Perey, who was particularly good at demonstrating how to do this. It kind of goes just like a behavioral interview - for each statement made by the person you are working with, you have to decide if it is fact/experience based or the output of a model or theory. In short, is it fact, or is it opinion? And ask additional clarifying questions to hone in on that: "What evidence do you have....".

Leading the seriously talented

In high tech, we can hope that through corporate reputation, good fortune, persistence, and good choices, we get to have people on our team that are really smart. Ideally, smarter than we are. Consider the alternative: a team of people who are not as smart as their leader?

The challenge with really smart people is they do not really want to be led. I have seen this. According to an article in the March 2007 HBR, they want their leader to be smart enough to appreciate and understand their contribution, but not to outshine them. This I agree with. The article also says that they feel they are part of an external community that transcends the current organization. In my experience I have not seen this (this may be because I have spent my career with engineers). Many really smart people unfortunately focus on what they are good at and don't network enough or desire to get better at what they aren't good at. In fact the article talks about rewarding clever people with perks such as getting out of assignments categorized as "organizational rain": those things which clever people view as non-value add but are necessary to support the organization. I'll go out on a limb here and say that I think that is really bad for teamwork, and coddles rather than develops the superstar. The article goes on to say that the leader should minimize the rain; but that is obvious irrespective of the organization's talent.

I'll add that I've met a couple of basic types of clever people: those for whom recognition is a reward and gives them energy, and those who really don't care about recognition. I think the former is more prevalent but have no data to support the claim. Both types, when functioning well, want to do well. It's just a matter of whether you can add energy with recognition. Recognition doesn't have to be sappy or public, it's far more important that the leader knows what they've accomplished and lets them know it. For those for whom that doesn't work... you are on your own. You may have to ferret out those who pretend they don't want recognition -- a defense mechanism against being manipulated. Overall, in such environments, you'll do a lot more damage failing to recognize accomplishments than the other way around.

Measurement is hard

I was going to title this post "ISO 15939", but then many of you would not be reading this. However, this last week I was introduced to a measurement world I am still trying to figure out. It looks compelling, and it is related to this standard.

One of our challenges is convincing people that they should expend the effort to measure something. One of the books on this subject I like is entitled "Practical Software Metrics for Project Management and Process Improvement", by Robert B Grady. In the book he describes how you use the "Goal, Question, Metric" paradigm to choose what to measure. Using this method you first state what it is you are trying to accomplish, then what questions you would ask to see if you are accomplishing that goal, and then decide how you would measure the answers. Very simple, in fact, practical. The book is full of lots of examples too, and it's dense, and to the point.

Fast forward to this week. I had the pleasure of listening to Rick Hefner, PhD, Director of Process Management at Northrup Grumman, talk about measurement and CMMI. He referred me to http://www.psmsc.com, which I'm still trying to wade through. It seems based on similar principles. PSM is a web site for Practical Software Metrics. The book by a similar title was written in 1992, and this organization has been meeting on a large scale since 1996; yet I had never heard of it; hopefully that's just me and this is old news to you guys. The book was written based on experience at Hewlett Packard. The PSM web site and group was sponsored from DOD and the Army (this may be why I haven't heard of it). But ... bear with me, it looks flexible, not DOD-ish.

I'm sure a number of you will react that we just need to use agile practices, work hard, and hire good people and forget measurement. I'm sorry, but I won't ever agree. You can't improve strategically without measurement, because you don't know what to improve, or if you actually did improve. If your product and work life is perfect, your customers are always happy, you never miss deadlines, you have more revenue and earnings than you can count, and you have fantastic work/life balance.. then fine, maybe you don't need measurement. If you have that environment, call me - I'll work for you. Otherwise I think you should check this out, just to know what it is and see if there are tools here for you. And by the way, eXtreme Programming advocates metrics - you have to measure the number of stories built in an iteration. So please don't tell me I don't get it.

There are a number of extensive white papers on the site, dealing with subjects such as how to measure your process improvement efforts, and measurement of security properties of systems.

They have a piece of free software (PSM Insight) that will help you with measurement that conforms to iso15939. I haven't run it yet, but was viewing their online demo and it looks useful. One could argue it's simply a graphical tool for your data, but it seems to also get you to conform your data in a way that uses industry standard metrics and indicators, so that others can understand you better. I would be interested in any comments from people who've used this tool.

Bottom line: check out http://www.psmsc.com

Praise is getting harder

The Wall Street Journal yesterday did an article on younger workers' need for praise. (You'll need an online subscription to read the article).

The article claims that popular self-esteem-building parenting and coaching techniques have created a generation for whom a lack of continuous feedback feels like rebuke. The abundance of praise may have led to the formation of a cadre of narcissists. Moreover, in the race to provide such praise, praise words get inflated - "nice" and "smart" are no longer complements. What you think may be praise might not have the desired effect.

The article mentions communication that many of us are probably more familiar with - if nobody is yelling at you, that's a proxy for communication of satisfaction with your performance. That strategy will fail with many 20-somethings and you will be burdened with filling a vacancy. On the other hand, inflated praise may seem disingenuous, even to the receiver. Bottom line, praise is getting harder.

The article talks about how to give feedback in such cases; a lot of younger people may completely ignore candid feedback, because they are used to being told they can do anything if they believe they can. Steve Smolinsky advocated using language like "It's not as good as you can do", a compromise with some lack of directness.

All of this language is counter to a lot of how I have been coached and treated in my career. I'm certainly not advocating being mean, but if you are disappointed, the discussion has to happen; you may not understand all the factors, and very likely your employee doesn't. Clouding this discussion with praise may fail to get the point across. With practice, you can give someone feedback and show that you want them to be successful at the same time, without confusing it with ego-boosting messages. What this article says though, is that may not be enough. Perhaps you can use another technique they mention for relationships - give five times as much positive as negative feedback (but do it at different times).

Bottom line, this probably isn't new - you should already be thinking about how different people react to different forms of praise and feedback. What is new, to me at least, is thinking about it as a assumption based on age; it will require observation to see if the theory matches your reality.

Develop, Support or Punt?

As a leader, having identified an individual's lack of skill in a particular area, how do you decide whether to try to develop the skill, simply provide support from someone else in the weak area, or move the person out of the role or team? After all, it's the leader's job to remove roadblocks and provide support, right? When does support stop being a good thing and start being a problem?

I don't think this situation has a general answer. The only sound bite I have is that if the lack of skill could demotivate the team, then unless it can be remedied quickly, the person lacking needs to be removed. For example, if a person simply can't tolerate their design being reviewed, maybe they shouldn't be doing design; that in turn might have significant consequences for the individual, but the leader must consider the health of the team first. This is hard to do if the person has some other skill that is very helpful to the team; but it's not enough if it could take the team down.

Another class of skills are those that are required to perform the minimum requirement for the job. In such cases, supporting the person rather than developing the skill will be demotivating for the team. So for example, if the person cannot write clear documentation on their interfaces, but that is a requirement for the job, then allowing the person to be weak in this area by assigning it to someone else is not supporting them - it's enabling them to evade responsibility. The person may be a superstar in some limited ways, but if they can't do all the required steps in the job, they need to be fixed or removed.

After that it gets a little fuzzy. What if your superstar designer and implementer just can't negotiate? She gets nervous and clams up when she should be discussing who should do what... and she really hates negotiating. Should you overlook the shortcoming, try to fix it, or let her go? (Assume that this is not an essential part of her job, so letting her go isn't the right solution). She might quit if you push her too hard, but you know she could be so much more if she had this skill. I advocate you tell her that; your opinion on how much more capable she could be might be enough to overcome the fear. If she's really not interested in fixing it, it isn't likely that she will be successful in developing the skill. So first create the motivation for her to try; it is amazing what people can do when they want to. Failing that, assign her some support.

Eco-Capitalism

This twelve minute video talks about how some large companies have made environmental progress and money at the same time. Not only is this a fabulous trend for business and the planet, but it shows that if you look for win-win strategies, you might find them. Conversely, if your model of the world believes that something can't be done, your bias may inhibit or prevent it.

Intuition

I love this quote attributed to Jack Welch (and I've probably got it wrong, sorry Jack):

If we are going to make this decision based on opinion, I prefer mine.

I like it because it is straight up - facts and analysis are credible scientific truth-seeking mechanisms. Opinions are based on all kinds of human biases.

I attended a meeting recently regarding a paper to be published soon, about studies regarding expert's ability to predict future success of startups based on business data presented by entrepreneurs. The study group was able to use neural nets and Bayesian analysis to "code" the startup team's properties such that it predicted success better than VCs. It's not published yet, so I don't want to spoil their thunder, but it looks fascinating.

What this says is that your "gut" reaction is undoubtedly worse than careful analysis. It might be really good for those life-and-death split-second decisions using that small part of your brain wired for preservation. The allure of the intuitive decision is strong; but there is no evidence that it chooses the correct direction, and there is some compelling evidence to the contrary.

A May 2003 HBR article called "Don't trust your gut" reported that in 2002 45% of surveyed executives relied more on instinct than facts and figures. That's a staggering and scary number. It's so much easier to go by gut reaction, but the article makes the case that we are such effective pattern recognition engines that we see patterns where none exist. The pattern recognition skills built into your most basic brain functions are fast but not particularly good at sorting through risk. It's biased for survival; I read somewhere recently where a man had been next to a window which blew in during a windstorm, and now he gets nervous whenever he hears wind... totally illogical, but the pattern is burned in his brain.

My dog is a great pattern recognition engine. She notices subtle movements, sounds and behaviors and can interpret with surprising accuracy what will happen next. Yet I wouldn't ask her to choose my stocks for me.

Bottom line? Do the math.

Focus and Innovation

In my experience, a major impediment to innovation is lack of focus. If your organization isn't clear on what it is trying to accomplish and why, you are likely to consume your resources on a myriad of time consuming projects that contribute little to the effectiveness of the current product, and leave no room for innovation.

So if you want to innovate, get control of your portfolio. It will take time for this to trickle through the organization so that engineers feel comfortable saying "no" to things they used to agree to. It is hardest when those things are also things they enjoyed doing. I've seen a dysfunction where there seemed to be a gleeful satisfaction in avoiding accountability because the system wouldn't let engineers work on what they know they are supposed to work on. You have to observe this and stop it. But in order to do that, you need a clear mechanism for establishing and communicating focus.

Steven C. Wheelwright and Kim B. Clark advocate for an "Aggregate Project Plan" which decides on the fate of projects before they begin:

Simply adding projects to the active list—a common practice at many companies—endangers the long-term health of the development process. Management needs to create a set of projects that is consistent with the company’s development strategies rather than selecting individual projects from a long list of ad hoc proposals.

Wheelwright and Clark used change in product and change in (manufacturing) process as a means to define different types of developments: Derivative (little change in either), Breakthrough (change in product and process) and Platform (the middle). They also added a bucket for R&D and another for Alliances. They then plotted circles in the boxes to represent the resources required for various projects - larger diameter circles represent more resources. Using this system they were able to get management to remove projects that weren't clearly aligned with the company strategy, and in just a few years improved productivity at a particular company by a factor of three. The graphs started as a mess and ended up being clear and compelling.

Fewer projects meant more work got done.

Bottom line: don't let the busywork prevent you from doing the important work. We all know this is good advice, but it can be hard to make it happen. Wheelwright and Clark provide a tool to help you manage up and out to hold capacity back for what it is needed for.

Acid test for secure development

The March 1, 2007 issue of CIO magazine lays out questions for customers to ask you about your software development environment, and how to evaluate the answers. The first 5 questions are in print:

1. Do you review security at each phase of the software development life cycle?
2. What methodologies do you use for security testing your products?
3. Do third parties conduct security assessments on your products?
4. Do you have security squads that attack your products prior to release?
5. Do you use automated tools for security testing or code review?

and they have another ten questions in the full online article here. I can tell you that most of the places I have worked would provide really poor answers to these questions even today.

For those of you out there with products products which have access to your customer's networks and data: get yourself a roadmap for developing the skills in your organization so that you can credibly answer these questions well. Educate your management to get the funding and time required. We've gotten away with some amazingly casual attitudes towards protecting our customers, but those days are rapidly vanishing.

Innovation Test

I'm not sure if this is ridiculous or interesting, but I stumbled over a tool, put together by IBM Global Services, which portends to assess your organization's innovation strategy and benchmark it against 750 other companies. I rated a former employer and ... surprise... we didn't score really well. The assessment tool raises more questions than it answers, in my mind; and no doubt this is a tool to get you to hire IBM consultants to help raise your innovation. Well... let me rephrase that... to create an innovation strategy.

The tool is here:
http://www-935.ibm.com/services/us/gbs/bus/html/gbs_ceo_iat.html?re=schome

but I'm going to make a broad claim here and see if it sticks. Innovation is less about a strategy and more about a culture. You have to look beyond the short term, make sure people are not overwhelmed with the day-to-day things, so they have enough time to think about making long term things better. And of course reward the behaviors that support innovating. Now that I've said that, maybe I'm doing the same thing as the survey. I'm just as trite... and I didn't have to survey 750 CEOs to get there.

Cool Change Management predictive metric

The October 2005 issue of HBR has an article called "the hard side of change management". They introduce a new metric called DICE, which stands for "Duration", "Integrity of Performance, "Commitment", and "Effort". In their study they found that by applying simple subjective scores to each of these areas, and then a simple formula to roll up a total score, they have a number which can be used to predict success or failure. They did the study on over 1000 projects and found correlation between these four factors and were unable to add additional factors to produce a better predictor.

Amgen used the tool in 2001 when they made a series of changes. At one point they used this metric on 300 initiatives (yikes!) and reconfigured resources on 200 of them based on the DICE framework.

The authors suggest that it be used in one of three ways: track projects, manage portfolios of projects, and force conversations. All three are really helping the organization decide where to focus time and energy.

The article gives specific guidance on how to evaluate a score for each factor. You can pay for and download the article here from hbr.com.

Root Cause (or, punishing the innocent)

An article in the Wall Street Journal yesterday reminded me of how easy it is to fire people up to solve the wrong problem. For those of you with an online WSJ account, you can view the story here. There is also this article in Information Week which anyone can read. The articles talk about a bill that republican Michael A Costello is sponsoring, Massachusetts House Bill 213, which would punish retailers for leaking personal data. Now, don't get me wrong, we do want to provide incentives for protecting personal data. But the issue here is stolen credit cards. The root of the problem isn't security practices at retailers. It is not possible to completely secure a complex system from hackers. There will always be ways to get such data. Holding the retailer accountable is just wrong. Similarly, holding the software, system, and database vendors accountable is also fundamentally flawed.

What is the core problem here? The main problem is that credit cards are embarrassingly insecure. The banks don't deal with the problem because it has been less expensive for them to pay the price of failure than it is to fix the problem. What this bill would do, if passed, is completely let the credit card companies off the hook. That is just so wrong it is offensive, and I hope people see this for what it really is: an attempt to remove the increasing risk of credit card theft away from the group who is really responsible, by taking advantage of the current emotional response to recent TJ Maxx theft headlines.

The credit card companies can solve this. If you've used a SecurID card from RSA, you know that a credit card sized object can provide a unique temporary number based on a secret PIN you provide. You must have the card and supply the secret to get a one-time authentication. Instead of the inane little three digit code credit card companies have us copy from the back of the card, you could use a dynamic generated code which is based on at least two factor authentication.

Using such a system, it does a thief no good to have the card in their possession unless they have also obtained the magic number. If that did happen, the person who lost the card simply reports it stolen and it is disabled. No break in to any system would divulge the personal secret, and the TJ Maxx problem would simply go away. Not only does this virtually eradicate the most prevalent forms of theft, but it provides the bank with non-repudiation and replay protection. In other words, customers can't claim the charge was made without their authorization, and someone can't later use the numbers to create another charge. This means the consumer and the retailer win, at some cost to the credit card companies relative to the current system; but how much more expensive is it, if most of the theft goes away?

There are other ways to do this as well, probably equally effective, and some which are easier to use (hosted on a cell phone for example). But the banks don't want to invest in the infrastructure, and now they are trying to legislate passing the buck to the retailer, which ultimately will end up being paid by either the consumer or the systems providers, while the credit card companies continue to make record profits with inferior technology.

So let's quit punishing the innocent and solve the right problem. The retailer and the consumer pay the 3% transaction fee - shouldn't we demand that they earn their money and fix this abomination?

Do the same in your business. When someone is pushing costs around, take a look at what the real problem could be. It's probably the one that saves the most cost for most stakeholders, and in particular respects your customer's costs.

A change tool: ADKAR

I was considering a potential assignment and rummaging through my toolbox, when I recalled an acronym: ADKAR. I don't recall where I originally learned it. It is a diagnostic tool to help you figure out how far along a change an organization is, and what remains to be done.

(A)wareness is present if people are aware that a change needs to be made.

(D)esire is present if people want to change the status quo.

(K)nowledge is present if the people know how to change it and get to the new state.

(A)bility is present if the people are actually able to work on making the change -- including but not limited to (for example) being given enough time to do so.

(R)einforcement is present if there are positively reinforcing reasons to keep the new state.

It's compellingly simple on the surface. The hard part is really who are the "people"? An organization generally will have some people with each of these attributes at any given time. A stakeholder analysis will help here, but I think there is a momentum factor as well. As you progress down ADKAR, you have to line the influencers up and gain momentum with everyone involved.

The requirements factory

I was speaking to some offshore development managers last week, where we were discussing what a challenge it is to get good requirements. This is not a new phenomenon, it has just gotten so much harder with increasing levels of technical complexity and the cultural and distance diversity of our current development landscape.

The May 1995 issue of Communications of the ACM included several articles about requirements for software products. One of them involves how Digital Equipment Corp redesigned their requirements process. Their challenges and learnings are still relevant today.

They first described a fairly traditional nine-step process that one might find at any major software development organization. It isn't "waterfall" since many of the steps overlap. Nonetheless they mention that many product development personnel expect that creative, knowledge-driven processes are similar in execution to deterministic, manufacturing style processes, and that it was that view that was correlated to dissatisfaction with the requirements management process.

[they] expected the process to do the creative work of contextualized data collection, interpretive data analysis and responsive design

The teams that were more successful allowed themselves more flexibility on the process. In other words they adjusted the process to the problem. This supports the idea that a process should not be over-prescribed; the team needs the ability to be creative not only in how to implement the solution, but in how to figure out what the solution is.

Then they did something very innovative and interesting. They incorporated creation of marketing deliverables into the requirements management process. Specifically the marketing and advertising messages, user information, pricing and competitive positioning and sales and support information. I haven't worked or consulted anywhere where that was done up front, but it strikes me as a brilliant way to engage the cross functional teams to work through the entire problem set and ensure that they understand all aspects of what the proposed product is and needs to do. It provides the right framework to help answer the questions which will inevitably need to be solved, and gets them resolved earlier. The result is lower requirements churn.

The challenge for most organizations is going to be the change in behavior required to get the marketing department to work in a fundamentally different way. That means you'll need a compelling vision or a painful execution failure, and support from the top.

A well written product quality article

I was part of an effort where we had a tremendous impact on quality in just a couple of years. We principally did it by turning the organization around from its earlier behaviors, and simply making it clear that quality is the developer's job, not the QA department's. QA's job is to measure and prove that the developers did what they were supposed to (or that they didn't). Development's job is to design and build a high quality product. A lot of development groups don't run that way; we got fantastic results by making the change. I found this writeup, by Karl Wiegers, which talks about how to specifically implement systems which support that goal. It is fantastically well written. Karl is also the author of a book I have used to set up review systems, called Peer Reviews in Software.

Effective Communication

I found this on Ronny DeWinter's Software Quality blog:

Communication levels:
Not everything that is said is heard.
Not everything that is heard is understood.
Not everything that is understood is agreed.
Not everything that is agreed is applied.
Not everything that is applied is retained.

That is a fantastic short synopsis of why communication is so difficult. It shows that just getting someone to understand you is not enough. Of course, getting further down this list is not always required. But if it is, you should test every step so that if a breakdown occurs, you know where it happened and how to fix it.

You may not need agreement in every case, but it is nice to know when you don't have it, and if you have trust, agreement is testable simply by asking. If you don't have trust you may have to test downstream.

One of the places I worked would appear to have agreement but often fail to actually practice what was agreed. Application or practice should be easily testable, you can build it into the original communication. For example, "When you complete this, send me a copy".

Whether something is retained or not may or may not matter. If it is important to you that it is retained, put a follow up action in your favorite planning tool to test future retention.

Who's schedule is it anyway?

Delivering new products on schedule is always difficult. At a recent Agile Software seminar, someone asked the crowd if they had ever had any home remodeling done. A lot of people raised their hands. Then she asked if it went according to plan; very few people raised their hands. The point she was making was: if something as well understood as remodeling can't go according to plan, what makes us think that we can do something that has never been done before, and predict the future outcome?

What can you do if your schedule is dictated? This happens in many or perhaps most organizations, and it's not going to change anytime soon. But you can manage it.

I remember an executive who once told me: once your organization gets to a certain size, you are expected to just figure out how to make the dictated schedules work. Whether this is successful or not depends on what percentage of your responsibilities has this attribute. If schedule is the number one requirement for 10% of your work, indeed, you should be able to manage it. Somewhere between that ideal and 100%, you will hit a wall unless you have a method to deal with the unsolvable problem.

I advocate for a highly transparent system to communicate the decisions you are going to have to make. Specifically, you really only have a couple of variables to play with to meet the schedule: resources and function (some people will say quality too is a variable -- depends on your environment). You may need to decrease function or adjust schedule in another area to free up resources to meet the schedule on a higher priority project. The transparency depends on your ability to rank the projects in a way that meets the corporate strategy. You will need to articulate and defend the priority of each; depending on the number of items, you may need a spreadsheet and a numerical method for ranking that can easily be explained. Once you have the ranking, you can justify hurting the lowest priority projects in function or time in order to fund the highest priority projects.

This seems self evident as I write this, but in practice it can be really hard to do when the project you are hurting is going to affect someone else's bonus. Once ranked, socialize the ranking before adjustments need to be made, so that your decision criteria has been vetted before you need to hurt someone's favorite project. To be really transparent, make sure the stakeholders of those lowest priority projects understand the risk involved.

Software Product Lines

I decided to cover this subject since the December issue of Communications of the ACM is dedicated to the subject matter. I first got introduced to the terminology last year when I was talking to a San Diego employer, who was looking for management talent with this skill set. I didn't find much information on it then, but bought a (largely boring) book on it.

If you haven't heard of it, it's kind of the holy grail of software development. What if we could stop re-implementing stuff, and use the stuff we have already invested huge money and effort into making correct? People talk about re-use all the time, but it really doesn't happen significantly in real life. So we pay our employees to solve similar problems over and over again. Extremely inefficient. I've long been a proponent of solving this problem... imagine what it could do for your quality alone. Can SPL really solve this problem?

I don't yet know the answer to that question. A significant amount of information comes from the SEI at CMU. In particular, check this out. Google of "software product line methodology" turns up a bunch of references. Maybe I didn't do it right last year, but it appears that the methods have a lot more traction now. CMU is even offering a certificate program in it.

The articles in the December Communications of the ACM were mostly written in academia. One was written by a leader at Nokia. I mentioned that a San Diego employer is changing their organization and development practices to embrace SPL. It must have enough evidence of success to be worth it, or maybe it's just another management fad. The challenge is that it takes additional work to break your products into product lines; different practices, organizations, processes, roles, etc. The initial change will be hard, and even after that there is an investment hurdle to get over when determining new product lines.

What the methods still seem to need in my mind, is a good grasp on the future. I am dubious about the abilities of the average organization to do a good job at that. I suppose applying it to the cash cows makes sense, except that by definition they already exist, are stable, and making money. So to change it you have to believe you need to make significant additional change, or maybe your current software inventory is too hard to change (either in development effort or product stability).

I believe this method is applicable to larger organizations with good Voice-of-Customer (VOC) data. If you really know where you have to go, you may be able to make the right investment decisions to create software product lines.

Sustainable Advantage

Because I am such a fan of innovation, one of my former bosses once chided me, saying: "The only sustainable competitive advantage is execution". The context of the discussion was about Apple Computer's innovations, and whether they were innovating or simply producing ... well .. art. This quote from fastcompany.com inspired the conversation:

If your cool new thing doesn't generate enough money to cover costs and make a profit, it isn't innovation. It's art.

That article, written in January 2004, may have to eat its words because Apple has proven to be an impressive execution engine. Two incredible examples in my opinion are completely switching over to Intel ahead of schedule, with great quality, and changing the way music is distributed and sold. These are really hard things to do, and they executed amazingly well. It didn't hurt that the products are world-class cool, but what gets lost is how those great ideas could have been simply ideas. The difference is they set audacious goals and then they executed.

That's a long introduction to what I want to talk about, which is taking a fresh look at your business from the standpoint of execution. We complain about how offshoring is making things so difficult, how technology and open source and infrastructure has enabled a lot of competition. Yet we rarely take a disciplined, open, introspective look at our value chain and ask "why" at each step. If we did so regularly, as part of strategic reviews, we could deliver better products faster to customers, increasing customer satisfaction and our brand's reputation. In the process we can literally crush the competition, and then we get to call the shots instead of constantly reacting.

You can use tools from six sigma and lean, to evaluate what you are doing today, where your value is created, where effort is expended for little or no value, and where inventory queues (not necessarily physical inventory) prevent faster flow of value creation. The objective is to get objects through the value creating engine faster, spending enough administrative oversight to ensure the process is working in terms of quality. To do this, you have to start measuring, and that might be difficult if your organization doesn't want to do that extra work. I advocate you start by creating a value chain map so that at least you know what you want to measure and have enough information to make a compelling case for why the organization should do the work to collect the data.

I want to mention, you don't have to fear six sigma. You can use the tools without making the whole organization embrace it as a normal part of their operations.

If you can get that far, and can ensure the integrity of the data, the rest should go a lot easier. You'll still need to involve stakeholders every step of the way, who may feel threatened if something they currently do is no longer necessary. In the end though, you should be able to bring everyone together if the improvements fit into your overall strategy. Using the data, the tools, strategy, communication, and change management, your company too can be a world class value producer.

Innovation and middle management power

Rosabeth Moss Kanter wrote an article for Harvard Business Review in 1982 that was reprinted in 2004, entitled "The Middle Manager as Innovator". She points out that middle management drives changes that increase organization capacity.

Among the many things she says that I agree with, she talks about how lack of power in these ranks can interfere with the innovative process, because it inhibits collaboration. When power is unclear, unfocused, or unevenly distributed, managers are more concerned about protecting their turf than collaborating for the greater good. The successful middle manager in these environments uses their power to persuade their peers to support their cause. This is the good side of politics, influencing others to accomplish the greater good. In order to be successful at doing things out of band, almost surely these managers will need extra resources, and that will likely come from the manager's peers, and he or she must have a little support from higher up to prevent a veto from stopping the project.

One of my coaches pointed out that in order to make things happen, you have to have the right combination of Power, Influence and Authority. The required mix depends on the particular objective. I think in Ms Kanter's article, some times she is talking about influence and authority rather than power. Influence is the ability to change someone else's direction based on a number of skills including communication, persuasion, trust, vision, etc. Authority is that property which is granted to you by someone who has higher authority - it is what the manager is officially allowed or expected to do. Power is the ability to inflict consequences, good or bad, on others.

I have worked for companies where collaboration was really difficult, and I think that it was the lack of power anywhere in the organization that was a key cause (when this is the case, authority and influence must play a larger role, leaving things unbalanced). Some of my peers an I analyzed what it was we were actually empowered to decide. It was almost nothing, limited to who gets promoted and how much to compensate them. This was an intentional part of the culture, Darwinism. One influential leader told a group of new managers, "If you want to get something done, don't ask for approval, just do it". This was felt to foster an innovative environment, and in older times it worked. But when power is fleeting and temporary, and everyone is trying to make their own project successful, you will see very little collaboration.

Collaboration is key, in my opinion, to long term success and market leadership with innovation that improves not only what is delivered, but how. To accomplish that, make sure your middle management is empowered.