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

A mentoring experience

About a year ago, I was introduced by email to a young fellow I'll call Pankaj, and we had lunch together for the first time yesterday. We had a great time. Here's how it happened.

I had signed up with MentorNet as an available mentor for a student or someone starting out in my field. This is a high-tech and focused version of what we used to call "penpals." The idea is that prospective mentors and mentees sign up and give their preferences: want a male or female counterpart^*, how close a match to their current field of work/study they want, etc. Then, like a dating service or something, they match you up and encourage you to email each other regularly (weekly or biweekly).

^*"counterpart" isn't quite right; neither is "partner", but the idea is "your mentor or protégé." (the mentornet folk use "protégé.") The Japanese word 「相手」 is what I want, but I'm not sure what the right English word is.

So I was introduced to "Pankaj" and we exchanged emails from time to time.

But MentorNet don't just leave you; they send reminders, suggested discussion topics, etc. Sometimes I used the MentorNet reminders as a starting point for discussions. Once, when I had sent emails a few days or weeks apart without getting a reply, the MentorNet reminder said that students often felt overwhelmed with their studies, with their part-time jobs if they had any, etc., so don't be discouraged if they don't always write back right away, and don't give up on them. That one was well-timed.

Sometimes Pankaj would ask me about something and I would send him a pointer to one of my blog posts. Occasionally I'd write a new blog post based on something he asked. But most of the time I tried to give him sage advice (yeah right) about careers and life. And somewhat inspired by 1 Thessalonians 2:8, I talked about life outside of "business" -- family, vacations, church, etc. And when he wrote about his travel (back to his home country), his family, etc., I responded as I'd want someone to respond to my daughter living on the other side of the continent. And I tried to imagine how his parents must feel with their son half-way around the world.

As it turns out, I didn't really have much sage advice for him. He asked me how to select a topic for a research paper, and I didn't know. He asked how to avoid getting "pigeonholed," and I didn't know that either. But I told him what I did know, and how I would think about these things.

So at the end of our designated 8-month period, when the MentorNet folks asked me how I felt about the experience, I wasn't sure. Sometimes my emails would go unanswered, sometimes I had no clue how to answer his questions, and overall I wasn't sure how useful I was to him.

Then Pankaj asked to get together in person, which I immediately agreed to.

So yesterday it happened. He came to the NetApp office and we had lunch on the patio. At one point, he paused to thank me for being involved with him, being his mentor. I mean he was effusive! He said my emails were always so encouraging (and I'm thinking, What did I say? ), that I kept emailing him even when he didn't reply for a while (I never gave up on him), etc. And, he said, he was especially happy that I didn't email him only about classes and careers, but also told him about my family, and that I responded from my heart when he wrote to me about his.

Wow, I thought, those things never occurred to me as being unusual.

What really made me feel excited was his comment that because of his interactions with me, he was now volunteering to teach a computer class -- at a community center or something. "I felt like I was busy," he said, "but I'm sure you're a lot busier than I am. And yet you took time to encourage me and give me your advice..." And so he felt that he could take time to give something to others. "I don't have the experience to be a mentor to somebody," he said, "but I have skills with computers..." and so he gives back to the community. How cool is that?

I told him that was a great thing to do, and a great habit to get into. It reminded me of the habit of giving, so I hijacked the conversation briefly to tell him about the church we attend, where there are a lot of rich people. I mean, our household income is below average there! And on the subject of giving money, this is also an area where people need to get in the habit early. They don't necessarily have to do all their giving to the church, I said, but they should give to disaster relief, helping the poor, development, to something anyway. And if they can't give $3,000 on a $30,000 income, well, it's harder to give $20,000 on a $200,000 income because it's so much more money (or whatever their target giving % is). But I finished that digression by telling him how glad I was that he was in the habit of giving his time.

During our conversation, it came out that he'd agreed in the spring to take a certain summer internship, even though that company doesn't hire its interns as permanent employees. After committing to that internship, he got internship offers at other companies--companies that might have converted his internship into an offer of permanent employment. He turned them down because he'd already given his word to the first company, even though he really wants to find "permanent" or regular employment here.

I applauded him for keeping his word, because so many people these days don't.

We talked about what it takes to find a position with a good company, and I told him that a lot of it is being in the right place at the right time and knowing the right people. I mentioned someone in our office who came in as an intern and is now on track to be a regular employee once he graduates. This ex-intern got in basically because his resume was in the pool and happened to fit what we wanted in an intern; he showed that he could do what we expect a new college hire to do. I also summarized part of the story of how I got hired at NetApp.

Of course, I said, it's important to do what we can -- study hard, search diligently, live wisely -- but those things improve our chances; they don't guarantee success. You can graduate at the top of your class, get a great offer from a terrific outfit, and be hit by a truck on your way to work.

He asked about my kids, and I told him how they are enjoying their current adventures. He said I was a successful parent, and I said a lot of that is out of our control too. We read bedtime stories to our kids when they were younger, we read the Bible to them when they got older, of course we prayed for our kids... but a lot of people do those things and have big troubles. So, as one of our teachers at church told us, we cannot raise Christian children; we can only be Christian parents, I told him. (I also translated this for him into "raise moral children... be moral parents.")

In fact, I told him, everything that really matters in life -- everything -- is out of our control. We can study and work and pray, but we can't make someone give us a job offer. We can read to our kids, pray for them, go to all their games, help them with their homework, etc., but we can't make them turn out the way we'd like.

We walked around the building a bit, I showed him some of our products, and let him have a look at my office -- he saw some family photos and some of the kids' artwork. We also talked about the kind of work we're doing at NetApp; there are lots of significant problems to address that lie outside of the filesystem itself.

I certainly plan to stay in touch with "Pankaj" in the future, but probably not as frequently. And I am going to point my browser at mentornet right now and sign up for another "protégé" for the coming academic year.

Giving customers what they really want

How do we find out what customers (or "clients" or "users" if you prefer) really want? This actually is a trick question, because the answer isn't "ask them what they want." I have two answers. The first is what I call the "laminating machine" story, which I heard some years decades ago, in a class called "Building Market-Focused Organizations." (Note: I'm making up some numbers here)

This consultant was working for a manufacturer of particle-board. The manufacturer was visiting one of his customers, a furniture maker.

The furniture-maker said his problem was that everything cost too much. The only thing he wanted the particle-board guy to do was lower his prices!

Then the consultant said, "What's that machine over there?"

Furniture guy: That's a laminating machine. We put 2-3 sheets of particle board and glue 'em together.

Consultant: why do you do that?

F: Because we need particle board 1¾" thick. Of course you can't buy board that thick, so we glue 2 sheets together under pressure, and heat, etc...

C: (to particle-board guy) Could you make particle board 1¾" thick?

Particle-board guy: Yes we can!

F: Whoa, could you really do that? I could save a lot of money...

The furniture guy never thought of "gotta laminate" as a problem. The particle-board guy asked what kind of problems they were facing, and the furniture guy would not have come up with "your board is too thin!" for a long, long time.

Of course the particle-board guy wouldn't have come up with "Offer them thicker particle board!" for a long time either. The rest of the story is that the particle-board vendor continued to work with the furniture guy to better understand how they could help his business. They captured this client for a long time; other particle-board guys could offer only lower prices, but this vendor knew the problems the furniture guy faced and able to offer things the other vendors couldn't even imagine.

How do we get people to look past what the customers complain about? How do we get them to figure out what the customers are trying to deliver to THEIR customers, and then figure out how to help them do that?

That's the $64,000 question. Or the $64×10⁶ question as the case may be.

And the second answer?

The other thing that comes to mind is the Kano model of quality. Wikipedia's article is, surprisingly, not all that useful. This paper provides some examples ← No it doesn't; as of 2008-10-17 it's a 404. Hence...

Refer to the figure from the wikipedia article and let's talk cars for this example.

Let me describe a "basic" attribute: the car has doors that close securely. This is basic because if the doors don't work, you'll hate the car -- end of story. If the doors work perfectly, that gives a total "ho hum" kind of response, right? You expect the doors to work already! If the salesman talks about how well the doors close, you're gonna think he's got rocks in his head, right?

For "performance" attributes, one could imagine fuel economy, ease of handling, and a quiet ride for 3 examples. If someone offers a car that gets 300 miles per gallon, goes exactly where you want, and lets you drive on bumpy roads while being able to hear your wife whispering to you, those are all good things, correct? You'd be more interested in a car that did all that stuff, but a car with less of those could still be considered -- just not as avidly.

For "delight", imagine a car that could fly and also go underwater. Does the lack of such qualities concern you? No -- you never thought of them? But if it could do just one of those -- that would get your interest, would it not?

That's the basic(sic) idea anyway.

Earning the right to be heard: showing that I've heard you

In a brilliant posting last month, a founder of our company describes how to get support for a plan that isn't perfect: admit its flaws!

This is a brilliant strategy, not only in the office, but also at home, because it shows that I've heard and internalized your concerns. That earns me the right to be heard -- it's a big part of the solution anyway.

Culture, schmulture (part deux)A thinly disguised conversation

The other day I had an interesting conversation with someone from Bangalore. When I described it to the lovely Carol (along with my comments on the cross-cultural aspects), she suggested I write it up. The names have been changed so as to make it not too obvious... especially since I'm sure I got the order and some details wrong.

I showed most of the below to "Mahesh" (he's still here in Sunnyvale) and told him my idea of using it to illustrate cross-cultural communications, and he was OK with it. He asked me again if I had any plans to visit Bangalore.

For your reading pleasure, then, here is...

The thinly disguised conversation

Bill was trying to code a lookahead regex in Perl when he heard a knock on his office door. It was Mahesh, who he met yesterday. Mahesh manages the team in Bangalore, and was visiting headquarters in Sunnyvale for the first time.

Bill turned his chair around to face the door. "Come in, come in!" he said.

"I wanted to drop this by." Mahesh produced a small paper bag, which Bill accepted. Opening it, he saw it was a very thin vase, wrapped in cellophane. He tried to stand it up on his table.

Mahesh encouraged him to take the cellophane off, then explained that the vase was made of gunmetal. The pattern was engraved and covered in silver. "Very pretty," Bill said.

"If you come to Bangalore, you will see many shops, including this one." Mahesh indicated the store's name on the paper bag.

I wonder what else he had in mind, Bill thought.

After a moment, Mahesh sat down in the big armchair and suddenly looked abashed. "I hope I didn't offend you by sitting here when you didn't..."

Idiot! Why didn't you offer him a seat? Bill mentally kicked himself. "No, no, no," he said. But now what? Mahesh wasn't the usual fast-paced conversationalist.

After a moment, Bill asked, "How long will you be in Sunnyvale?"

"Just this week," said Mahesh.

"And what are your objectives for this visit?"

"To meet people. To attend the meetings that this part of the team has." He smiled and made an open gesture with his hands. "That's all."

Taking that at face value, Bill tried, "How long have you been with the company?"

Six months. Bill and Mahesh had both worked at HP before, and so they were able to compare their impressions of their current company in light of their former employer.

Bill cast about for something else. "How do you feel about the collaboration between Bangalore and Sunnyvale?"

A brief pause. Mahesh smiled again (somewhat awkwardly, Bill thought). "Pretty OK. Well, we have a young team, not much experience -- neither here in the company nor elsewhere. I was hoping to set up a meeting with you, once every 15 days or so. It would be a phone conference -- you could do it from home -- and you could get to know what we are working on, get to know the team, and so on. Maybe you could mentor some of them. Does that sound all right?"

"Perfect," Bill replied. Does he mean every three weeks (15 working days) or twice a month (15 calendar days)? he wondered. Those details can wait, though; I'd say "yes" either way. Arrgh -- I forgot I have to set something up like that myself -- for next week, when Pete is out here.

"What time would work for you?" Mahesh asked.

The time difference could hardly be worse: 11½ hours, or maybe 12½. People in Bangalore usually come to the office "late" in the morning and stay late in the evening.

"How about 6:30 AM my time?" Bill tried. "Would that work?" Is that 7pm in Bangalore, he wondered, or is it 6pm now that we're on daylight savings?

Mahesh looked surprised. "Isn't that too early for you?"

"Well, I'm usually up by about six anyway," said Bill. "And if it was going to be evening here, it would have to be quite late." Later than I probably want to be awake, he thought.

"You know, offering to have a phone conference with the team at 6:30AM your time is no joke; they will really appreciate that," Mahesh said.

"Well, anyway, if it was like 6:30 then we could talk maybe half an hour and I could still ride my bicycle over to the train station," Bill explained.

The conversation then switched to less work-related things: where Bill lived, commuting, each man's children, etc.

Bill thought of something else. "Is there anything else we could do at this end to improve collaboration? Offer to help or something like this?"

Mahesh talked about the need to build some sort of wrapper first.

Bill nodded, while frnatically thinking, what kind of wrapper? He was usually pretty good with accents, but it took him a while to figure out that the word was "rapport." He turned his attention back to Mahesh.

"Unless the rapport is built," he was saying, "then offers of help could be misunderstood."

Drat it, Bill thought. I've blown that more than once, then.

"But once that rapport is there," Mahesh continued, "then we could get the kind of mentoring my team needs. There are tremendous mentoring resources available here in Sunnyvale and it would be a waste not to use them."

"Right," Bill said.

"After one or two meetings," Mahesh said, "some of the guys might send you email, 1-on-1, or maybe call you in your office in regular hours."

"Perfect." Bill was pretty sure that this was what Mahesh had wanted to talk about.

After a while, Mahesh thanked Bill for his time, and left.

Bill reflected on the conversation afterwards. That was pretty important, he thought. We both learned something, and built bridges.

How did Bill do?

Here's what I came up with:

1. Though he was working on a technical task, he took time with his visitor.
   
2. He acknowledged the gift verbally and appreciated it.
   
3. When he saw Mahesh standing there, he probably should have offered him a seat!
   
4. At least he figured out that Mahesh wanted something. Could he have asked him about it more directly? Probably not. ("What do you want from me?" probably isn't quite what you want to say. "Can I help you?" may have the problem of offering help before rapport is established.)
   
5. The collaboration question was probably a good one. I also give Bill points for not asking too many questions right away. (Americans often ask too many questions, though in this case "Did you mean every two weeks?" would probably have been OK.)
   
6. When Bill didn't understand "rapport," he probably could have interrupted Mahesh immediately and asked him what he meant. I don't fault Bill too much here, though; his style seems to work for him
   
7. Bill never did get around to finding out whether Mahesh meant every 2 weeks vs. every 3 weeks, but I don't fault him too much for that, either; the two of them can figure that out later.

school→industry transition

A few weeks ago, actually a couple of months ago, Laurie put the arm on me to teach "new college grads" who are becoming new employees at the office. I was to teach them about our development tools and workflow, but rather than cramming a ton of how-to stuff into their already-full heads (my part is coming about ¾ of the way through their indoctrination), I decided to start with introductions and so on.

The "school to industry transition" came to mind as a topic that might be useful to them, and nobody else was addressing it, so I came up with "the four Cs" -- a different set than you've probably heard before. Here they are:

Collaboration

When I interviewed at HP, now over 3 decades back, Peter asked me what I'd do when faced with a task I couldn't figure out. I had no clue, so I suggested I'd go back to my manager and tell him it didn't look feasible. Well, he didn't call me a moron, but he did correct me. "Ask your colleagues for help!"

D'oh! In school I thought mostly in terms of independent work. One of my profs actually said that "there is only one acceptable way to do homework: alone."

In school, we're often in competition with each other. There are only so many "A"s to be given out, right? This is less of an issue with group projects, but even a team-written research paper has only one primary author.

It's true that some companies rank their employees against each other. This is rather a nasty deal and can't be helped, but I hope you work in a company that rewards team players over prima donnas.

Because at least in most technological organizations, one person alone can hardly accomplish anything! No one person understands the entire operating system, or these days even the kernel. (Linus Torvalds himself doesn't know everything about Linux.) So we have to work together... which brings me to:

Contribution

There are some things that only you can do to help your team, some other colleague, or the company. That would be a unique contribution and perhaps you should do it!

Then there are things that nobody else will do, even though they could:

• Take minutes at meetings!
  People seem happy to let you do this. When you send notes out, people can refer to them later and don't have to rely upon their memory. Along those lines,
• Be kind to future generations in your prose (and your code)
  So when you take minutes at a meeting, write them in a way that will be convenient to refer to later on. The headache you save may be your own! Put "action items" at the very top or very bottom, or maybe set them off like this:
  
  ==>Joe: verify marketing has seen the design spec by next Tuesday
  
  That makes them easy to see...

  Analogous comments could be made about code (if you write code), even if they're just short scripts.

• When you like something, tell them!
  If Joe or Jane does something you like, something nontrivial I mean, send 'em a short email saying basically "thanks for your help on X; that will speed up the next phase of design" (or whatever). Use "bcc:" to let their manager know, too. Or send their boss a separate note. These are always appreciated, especially when their boss has to write their review!
• My current employer has a "wiki" that's full of info on how to do various needful things, and anyone (inside the company of course) can edit it. If you have one, and find something in there that's wrong, fix it! Your employer may require reviews or something, and there may be guidelines for how much time you spend on that kind of stuff. Follow all those. But every question you answer (assuming that your answer is in a section of the wiki that people will look early on) will save people however much time you spent figuring it out. (Yes, I assume you're "average"; if you're faster than average, your answer will save others more time than you spent figuring it out!)

Completion

Ph.D students don't generally suffer from this malady, but undergraduates will sometimes say, "Bah, it's good enough; I'll just turn it in like this and take a lower grade on this one" -- because their other assignments give them enough points to get their desired grade, or they already have an admission for grad school or a job offer, or whatever.

If code is inadequately thought through or inadequately tested, there may be a phone call from the customer to your CEO. Test now or escalations later!

The other thing, though, is this: "completed" is defined by the customer. Reliability may be very important, but every whiz-bang feature you want to put in? Maybe not.

CSFs (Critical Success Factors)

Sorry for the jargon, but basically this means: What does it take?

What it takes, in a word, is character: Not "laziness, hubris, impatience" -- at least that's not the usual list. Instead, things like

• conflict resolution and cooperation
• being conscientious (not contentious); very often haste→waste, if not in technology then in interpersonal relationships
• self-control and work/life balance. You can cram for a final and you can push hard for a short while, but you can't do that for thirty years. Believe it or not, someday you'll be as old as I am and you won't be able to do that.
  
  And when you have a family and children, you really shouldn't be doing that. Don't let your job cost your marriage or your relationship with the kids; it's not worth that!
• Humility -- a willingness to learn and take feedback. How many people, when you give them a suggestion, tell you why they thought what they did was OK? They might want to learn, but they care more about thinking themselves right.
  
  Don't be like them! Instead, copy Einstein, who supposedly said that he'd rather know whether he was right than that that he was right about something.

Conclusion

That's my list; if you're starting a job right out of college, I hope it's useful to you. Given average talent but above-average pursuit of those four things, you'll beat out the "genius" who can't work with others most of the time. You'll be a superstar.

postscript: a book recommendation

Drucker's The Effective Executive (amazon.com link) which may have influenced my work world as much as any other book

We all do it, so don't punish them

The other day, Jack dropped by and we chatted about code quality tools. I mentioned CP-Miner (more), and its ability to detect when programmers introduce errors by copying code from one place, pasting it in another, then incompletely or inconsistently changing variable [etc] names in the destination copy. He thought about it a second and said off-handedly that since we all do it, there is no point in punishing people who do. But we do have to catch such errors and remove them, for the sake of our customers, employees, and shareholders.

I thought this a very important principle -- if everybody makes this sort of mistake, then it's not an exceptional thing; you don't have to be a worse-than-average performer to do it. This reminds me of Deming's “red beads” demo, which is astonishing both because the process is so idiotic, and also because some companies actually do this sort of thing.

Something to keep in mind in the drive for software quality.

Why are projects late? And how to fix that.

I used to work with this very interesting fellow -- I'll call him "Roger" ('cause that's his name) -- who had some great ideas about project management. After some investigation and some brilliant insights, he shrank software development schedules without cutting quality or features, and without spending more money or getting people to work longer hours. He did this both in a large company (HP) and in small startups in the ’90s. For some years, I nagged him to write a book about it, but never succeeded in persuading him to do so.

Fast forward to 2007. I'm talking with Lissa, who I think also knew Roger at HP, and she mentions one of these ideas. "Brilliant!" I say. "Did you learn that from Roger, or did you come up with it yourself?"

Neither -- she got it from Goldratt's Critical Chain. Whoa, was this the book Roger was supposed to write? I ordered it from amazon.com and found out: He doesn't have everything Roger came up with, but he's got a lot. I think every manager and every director in Engineering ought to read this book (and probably more by this guy), but let me outline why projects are late and some things you can do about it. Page numbers below are taken from Goldratt's book, in the above edition.

1. They shouldn't be late!
   
   • People put safety factors in their estimates
     (NOTE: given the typical distribution for completion times, P(success) of 80% implies the estimate is 3x the median, i.e., padded 200% -- pp. 43-46)
     
   • Managers take the padded estimates and add their own padding
   Hence we have safety and more safety, but projects are still late!
   
   
2. In a sequence of steps... (pp. 121-122)
   
   • delays from one step are passed on in full to the next one;
     
   • worse, the longest delay from all steps is passed on to the next (dependent) step;
     
   • advances ("We finished early!") in one step generally do not result in an early start on the next step
   Roger reminds me that Dan used to call this the "idiot shift right" -- slide the schedule to the right and the past is forgotten.
   
   
3. People don't start on a task until they think they have to (the so-called "student syndrome", p. 124); since estimates are all padded, they don't even start when they say they will.
   

   Two other factors cause later starts in the general case: one is the desire to postpone investment (present value of money, pp. 68-69) and another is the desire to limit the number of irons currently in the fire -- in other words, management focus is a scarce resource (p. 70)

4. In some situations, critical resources are forced to multitask based on conflicting priorities; this can easily double lead-time on all paths (p. 126)
   
   
5. The key step in fixing this is to make "safety" explicit and visible. Goldratt calls it the "buffer" (pp. 153-155). Roger called it "contingency" or "contingency account". Any of these phrases can work, but the idea is that when your step takes more time than you thought, that eats into the buffer/contingency.
   
   
   • You track the current "balance" in the contingency account, or the amount left in the "buffer", and that will tell you how well things are going. (p. 163). Do not track due dates, or that will trigger the student syndrome!
     

     Also -- don't track percentage of resources/time used versus projected; that makes it look like you're on time even when you aren't (p. 73), and will tend to optimize the wrong management behavior (pp. 73-74).

   • Goldratt has the "project buffer" only on the critical path; he creates "feeding buffers" at the places where noncritical paths join the critical path (p. 158), "resource buffers" (which I'm too dense to understand, p. 160), and the eponymous "critical chain" (pp. 213-219), etc. According to Goldratt's paradigm, it is very important to keep track of which path/chain really is critical so that you can subordinate (pp. 159-160) noncritical paths to the critical path and thus reduce multi-tasking (which is evil, p. 126)
     
     
   • In contrast, Roger made a PERT chart and then locked it away somewhere. Instead of trying to figure out when the critical path is late, he wants to know when any task takes longer than estimated. This is far less complex than Goldratt's schema, and also takes into account a reality that Goldratt ignores: that dependencies aren't really "hard."
     

     Roger used to say, "If you really can't make any progress on anything because you're waiting on someone else, take some time off. And no need to report it to HR -- it's on me." Because if you think a little, you almost always can find something to do that will move the project ahead. And no one has ever taken him up on his offer.

     Roger's secret weapon on this front was: "Well, is your documentation complete?" That might have something to do with why nobody took him up on his offer.

     I tend to think Roger has it right, i.e., that managers tend to take the "critical path" a little too seriously.

     The other thing he did was to create a "right-to-left" PERT chart, the "integration plan", which mathematically "should be identical" to the usual (left-to-right) one. But there's some effect of doing it in the "reverse" direction that makes the critical path stand out.

   Whether Goldratt's scheme (with a lot of focus on the critical path, various buffers, critical chain, etc.) or Roger's (one "contingency account", treat the critical path with benign neglect) is ultimately correct, I think the first step is to Just Do It™ -- take a step away from "pad everybody's schedule and track milestones", toward a tracking scheme based on buffer(s) (or contingency account(s)).
   

I obviously have not done justice to Goldratt's book (I've only read this one), and certainly not to Roger's management ideas, but this is a start, anyway.

Update:
Roger read the above and emailed me back the other day, to clarify and remind me of some things I'd forgotten. The green text is my summary of his comments.

— collin 2007-04-10

Drucker the prescient

You've heard about, um, what's his name?, Treacy maybe (looks like TREE-see but pronounced like Tracy)? with the three paths to biz success: operational efficiency, superior technology, customer intimacy?

I happened to see this just now in Drucker's Managing for Results (H&R 1964), p. 200:

General Motors, for instance, clearly prizes excellence in business development and business management (operational efficiency). At General Electric, on the other hand, people were for many years encouraged not to concern themselves much with business, but to excel as scientists or engineers (superior technology). IBM, until recently, stressed the ability to produce sales and customers, with the district sales manager the key man (customer intimacy - sort of)
(green italics mine).

When did Treacy's book come out (Discipline of Market Leaders, 1997?) -- and how many years earlier did Drucker point out practically the same thing - 30 or more? The guy was a genius.

Skills are not enough

Some of us are reading McConnell's Rapid Development, and this question arose:

Why, ten years after that book was written, are most of the software organizations we know are still messed up? Does McConnell's advice actually not work?

Here was my take on it. Usually I'm not quite so excitable at the office, but I had to read patent applications, and that made me grouchy. Edgy. Whatever.

OK, here's my irrational rant of the day. (my first of the day.)

I believe that the problem is the technical mindset. By that I mean we focus on technique rather than on character. This mindset is endemic to our culture in this period of time: look at all the how-to books. The weakness, however, is seen in the titles of all those "Dummies" books. No matter how much technique a dummy may have, s/he is still a dummy without changes in CHARACTER.

If I think wishfully rather than realistically, that's not a skills issue; it's a character issue. If I deny reality rather than face the truth that (my team and) I have screwed up yet again, that's character, not technique.

I said "culture" above rather than "industry" because Dummies books aren't limited to what we usually think of "tech" (as in technology) subjects, although they *are* focused on "tech" as in techniques, and skills....

In fact, sorry to say, this kind of technique-obsessed thinking has infiltrated the church (you can mentally substitute any other religious or civic group with a fair chance of being correct) -- what do we need for successful small groups, choirs, programs? Skills! Classes! Training! Technique!

Bah! What we need is integrity, holiness (in some areas), zeal, leadership, and guts! Not just technique! Not just skills! Technique and skills are just crap if my head is full of wishful thinking. You can see this if in place of "civic group" you put "marriage." Your wife doesn't want skills and technique (well, maybe in some things), she wants YOU.

What we need in software development, BESIDES knowledge of tools and techniques and skills, is discipline, reality, courage.

What we have, early in the 21st century is lots and lots of technocrats, very smart and highly skilled people who may be OK in the character department, but not great. Not highly courageous. Not highly disciplined.

That includes me.

Reading these accursed patent applications makes me feel very edgy.

Regarding McConnell's advice (in the book) I said:

It would work if only we would follow it. We cannot master software if we only work on technique. We must first master ourselves.

Arrgh.