"Valero objects to being forced to fund its own demise."

That quote came from this recent Mercury News article; it made me want to bang my head on the wall.

What is it with these guys? Kodak invented digital photography in 1975, and then covered it up. They declared bankruptcy earlier this year. These clowns should have been leading the charge into digital photography; they had a 1.4 Mpixel CCD sensor... in 1986! The issue? With Kodak, as this Forbes article puts it, the company "had the nearsighted view that it was in the film business instead of the story telling business."

Nobody wants film—nobody has ever wanted film; what they wanted, and still want, is a way to bring the past into the present. I almost wrote "what they... want is photos" but that's too narrow, too; think 8mm movie film, video camcorders, and who knows what else; the Forbes article is right: Kodak were in the storytelling business, not the film business. And the film business has been in decline. Kodak could have exploited its early (early!) lead in digital photography so that the declining film business wouldn't have killed them.

This guy from Valero sounds like someone from Kodak: they're in the oil refining business. Dude, nobody wants gasoline; nobody wants diesel either. What we want is to move from point A to point B. Nobody cares whether that's a fill-up of electrons, hydrogen, hydrocarbons; what everybody wants is a way to get to their destination.

Here's a little more free advice: there is only so much oil on the planet, and we can't make any more (I'm talking economics here). Demand for the diminishing pool of oil is rising—and I don't just mean from China and India. Dude, the oil business is a business in decline. You gonna be Kodak and try to milk the declining oil business? Your shareholders should insist that you guys get into the hydrogen business, 'cause we're gonna be out of oil one of these days—yeah, it'll be after you retire, but how d'you want to be remembered? As one of those clowns who drove over the cliff you knew was coming? Or as someone with the foresight to steer away from the cliff and toward a bridge to a possible future?

You guys at Valero have some expertise that's not dependent on petroleum. You have real estate expertise, you have expertise in small retail operations, you have expertise in dealing with guys in cars with credit cards, you know how to deal with government regulators (city planning commissions and building departments, weights & measures guys, etc.). You guys need to take your eyes away from the microscopes and see what you're driving toward.

You guys could be the heroes of the industry; what would it be like, do you suppose, to have Shell and Chevron and Texaco chasing your taillights? If you're really an executive, a decision maker rather than a mere "operator" (see Drucker's The Effective Executive if you don't know what I mean), then your job is to think about the future, and I don't mean next quarter's numbers.

Freedom to act (at work) -- whether you want to be a VP or not

About 30 years ago, I saw some fabulous presentations by William Oncken on the subject of "Managing Management Time." This was before I knew I didn't want to be a manager. But the videotapes had valuable information for anyone in organizational life. One such concept was that of the "Freedom scale."

You can find this scale online, for example on page 2 of this PDF or page 7 of this one. The scale looks something like this:

1. Wait until told.
   This means don't ask, don't even think.
2. Ask what to do.
   Don't suggest, don't recommend. Just ask.
3. Recommend, and act with permission
   That is, don't act without permission
4. Act and advise immediately.
   The boss hates surprises
5. Routine reporting only

Conflict arises when the boss and a subordinate have different ideas of what freedom the subordinate should be working at. This can happen because the boss doesn't communicate well; or maybe the boss is internally conflicted. The issue could be with the subordinate, too: if I'm a subordinate who's lazy or afraid to act, I'll tend to operate at level 1 or 2 whereas the boss may want me to operate at level 3 or 4 (or maybe I'm just accustomed to being told what to do all the time). If I tend to be rash and not to have good judgment, I may want to operate at level 4 or 5, but the boss may want me to act at level 2 or 3 instead.

Some of these things can be made better by communicating directly what level of freedom someone should be working at with regard to certain issues. Maybe it needs to be put in writing. On a sign in the employee's office/cubicle.

But when someone has to operate at a different level than they're accustomed to, that takes some adjustment. Someone accustomed to waiting (level 1) or asking (level 2) may have to make a recommendation (level 3). Or in case of an error in judgment, they may have to switch from "act and advise" (4) to "recommend then act with permission" (3).

And the boss may have some adjustments to deal with too, if for example a subordinate asks what to do and the boss wants recommendations rather than just problem statements. Of course, adjustments take work from everyone. I'm not sure who it's harder on.

But whether you're only a subordinate or you're both a subordinate and a boss, the freedom scale can provide a way to clarify expectations.

So you want to be a VP, part III

link to part II
Just read this terrific post summarizing a talk by Patty Azzarello on How to be Really Successful at Work AND Like Your Life. Two sentences from amazon.com's "About the author":

Patty Azzarello became the youngest general manager at Hewlett-Packard at age 33, ran a $1B software business at 35 and became a CEO at 38 (without turning into a self-centered, miserable, jerk). Whether leading massive business transformations or advising CEO’s 1-to-1, her insights, integrity, and generosity have fused with her work to create life-changing impact on the careers of thousands of people in large and small companies across the world.

All that's impressive, but I really liked her advice to DO BETTER, LOOK BETTER, CONNECT BETTER (details on the above post on compscigail's blog).

Patty has a short video on her home page introducing her (November 2010) book; amazon.com hosts an author page with links to her book, blog posts, etc.

This looks like great advice, particularly if you want to become a VP without ruining your life.

Workplace humor US-Japan

Back in the previous millennium, during our six-year stint in Japan, Mizuno-san and Kamei-san had accompanied me on a business trip to the US. As we sat in the company cafeteria, my old buddy Paul, who I worked with back in the 1980s, stopped by to say hi.

We shook hands, and I introduced him to my Japanese colleagues. "You work with Collin?" he asked them.

When they replied in the affirmative, he said, "And you're willing to admit it??" The Americans guffawed, but my colleagues were mystified.

Back in Japan some time later, I described this interchange to some other colleagues. Kubo-san, one of the best English speakers in our department, was surprised at this sort of joke. "It is an honor," he said. He meant an honor to work with me. He was completely serious.

Fast forward to the 21st century...

My current boss asked the other day what I was working on, "besides beating on Chris two or three times a day."

I replied in mock exasperation, "You said two or three times a week!"

The reply was immediate: "That was before you moved right across the hall from him! Slacker."

Overcoming NETMA (Nobody Ever Tells Me Anything)

I attended a great seminar by this title, probably around 1990. Unsurprisingly, I couldn't find my notes in 2004 (a six-year stay in Japan came between those dates). So I'm going to give you what I remember, jumbled and incomplete though it may be. Here's a story:

My mother mentioned in a letter that "by the way, our house burned down, so we're moving..."

Back when I was in college, long distance cost like dollars a minute, but I called them anyway. "Why didn't you tell me sooner?!" I said.

"We didn't want you to worry," they said. Oh, and "you couldn't do anything about it."

"Upset" wasn't an adequate word. A lot of the time, our instructor said, we don't give people a lot of information for the same two reasons.

They hate that.

First, they do worry. They often know something's going on, but when we don't tell them... well, nature abhors an information vacuum, so people make stuff up, and often it's worse than reality. This is true in families, and it's true in organizations.

Then, sometimes they can do something about it, even if it's just asking a question. To cite a fictional example, in Tom Clancy's Debt of Honor, a certain aircraft carrier sustained damage to two of its four propellor shafts. It'll be months before they can be fixed, and everybody assumes it'll therefore be months in dry-dock. Until someone says, "Sir, I hate to sound stupid, but how fast will she go on two shafts?" It's a lot easier to weld the gearbox shut than it is to restore the two shafts, of course, but somebody had to think of it first.

We aren't trying to keep people in the dark (it doesn't work anyway, contrary to the mushroom theory); we just don't want to weigh them down with too much stuff and distract them from what they need to be focusing on. So what are some practical steps?

Oh, by the way, the objective here isn't information for information's sake, but rather building a healthier, more effective organization.

A periodic meeting

I remember the story; unfortunately I don't remember why this was such a good idea. The story was this: A certain dentist had a staff meeting every morning, before the first patient arrived. They would review the day's schedule, including anything out of the ordinary; I think he brought doughnuts. I suppose that by getting everyone in sync, and telling everybody what everybody else was doing, this guy gave them a sense of being on the same team.

And if memory serves, the meeting wasn't all business, either; people mentioned things like vacation plans, so there was a sense of family. This made the office a more pleasant place to work -- and also to visit! Patients liked the atmosphere and apparently referred their friends, because this guy's business was booming.

A meeting, then a meeting

The boss in this story was in the state government, in Texas. She went to her department-head meeting, and as soon as she got back, gathered her people to tell them what happened. Of course, she only had to do this a few times before they started anticipating these post-meeting meetings.

What benefits came from this practice? I'll leave that as an exercise for the reader.

Give 'em the bad news right away

Suppose the Big Cheese lets fly that there will be layoffs -- 6% of the workforce. Should you tell your people what you know?

If you don't, then, well, see above. So how much do you tell them? Well, you don't want them to make up stuff that's worse! But you may be forbidden to say too much. H'm, sticky situation. But that's why they pay you the big bucks.

What's the worst thing...?

This might have come from some other seminar, but the idea here is to ask people what the most annoying thing is. Go ahead, man up and ask them!

It might be easy to fix, in which case wouldn't you feel silly leaving that opportunity not taken!

---

That's it for now; I'll update this if I remember more.

So you want to be a VP, Part II

Part I provides some background; in this posting I'll introduce some of my favorite work-related books.

1. Drucker (the prescient), The Effective Executive
   If another business-focused book has had a greater influence on my thinking about work, I don't know what it is. Know Thy Time, Focus on Contribution, Effective Decisions—brilliant.
   His Managing for Results is also interesting, albeit less applicable for someone in my position.
2. Cohen and Bradford, Influence Without Authority
   A great book on the "new" (1991) world of the flattened organization, and how to deal with the realities of being on the hook for results, without being given the corresponding organizational authority. Very practical. It includes some success stories as well as some not-quite-s.
3. Covey's 7 Habits of Highly Effective People
   A broader focus than just business. Worth a trip to the library. Don't take it too seriously, though; he tells you what to do in life, but it feels like legalism to me.
4. Goldratt, Critical Chain
   Great insights on scheduling, why projects are late, student syndrome, etc. I wrote about this in 2007.
5. Townsend, Up the Organization
   Entertaining and common-sensical, but more focused on the higher echelons of management.

These books have informed my thinking, more than giving me specific action steps.

Besides thinking differently, of course, one must also change actual behavior, doing things beyond the comfort zone, to grow professionally (or personally for that matter). This needn't be a long slog up the ladder; you really can decide that you don't want another promotion, if for example you'd rather write code than budgets (I resemble this remark).

So you want to be a VP... Part I

A young friend mentioned the other day that there's a pretty clear path to getting an engineering job: you get an engineering degree, you go to the career center and job fairs, you send out your resume, you go for interviews, and in a normal economy you can probably find work. But suppose you're working as an engineer and you want to become vice-president or head honcho of a company: what do you do?

By the way, I'm probably not the best person to ask about this, because I couldn't stand being even a first-level manager when I tried it in the early 1980s; if can't design, build, or debug something, then I won't last very long in a job. One of the few times I took an active role in my career was asking to be anti-promoted from management to individual contributor; being a vice-president or CxO sounds like about as much fun as a root canal without anaesthetic.

That said, I do have some thoughts on the subject, mostly about being a valued employee whatever your role is. And as much as I bad-mouth my management experience, I have to admit that it made me a better engineer, because it provided insights into what managers do and the kinds of challenges they face.

So let's start there: your manager. Unless you have an exceptionally bad one, then your success will be tied to hers (assuming for this post that your boss is female). It's hard to look good if she doesn't, and if your mission at work is to help her succeed, she'll do what she can to help you accomplish that mission. So try to understand your boss's world: what does she worry about? What is her vision for your department? What kind of skills do you need to develop in order to help make that vision into reality? And so on.

Along these lines, I happened onto this article on talentsmart.com, which described "Next-Generation Leaders"; it's definitely worth a read, and includes this summary table:

Next-Generation Leaders	Trophy Kids
Create meaningful work for themselves	Expect meaningful work to be given to them
Ask, "Is there anything else I can do?"	Say, "That's not really my job."
Constantly strive to do their best work	Constantly claim "I'm trying my best"
Try to solve problems on their own before asking for help	Ask for help at the first sign of an obstacle
Use self-deprecating humor to give everyone a laugh	Make sarcastic comments in attempts to be funny
Think about what other people want	Frame things in terms of "what I want..."
Have enough self-confidence to learn from other people	Talk down to other people
Eye long-term rewards for themselves	Expect a constant flow of immediate rewards
Pride themselves on results	Pride themselves on trying hard
Earn their success	Blame others for failures
Try to create real value	Try to earn praise
Adapt their language and appearance to fit the situation	Believe that their appearance defines them
Seek out feedback on their performance	Get defensive when critiqued

The left-hand column isn't just for future VPs, by the way, and the right-hand column is a good list of warning signs. You might want to look at that from time to time, and see which column honestly is a better description of what you're doing.

I mentioned good managers. If you find a good one, do what you can to stick with her. If you have a bad one, you may take measured steps toward a better one, but burn no bridges! You want to be VP, you'll have to work in an organization, which means you don't control who you work for. It's hard to succeed if your boss goes down in flames. And who knows -- your boss may learn something from you and become a better one! So don't undermine your boss; if you disagree, tell her so, respectfully, but when marching orders are given, you have to obey them until you find another boss. There are plenty of reasonable ones.

I really believe that last sentence, by the way. This may be old-fashioned, but I like to practice the principle of "abundance thinking." Abundance thinkers believe that there's no shortage of blessings, no shortage of success, no shortage of credit to go around. There's no shortage of reasonable managers or reasonable colleagues; there are lots of people around who are or could be excellent. The folks who run Disneyland are abundance thinkers; if you want to start up a theme park somewhere, they will show you how they did things, tell you what worked and didn't, and so on. Why would they do that, if you might be a competitor? Because they believe there are plenty of guests interested in theme parks, and if you try to duplicate what they have today, no worries; by the time you do that, they'll have innovated in other ways.

In contrast, "scarcity thinkers" behave as though life were a zero-sum game: the more credit you get, the less there is for me. Thi is not 100% false, but it's mostly false. The part that's true is that there's only one #1 slot in any rank-ordering of employees, but the part that's false is this: when you help other people, when you catch them doing great work and tell their boss about it, well, I'm saying this is a great habit to get into and absolutely will not hurt your career.

So I routinely tell our young employees to do that: if someone helps you out, send their manager a short email, especially near the time for annual reviews. This is good for everybody: you'll develop a reputation for generosity, your colleague's boss will have a nice piece of written evidence for ranking/evaluating your colleague, and of course your colleague will reap a bump in their manager's esteem.

Another thing I advise our young employees to do is to take notes at meetings. This will help forestall the otherwise-common confusion that follows when nobody records decisions. "What did we decide last time?" and "I thought you were going to do that?" and "When was that supposed to be done anyway?" -- all these can be answered by referring to the notes you took and circulated; if you email them out the same day, with a request for corrections/clarifications, you can help prevent wasting time at the next meeting, and everybody will love you. In Up the Organization, Townsend suggests keeping notes to one page and touts that as a means to becoming a Vice-President.

Which brings me to books: Townsend's book, though not technologically up to date, is still a great read, and an easy one. You should also read Drucker's The Effective Executive. It's worth having your own copy and re-reading it from time to time. And you don't have to be a Director or VP or even a manager to profit from reading it. Know thy time, focus on contribution, etc. -- those are important principles for any "knowledge worker" to follow.

Dave Packard's 11 simple rules is another great list;you can find them here and lots of other places. Here's the summary:

1. Think first of the other fellow.
2. Build up the other person's sense of importance.
3. Respect the other man's personality rights.
4. Give sincere appreciation.
5. Eliminate the negative.
6. Avoid openly trying to reform people.
7. Try to understand the other person.
8. Check first impressions.
9. Take care with the little details.
10. Develop genuine interest in people.
11. Keep it up. That's all — just keep it up!

Again, you don't have to be a VP or even a first-level manager to gain something by following these.

Finally, make sure that being a VP is something you really want to do -- that is, you want to do the work, not just to have the title. What do these guys do every day? What do they like about their jobs? What are the challenges and stresses they face? And what is their home life like? Try to get some time with a current VP and ask them.

And why isn't a VP's life for me? Because VPs don't get to do what I do. They don't write code, they don't talk much to new employees, they don't solve interesting technical problems. It just doesn't seem very interesting to me.

A patent apology (sic)

There are plenty of reasons to dislike software patents: they stifle creativity rather than enhance it, they're used by rich companies to reduce competition (think Mi¢ro$oft and FAT, Apple and the WIMP GUIs), and so on.

Given this situation, can an employee in today's tech industry ethically participate in his company's patent incentive program? On one hand, it feels like a bribe: "Are you sure you don't believe in software patents? Here's $500 just to tell us about an idea that might be patentable, with thou$and$ more if we file a patent and a few more thou$and$ if the patent office issues one."

That is one point of view, and it's certainly respectable and consistent. I don't happen to hold it, and I'll admit right here that I'm biased, having received incentive payments (or "bribes" for you purists). But here's how I see it.

As I understand it, the main reason my current employer applies for software patents is a defensive one. In this regard, it resembles the attitude of US and Soviet defense strategists during the Cold War days: neither side wanted to be the first to use nuclear weapons, but neither did either want to be the victim of a "first strike." Though a patent "war" obviously wouldn't have the devastating human consequences of a nuclear exchange, unpleasant (potentially disastrous) financial consequences would certainly hit one if not both sides.

How does this work? Suppose someone at a fictional company Moon MegaSystems (hereafter "Moon") casts about for a way to make some money and considers suing another company Relational Equipment ("RelEq") for patent infringement. Moon owns hundreds, maybe thousands of software patents, which under challenge may prove to be invalid. But it takes time and money to challenge Moon's patents, so a potential victim of a Moon patent lawsuit may decide to settle -- to just pay Moon off -- rather than spend millions in court costs. But if RelEq itself has hundreds or thousands of software patents, Moon will think three times before suing RelEq becuase of the real possibility of a counter-suit.

Suppose a RelEq employee is concerned (as he should be) about his employer's financial well-being, but doesn't believe in software patents. What good does he do by declining to participate in his employer's software patent incentive program? What if every RelEq employee behaved this way, and RelEq's (defensive) patent portfolio became smaller, relative to Moon's? This does nothing to overturn the software patent system, and only makes RelEq a more attractive lawsuit target for Moon.

If we could vote on the policies of the US Patent Office (I guess it's the "PTO" actually) then I'd vote to overturn all software patents and refuse to grant any new ones. But given the current reality, I'll continue participating in my employer's patent incentive program. It's actually part of my job.

Rolling averages considered harmful

Well, if not actually harmful, it's possible to be misled by them. Here's an example (yes I am making this up) that illustrates something kind of anomalous.

Suppose we're measuring, oh, new cases of the flu, or complaints about potholes in the street, something like this. Now consider the following figures taken over a 7-week period:

week	# of cases	change
week#1	20	(N/A)
week#2	30	+10
week#3	40	+10
week#4	50	+10
week#5	46	-4
week#6	42	-4
week#7	41	-1

That table tells the story that the number of flu cases (or whatever) got worse and peaked in week#4. In weeks 5,6,7 we saw the number of incoming cases decrease.

Now watch what happens if we ask for a 4-week rolling average to be reported weekly. The table below shows the average over the previous four weeks:

week	# cases	change	4-week rolling average	change
week#1	20	(N/A)	(N/A)	(N/A)
week#2	30	+10	(N/A)	(N/A)
week#3	40	+10	(N/A)	(N/A)
week#4	50	+10	35	(N/A)
week#5	46	-4	41.5	+6.5
week#6	42	-4	44.5	+3.0
week#7	41	-1	44.75	+0.25

Note that in weeks 5,6,7, the 4-week rolling average is still increasing, even though the number of new cases is headed downward. This sort of thing can cause executives to worry needlessly, but the bad part is that the short-attention-span crowd can then order wild-goose-chases. "You guys say the number of cases is down week-on-week, but our 4-week rolling average is still trending up! Somebody had better find out why!"

So if you're tasked with weekly reports of a 4-week rolling average, you might want to watch out for anomalies like this.

What do you do at the office?

Someone asked me, and I flatter myself that some other reader(s) might want to know too.

I work for (but don't speak for) NetApp, a great place to work. I started there in 2002, after getting laid off from HP along with 20,000 others in the wake of the Compaq thing. I kept my 2002 résumé for some reason.

My first NetApp assignment was on management software -- this was portable C (Solaris, Linux, and Windows) -- then I worked on replication (SnapMirror and SnapVault) for a few years. In 2005, I became part of a "quality team" within the Engineering organization (I told them a "mediocre team" might be a better fit, but they weren't buying), where I helped institutionalize static analysis tools. It's all very well to say "Thou shalt run lint frequently and study its pronouncements with care..." but when you have hundreds of programmers, thousands of files, millions of lines, and schedules to meet -- not to mention interruptions and other pressures of a commercial software organization -- integrating static analysis tools feels rather like adjusting the ignition timing while rolling down the freeway.

Since then I've worked on various other initiatives in engineering tools and our home-grown build system. It turns out that I now write more English prose than code. This is not a big problem, since I do get to code now and then, albeit more in Python and bash than in C or assembly. My current mission at the office is to make life better for development and QA engineers, whether by streamlining some process or making it easier to get at information that's otherwise hard to discover.

Sometimes I do some work on the product (troubleshooting mainly) in areas of logical replication that are not widely understood. Earlier this month I had an opportunity to meet with a customer to describe how we use our own technology in our build and release processes (the dog-food theory) to provide some great advantages to our developers and to the operations folks.

Also, for the past 18 months, I've shared an office with a young fellow right out of college. I've helped bring him up to speed, and I'm very happy and proud to be involved with his professional development. My boss told me a few months ago that I was an "awesome mentor" and that she's never seen a new college grad become a solid contributor in so short a time. (Is there anything in professional life better than that?)

So that's the summary. Any questions, please leave a comment here. Thanks for reading!

East Coast to West Coast Executive's Translation Guide

I found this in my archives, from the late 1980s. It's mostly (but not entirely) tongue in cheek.

East Coast to West Coast Executive's Translation Guide EAST COAST   WEST COAST Absolutely no Maybe Action item for Joe by 2/12 Joe's working on the problem Bozo Subcontractor Brawl Design Review Dictator Facilitator Do it and do it now Can you sign up for this program Do it right or you're fired I'm confident in you F--- off Trust me Follow the spec Is there a spec? Get out of my office Let's get a consensus on this one He's a jerk He's not signed up to our plan He's a subordinate He's a team player I'll cover your a-- Consider me your resource Ignore him he's new I'm bringing you up to speed Local bar Offsite facility Oh sh-- Thanks for bringing that to my attention Overdesigned Robust Punch his lights out Constructive confrontation Shut the f--- up Thank you for your input Shut up a minute Let me share this with you That's totally incompetent Let me build on that point Unemployed Consulting Overbudget On schedule Underbudget We haven't started yet We finished early <No translation> We're done How do you feel about that What's wrong with you I certainly understand your feelings Where is the spec? What is a spec? Where's the schedule What is the game plan Yes Maybe Your plan sucks Let me share my feelings on this plan

Best place to work? You bet!

True story about working at NetApp. Names changed arbitrarily. "Bob" was an intern with us last summer; he shared an office with me (still does). At the end of the summer, our boss, "Ingrid," told me we could hire a new college grad. Should Bob come on full-time after graduation (December)?

"Sure!" I said. He performed well during the summer -- not like a seasoned veteran, but like a promising young intern.

Ingrid made the offer and Bob accepted. He helped Ingrid out a number of times with reports and websites and such, while learning a whole bunch of stuff, including Python. He did some programming tasks that I really would never have gotten around to, and we were able to deliver a fuller set of services to the product developers. In particular, Bob came up with a cool way to provide a service the developers have wanted for quite a while, and put it into production last week. It's fast, too -- faster than the rest of us thought it could be.

Yesterday, June 1, one of the developers emailed Bob (I was cc'd). The new capability Bob coded up? It worked great!

Now for the fun part. NetApp's Vice Chairman, Tom, has an open offer out: "Catch someone doing something right," he said, "and tell me about it. I'll call that person and thank them." So I emailed Tom last night:

To: Vice Chairman Tom
Subject: Caught this guy doing something right!
Date: Mon Jun 1 19:19:59 PDT 2009

Hi Tom,

Bob is a young guy, been with us just over a year (the first 6 months as an intern, some of that being part-time). Our developers had been asking for the capability to (technical details elided) Though he's been with us this short time, he figured out a way to provide this capability, and as you can see from the below, a happy (internal) customer also expressed his appreciation.

btw "only took 2 minutes" is contrasted with "waiting a few hours after the nightly build" so this is a huge plus for our developers. If you're still making those phone calls, I'm sure it would mean a whole lot to him.

Bob's extension number is: XXXX

Thanks!

--- Original message ---
From: <Joe.Developer@netapp.com>
To: Bob
cc: <elided>
Subject: re: quick <elided> capability

It works really well. Only took 2 mins to check (technical details elided)....

Now we have a way to ensure the fix really works before checkin.
Thanks a lot, Bob

Joe

Mid-morning, the phone rang. Bob didn't recognize the number. It was local, though, so he picked it up. I overheard the conversation (Tom's voice carries, even on the phone).

Bob: Hello?

Tom: Hi, Bob? This is Tom M______. How ya doin'? (Bob looked quite surprised.)

Bob: Uh, fine.

Tom: Hey, I just got a message from Collin Park telling me that you provided a way for developers to (technical details elided)... Very cool. How long you been with us?

...etc...

The whole thing was maybe a minute or two, but Bob had this gigantic smile on his face afterwards.

A minute or two later, I got an email back from Tom. "Just spoke to Bob... thanks for bringing that to my attention."

You know, the only reason I would ever want to be a big-time manager or VP or anything would be so I could make phone calls like that. What a kick in the pants! I think Bob was smiling the rest of the day.

NetApp's not perfect; it is, however, a great place to work. How many other companies have a big-time executive willing to call a one-year employee on some random person's recommendation?

I love this company!

Renaming the wheel: a parable

In the last days of the Kingdom of Israel, before the ten northern tribes rebelled against the House of David (~930 BC), the whole assembly came before Rehoboam son of Solomon King of Israel to make a request. The key issues were around labor conditions, but recently discovered papyri document some heretofore unrecorded conversations with the cart-makers' guild.

"Your majesty," they said, "we have this innovation we call the axle; since last year we have improved efficiency with the wheel, but this combination of wheel and axle will bring glory to the kingdom and wealth to the royal treasury, and also be more environmentally friendly."

Rehoboam told them to come back in a few days. According to 1 Kings 12:5-7, he got some good advice from his father's former senior officials: "If you want them to serve and obey you, then you should do what they ask today. Tell them you will make their work easier." About the cart-makers guild, the advisors said: "That 'wheel and axle' thing looks way cool. If you offer them additional supplies from the royal machine shop, our wheeled-vehicle technology will be the envy of the region. About the terminology -- that's beneath your majesty's notice; let them call it what they want. Should not decisions be made at the lowest reasonable level in the organization?"

Tragically, Rehoboam rejected this good advice (1 Kings 12:8) and turned to some young hot-heads who told him to answer the people harshly.

Even worse, one architecture astronaut said, "Rather than 'wheel' and 'axle', your highness, I suggest that 'rod' and 'reel' would be more appropriate and bring more glory to your majesty, and they all begin with your majesty's initial. And besides, you're the king; you get to decide."

Three days later, the people returned, and Rehoboam answered them harshly (1 Kings 12:12-14). In an unrecorded further comment, Rehoboam also told the GM reps, uh, the cart-makers' guild, "You have to use the words 'rod and reel', not 'wheel and axle', or no more access to the royal machine shop."

"But your majesty!" they replied, "All our papyri use the words 'wheel' and 'axle'!"

Rehoboam was unmoved. "Forget all the innovation crap until you rework your documentation to use the new approved words, 'rod' and 'reel'. I'm king; I get to decide."

The results were unfortunate, as recorded in 1 Kings 12:15-19. The ten northern tribes separated from the tribes of Benjamin and Judah. They were never reunited. And after being beaten down, the cart-makers' guild gave up their wheeled-vehicle technology and went into the manufacture of cast idols instead. They never recovered either.

Do CEOs matter? Alas, sometimes they do.

"It took two CEOs nine years to wreck what 85 years of patient accumulation had built."

So ends the penultimate paragraph of Harris Collingwood's piece in the June 2009 Atlantic. He quotes Stanford’s Jeffrey Pfeffer: “Good leaders can make a small positive difference; bad leaders can make a huge negative difference.” (from a 2006 article in Fortune)

Another gem from that Fortune article: Who can fix GM? Maybe nobody could in 2006, but there were lots of folks who could accelerate GM's collapse. (Heck, I could have driven it into the ground for a lot less than whatever they paid the last CEO.)

Do senior pastors matter?

I mentioned "huge negative difference" to the lovely Carol, and she wondered out loud if that applied to senior pastors. Certainly an awful pastor can scatter a congregation, but can an excellent one make a big upside difference? I guess it depends whether the congregation is like GM in 2006 vs. Apple in the early 1980s, to take a couple of extreme cases.

I don't have anything else on this topic, but I thought the comparison between CEOs and senior pastors was a good one -- and are the elders like the board of directors? Then I hope the Holy Spirit is the chairman of the board.

Software quality can only be understood backward

NOTE: the following is entirely hypothetical and has nothing to do with my employer

How many defects (or "bugs," to use the common but incorrect term) remain undiscovered by the QA folks, when a release is shipped to customers?

Well, you don't know; you can't know, until the customers find them. You can take guesses: last time the QA folks found X defects; Y were fixed, and the customers found Z more. This time, the QA folks found X' defects; Y' were fixed... but how big is the number Z' that the customers will find this time? We increased QA's budget, we introduced fewer new features, etc., so we think that Z' will be less than what we might otherwise predict from X' and Y', but....

But we have to make a decision on when we think the release ought to be shipped to customers before we know how many defects they'll bump into.

Thus, following the comments of that software guru Kierkegaard, we are forced to conclude that software quality can only be understood backward, but it must be lived forward.

Frivolous Friday dialogue

Scene I. On the train.

C: G'morning, Jay, how are you doing?

J: (brief pause) About like you look.

C: ...?

Scene II. A few hours later. A meeting.

P: (to M.): Tell Ch_____ he did a great job.

J: Actually, he works for N_____.

M: But I hired him!

C: Whoa -- have I just entered a time-warp? Is it May already? (Reviews are supposed to be written in May.)

P: Gotta go... (exits)

M: C_____, this affinity thing you're working on -- how much is that going to reduce build-times?

J: Was it 30% or 50% you told me?

C: (has a laughing fit; recovers). That would be "No."

The rest of the conversation was a lot less interesting from a "silliness" point of view. BTW, the organizational structure is like this:

P
|
+--J
|  |
|  +--M
|  |  +--(engineers)
|  |
|  +--C
|  |
|  +--(other managers, engineers)
|
+--N
|  |
|  +--(engineers)
|
+--(other managers)

Interns

NetApp had a company party this afternoon, and for a while I shared a table with K., who I worked with some years ago at another company, and C., who was an intern last summer and now works for us full-time. C. went to San José State -- K. did too!

K. reminded me that I had helped hire her way back then. I won't tell you how old she is, but I remember a conversation we had one day in the cafeteria: We were talking about housing prices, and she said something like, "I think people around here have just accepted that it's OK to spend $250,000 on a house." I thought it was ridiculous to spend a quarter of a million dollars on a house, but obviously that conversation happened quite a while ago.

K. is now a "director" at NetApp -- not as in "Board of Directors", but like a high-level manager. She looks terrific, by the way; as far as I can tell, she could be 25 or 30, except I remember our conversation about housing prices.

This made me think about R., who was my intern in 1980. He's now a vice president at NetApp -- not technical at all! He seems happy about being a VP.

And I remembered S., someone else I helped hire at a former employer. He is a founder or chief technologist or something at a startup -- he's done one or two startups....

A few months ago I was saying that if all my interns became VPs, I'd wonder where I had gone wrong -- people work with me and they end up leaving technical work and doing management instead.

But really, I tell myself, it's probably not my fault. They probably actually wanted to be managers, directors, VPs, whatever.

So I guess it's OK; I'll be happy for them.

Will there be layoffs? Let's try this first!

OK, this is absolutely not the view of my employer, my employer is not contemplating layoffs, but let's be realistic, nobody knows what the future holds, right?

So if things get so bad that a company is considering layoffs, here is an alternative I heard several years ago from an old boss. You've heard of the graduated income tax? This is the graduated income cut. The idea is that some people in the company make a ton of money (as one CEO said, "They pay me more than I know what to do with") and others make a lot less. The CEO-class of annual income could tolerate quite a large pay cut with a little inconvenience, whereas for the latter, even a 5% cut could be quite painful.

So, instead of doing a 10% pay cut across the board (as was sometimes done at HP), what if we said

• At $250,000 or more annual income, you can tolerate a 20% pay cut without any real "pain."
• At $50,000 or less, we probably don't want to cut your pay at all.
• For ranges in between, we'll cut your pay by an amount that varies linearly with your annual income in excess of $50,000

Let me give some examples:

• $50,000 and below: 0% pay cut
• $51,000: 0.1% pay cut
• $52,000: 0.2% pay cut
  ...and so on...
• $60,000: 1% pay cut
• $70,000: 2% pay cut
• $80,000: 3% pay cut
  ...and so on...
• $100,000: 5% pay cut
  ...
• $150,000: 10% pay cut
• $200,000: 15% pay cut
• $240,000: 19% pay cut
• $249,000: 19.9% pay cut
• $250,000 and up: 20% pay cut

Call me a socialist, but I think the 5% lost by the $100,000 guy will hurt him or her more than the 20% lost by the $250,000 guy.

Now if you're in an industry or a part of the country where $50,000 is a ton of money, well, you can slide the figures around to where they make sense. But this is just a Dumb Idea™ anyway with no traction I've ever heard of -- except at one, ah, exceptional company.

The algebra for the above is like this. Let

A = current annual income
N = proposed new annual income under this graduated pay cut scheme.

Then:

• N=A if A≤$50,000
• N=0.8A if A≥$250,000
• N=A(1 - (A-50000)/1000000) otherwise.

There's probably a generalized formula if one wants to have a linear increase in the pay-cut from 0 at annual income A₀ to P_max at annual income A₁, but it's now time for me to drill holes in the walls so we can hang aprons up on them.

The sound of one Schedule-Chicken clucking

Schedule chicken! If you haven't heard of it, it goes like this:

1. BOSS: OK, we have system test coming up next Tuesday.
2. MGR1 (sweating): We're on track for Tuesday (thinking: if a miracle happens).
3. MGR2 (avoiding eye contact): 90% complete; we'll be done next week.
4. MGR3 (to MGR2): But my guys tell me the API isn't even checked in yet! You were supposed to have that 2 weeks ago! With just a week to go, it's not possible...
5. BOSS (looking around): So when can we enter system test?
6. MGR3: Two weeks after his (indicating MGR2) APIs pass unit test.
7. MGR1 (silently): (Whew! I have 2 more weeks now!)
8. BOSS (to MGR2): So you'll be ready next Tuesday, right?
9. MGR2: Thursday
10. BOSS: But you said you'd be ready for system test next Tuesday, which was the system test deadline
11. MGR2: I said "next week".
12. BOSS (to himself): How can I get these guys to quit lying?

How indeed? Let me start by saying that the answer is not for BOSS to stand up and yell, "Will you clowns quit lying?" or threaten to fire the next poor fool he catches doing it. Unfortunately, BOSS (and the system he uses) are a major parts of the problem, because his subordinates have a perverse incentive to play the Schedule Chicken game.

Before we can figure out how to get rid of it, we have to start with "where did this come from?" Here are a few observations.

• #1: How did BOSS (or whoever) decide the system-test date? Why are we talking about dates in the first place? In other words, one issue is the whole focus on "meeting" a milestone.
• #2, #3: MGR1, MGR2 make completely unverifiable (and unfalsifiable) statements! Note that BOSS doesn't challenge them. Information about who's really not finished won't surface 'til system test actually starts -- or when it doesn't.
• #4: This is the first objectively true or false sentence that's been uttered. These accursed milestone meetings are filled with lies, but hardly anything falsifiable.
• #4 again: Why are we only talking now about something that's 2 weeks late? Shouldn't this conversation have happened 2 weeks ago?
• #7: Why does MGR1 think he has more time just because MGR2 is late? Why has BOSS trained him to think so?
• #8-#11 Deliberate deception! Probably driven by an overly competitive atmosphere
• #12: I'm going to say that all this lying is strongly encouraged by the environment. The focus on when (mistake #1) something will be ready (mistake #2) is a source of all kinds of trouble.

It's true that BOSS has to be concerned about the when question, but why do we pay BOSS the big bucks? Because his job includes this onerous task:

• translate what I need to know into terms that will produce the desired behavior in MGR{1,2,3}.

It's also true that BOSS has to predict the future. But we pay him to predict the future, and not just by rolling up unverifiable (and unfalsifiable) predictions from MGR{1,2,3}. Where's the value-add in that? No, what BOSS should be doing is getting factual data about the past and present from his subordinates. Things like:

• Have the unit test specs been reviewed and approved by <insert Test Spec Reviewer's name here>?
• What % of the unit tests have been run?
• What % of the unit tests have passed?
• How many staff-weeks (or staff-months) have been spent out of your budget for this task?
• How much of the overflow buffer (or "contingency account") has been spent?

That last one takes some explaining.

We're all optimists, aren't we? That's why our estimates are always too low. "Sure, two weeks," we say, but that assumes things go as planned. Really now, how often does that happen?

If BOSS pads the schedule, then workers will do the "student syndrome" (wikipedia) thing and not start 'til 2 weeks before it's due. And things don't go as planned, and even the padded schedule is missed.

How do you fix that? The key insight is in item #5 on this post: by tracking other things than what you track now:

• effort estimated (budget)
• effort expended (out of budget) -- not % but actuals
• how much is left in the "contingency account" or "buffer"

Of course there's more than that required to fix the Schedule Chicken game. But it's a great start.

Not "How close to 'done' are you?" (answer: 90%! Always!)

But "What % of your unit tests have been run? Passed? How much (not what %) of your budget is used? How much is left? How much is left in the contingency bank?" Track all of those. That's where you add your value.

And that's also why there's not enough money in the world to get me to do that job.

And by the way

Rothman's article on student syndrome (which came up in a google search while I was writing this) is brilliant. Her consulting group's homepage is here but don't hire them unless you're prepared to do what they tell you.

Open letter to a Stanford computer science undergraduate

Dear C_______,

Although I was representing my employer when met you at a recent career event, what I'm about to write here is not a statement of my employer or of anyone else.

The short version of what I want to say here is:

1. Your resumé is very impressive.
2. Your resumé tends to make me feel worried about you.

On #1, I don't guess you needed me to tell you that. I mean really, your accomplishments, both technical and in promoting women's participation in STEM, are exceptional. I would love to have you work with us next summer if we could find something that interests you; we have a lot of problems to work on, and we have a lot of freedom in the intern program to let you work on them. But there are also many other companies who would love to have someone like you work for them. Some of those companies are household names, so I consider that we would be very lucky to be able to snag you. So provided that the economy doesn't go completely down the tubes, you'll be in high demand. Including by us.

On #2, and this politically incorrect part really isn't a statement of my employer.... Maybe it's because I have daughters rather than sons, but when I look at your resumé, this is what I worry about: I hope you get enough exercise and sleep and fresh air, that you find time to do volunteer work, that you get out dancing or to concerts, that you read novels or poetry and take time to relax and reflect... that you find enjoyment in life outside of math and science. I did not do much of that at Stanford; I was in a big rush, which is a sort of theme of my life.

Apropos of nothing: My daughters are about your age, and I'm just as proud of them as your parents are of you. When I think of why I'm so proud of them, their schoolwork isn't at the top of my list. Of course my heart overflows with affection whenever I think of them, so I'm not really objective. But I think of their compassion, their joy in life, their love for God, their courage and maturity and generosity -- and that is what busts my buttons. Now it doesn't hurt that their verbal SATs beat mine, that they have better grades than I ever got, or that their teachers love them. But that's secondary.

Well, all that was really incorrect politically -- again, not a statement of my employer! -- and I hope I haven't offended you. But I certainly hope that you take better advantage of Stanford than I did -- that you take classes in areas outside math and CS and engineering, and I don't mean Philosophy 161. And that you "waste" time with friends and think and talk about where you're going in life. I hope you get a few Bs and maybe even a C (okay, a B-minus if a "C" is unimaginable) or two because you've taken the time to be with a friend rather than cram for the endless sequence of exams.

Because there's so much more to life than math and computers and engineering. I hope you don't make the mistakes I did, is what I'm saying.

Best regards,


PS: whether you come to work for my employer or not, here are a few things you might enjoy reading. Maybe in a few years?

• school-to-industry transition
• why projects are late
• other ramblings about life at work