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.