Some things I'm thankful for (particularly at work)

Some weeks ago at Trinity Menlo Park, Pastor Aaron reminded us that life is short, and we don’t have many days to bless those around us. Inspired by that remark, I emailed the below to a few (i.e., quite a few) of my co-workers.

---

2019-12-04 2:12pm Pacific

Colleagues,

I was reflecting the other day on things I’m grateful for. Family and friends, of course; a measure of health; vehicles and home appliances that work well enough. Not least is the opportunity to work together with so many intelligent, hard-working folks (yes I mean you).

And as I reflect on the ONTAP development experience at NetApp, it strikes me how much better that experience is today as compared to what it has been. Reviewboard is just one of the major improvements that came in over the past 15 years or so.

In the “old days,” you could check something into ontap/main, only to get a nasty-gram from the build daemon. Then you’d find out that the build daemon had been failing for several hours because somebody broke it and no one fixed it!

Auto-heal isn’t perfect, but it’s pretty close, which we can tell by how surprised everybody is when it can’t back out a bad checkin.

I also remember a day when Isabelle submitted something and the build-ng daemon whined at her. She backed her change out and the daemon kept failing! It took several days to figure out that missing dependencies had hidden the real culprit, which had been submitted some weeks before :-(

Bedrock and DOT/dev aren’t perfect either, but again we’re surprised at sporadic failures...

I think of Anchorsteam, which shipped at least a full year late. We added Scrimshaw after Fullsail, because customers were waiting so long for another release—but Scrimshaw was late, too! Back then, managers really had no idea how close we were to being ready. Or they wouldn’t say :-(

Although the six-month release cadence hasn’t been a panacea, it has brought some reality into the management ranks.

And do you remember how much stuff we shipped without testing? Scrimshaw.3 had no snapmirror testing whatsoever! A former VP demanded that we test patches more thoroughly—and also ship them more rapidly—that didn’t work too well.

I am so thankful that today we have CITs and auto-heal, daily code coverage reports, CTL, and other tools to enhance ONTAP’s quality.

All these things took a lot of work from a lot of folks. Reviewboard, bedrock, bammbamm, CITs, auto-heal on both build and CIT, and so much more. You know who you are.

Thank you thank you thank you for how you’ve improved life for developers, and thereby for all the folks that rely on our products every day.

Integrity?

Some years ago, the elder ex-teen (now the mother of two) and I spent some time in Professor Carter’s book integrity, which goes into various areas: intent, due diligence and so on. In other words, integrity means more than simply not telling lies. When put that way it seems obvious, though I don’t usually pay so much attention.

The question of integrity came to mind recently when a friend (I’ll call him “Dieter”) told me about an incident at work. Dieter’s a software guy, like me, and his company’s website (I’ll call the company “JCN”—not the real name) describes a project they did internally. In the article is a statement of why they did this project. The statement is not true; JCN actually did it for a completely different reason than their website says.

JCN’s stated corporate values include words about ethics and integrity, and they have an email “hotline” for that, so Dieter sent them a note pointing out that, paraphrasing, “Our website says the project was ‘first and foremost’ about doing X better, which everybody knows is not true.”

In fact, when the project went “live” at JCN, X was much worse. Dieter admits that today, X is not that much worse than it was before the project. That said, the project really wasn’t about improving X; it was done for a completely different reason.

Dieter acknowledges that this false statement isn’t critical to the company. They’re not promising something their products can’t deliver; nobody’s going to sue JCN or cancel a purchase order because of this statement. But as Dieter told the “integrity” people at his company,

When we make a statement about why we did something, and that statement is not true, that is what makes it a lie.

Please remind me not to get into arguments with Dieter.

JCN’s “integrity” people didn’t see it that way. Dieter was quite bugged by this; he even considered leaving JCN for another employer. But then remembered a couple of things.

• He’s an American; he knows that his government has killed people in other countries and overthrown democratically-elected governments. But he’s not thinking to become a citizen elsewhere.
• The prophet Daniel worked for a cruel and arbitrary boss, King Nebuchadnezzar. But would Daniel have quit, given the chance? Probably most bosses at the time were pretty similar, and maybe incompetent to boot. The same thing is probably true of American corporations.

Dieter came to understand that when the company says “integrity,” what they mean is, “Don’t do anything illegal, anything embarrassing, anything that will alienate a customer.” He wasn't happy with that conclusion, but anyway it was a conclusion.

Something else happened that I thought very interesting. After concluding his dialogue with JCN’s “integrity” folks, he told me, “my back stopped hurting!” His back has been complaining (yeah, he’s old enough for that) for some months. The pain hadn’t been debilitating, but he says that was the first afternoon when his back didn’t hurt at all.

What brought relief to Dieter’s back? Was it his acceptance of his employer's Newspeak, like the 5th stage of death and dying, that did the trick?

And what’s the moral of this story? Dieter doesn’t know. Neither do I

Confession: taking one for the team

Last week, I sent out a confession at work. I'd read an encouragement to do things like that, and…well, it's pretty self-explanatory. Here's a lightly edited version:

   From: collin <email.address@here>
     To: <recipient-list here>
   Date: Last Tuesday
Subject: Confession

Short version: I did something dumb and confess it.
Busy people can stop reading here, though I hope you read this at some point--maybe while waiting for one of your tests to complete. Details follow.

---

I picked up a free copy of The Soft Edge when they were being handed out at the cafeteria some weeks back. In it was an encouragement to celebrate successes and also to confess mistakes--especially big successes and big mistakes (cf. “Asoh Defense”).

I saw the power of this a while back when a colleague told me about a mistake, looking somewhat sheepish. “We’ve all done that,” I said. Just to make sure, I added, “I’ve done it myself.”

Well, I’m not the most empathic guy but I felt the weight lift off their shoulders. “You’ve done it?” they asked, incredulous. Yep. It was probably about 20 years ago, but I’ve done stupider things before. And since.

Fast forward to the present. There have been lots of failures in <test case name here>. Some of them happen only when nobody is watching, and have defied analysis. But one of them should have been fixed (by me) right away: burt987303.

It happened in February, then again 8am on May 2. The symptom was a timeout on a “d-volume-create” zapi. “Hey,” I thought, “if the simulator (in this case) can’t come back within 100 seconds, then maybe it died. I could look more, but since it won’t happen again for another 2 months, how much time should I spend on this?”

The answer was: Just a few minutes more--long enough to RTFM and adjust the timeout. You see, it happened again May 4th. You can read <internal document name here>, but the short version is that zsmcli has a “timeout” parameter: I coulda just set that in the command to extend the default 100s timeout.

I’m happy to tell you that I checked in a fix, and that said fix prevented another failure on 5/7 (in <log file name here>, there’s a 118-second d-volume-create execution).

To be clear, the issue was in a test script; the issue wasn’t in the product. I’ve introduced, or incorrectly fixed, product defects before, but this particular issue is in a test case, not in any product sold by my employer.

Is there a moral to the story? Well, the obvious one is to rtfm. Or the help message, as the case may be.

The second is, if you’ve done something like this (it could be more or less dumb; we’re not being precise), don’t feel too bad about it. Performance reviews are over; you could tell somebody. If you’re more senior--or just old--you could tell someone younger; it’ll probably help them feel better. And that in turn might help them think more clearly, too.

cheers,

Why did I say that telling a younger person about your mistake might help them think more clearly? Because when we reduce the pressure they feel to appear perfect (even if the pressure originated inside their own head), they’ll have less anxiety—less stress. Less anxiety, clearer thinking.

It also makes you appear more human, more real. And we need more of that—more live, human connections (as distinct from mere contractural, transactional connections) in the workplace. Out of the workplace too.

Too Thorough? part deux

In part 1, I tried to make the point that when a VP or Director calls someone “too thorough,” s/he may mean

“You're giving me too much detail (which I don’t want/need to know); let's get to the high-level information (which I do need to know).”

In other words, sometimes our presentation doesn't match the audience. I resemble this remark, I hope progressively less so as the years have passed.

Another way we're sometimes “too thorough” is that sometimes we spend too much time delving into details that have no bearing on the problem we're trying to address. By the way, I sincerely do mean “we,” as this post attests. About 3/4 of the way through that post, I wrote, “In other words, I was done.” I could have stopped there. Arguably I should have, since I demonstrated that my explanation fit all the facts, and that my code change banished the symptom.

That last sentence is the key. We are not FreeBSD maintainers; we are FreeBSD users. As such, once we know enough to plausibly assert we know what's going on, and to demonstrate that we can make the symptom vanish, we know enough, period.

So why did I continue there? No doubt some of it is a kind of engineering curiosity, not altogether a bad thing. It was exactly that engineering curiosity that drove me to ask my colleague to configure a virtual machine with a disk that could take coredumps, and to find the uninitialized struct component. That is, a certain amount of engineering curiosity is required if we're to make progress. I'll claim it's worse to have too little curiosity than too much, though the truth is probably more nuanced than that.

Early in my career, my manager wrote on a review that I tended to work fast and rely upon experiment. This was a nice way of saying that I sometimes rushed in with an answer without fully assessing the situation. He was right, of course. Back in those days, I would never have written that blog post, because the experimental result would have fully satisfied me; I'd be on to the next thing.

Is it just curiosity then? I guess there's some sort of pride in there, too—the desire for mastery. I love it when I have a complete explanation for how something happened—when I've mastered it. Of course that's not what my employers pay me for; they pay me for solutions to problems that they choose.

The next question for an engineer is: What problems are worth my attention, my curiosity? Senior people are supposed to just know; if something looks odd, is that something worth looking at today, or can it be safely ignored until it becomes a real problem? Is the "obvious answer" truly the answer, or does it simply make the "root cause" harder to find?

Well, we don't know. We need to look far enough to feel confident enough to make a decision, and we need to be lucky enough to not get blindsided too much.

So what's my plan? I'd like to say that the next time I'm hot on the trail of something, I'll stop and think, "Do I truly need to be investigating this?" and make a sober assessment of whether I'm being compulsive, vs. just exercising due diligence.

Maybe that's like saying, "The next time I'm about to say something stoopid, I'll bite my tongue." Does that sound totally useless? Well, if I can remind myself that I have this tendency, or limitation, that's the first step, right? As the engineering guru Clint Eastwood said, "A man's got to know his limitations." Or weaknesses. And of course women do, too.

---

Well, that was a lame ending. That's because I don't really have this one figured out. Maybe you have some ideas? Leave me a comment :)

Too thorough?

Is such a thing even possible for an engineer? Maybe not in a literal sense, but what does it mean when a VP or director says it (because they do say it)?

Short version: When a VP or Director says that, they probably mean “You're giving me too much detail (which I don’t want/need to know); let's get to the high-level information (which I do need to know).” Details follow.

Some years back, when I was working at HP, my boss and I had a meeting with “the great Bernard” (my boss's phrase) to talk about a proposal from a customer—it was AT&T actually. They wanted us to port some of their code into the HP-UX™ kernel, and provide support.

We had studied their proposal; I even had a look at their code. We had prepared some slides (think "powerpoint") and went to see Bernard. Bernard had talked with hundreds of customers and partners, and had a clear idea of what he wanted us to say.

It was not what we had written. Our slides discussed capabilities, testing, limitations and such; we had numbers and details. Bernard took a pad of paper, turned it "sideways" ("landscape" orientation), and started writing:

• HP is fully committed to AT&T System V
  
  
• …

His next points talked about how this would have to be an HP product, available to all our customers.

When we met with the AT&T folks, Bernard did a lot of the talking. He said we were going to sell a product based on their code, meaning anybody could buy it from us. They asked if they'd get some of the money, too. "Maybe," he said. That satisfied them.

The discussion continued at a very high level.

So had we been too thorough?

Well, no. But the presentation materials were too detailed for the level of conversation we were having. Fortunately, Bernard was vetting the materials so that we could have a fruitful conversation with the customer (and our would-be partner).

The lesson from this experience, which probably happened in the late 1980s, was to create a presentation to match the audience. If we were meeting with their technical team, like the folks who had written the code, or their QA folks, our materials would have been great.

I've been taught this lesson many times over the years, but I have yet to fully absorb its importance. I tend to ASS-U-ME that people have the same background as I, are fluent in the same languages (like vi(1) keystrokes), will "get" my allusions, and so on. When I'm my best (most culturally-sensitive) self, I remember not to assume too much, and one would think I'm getting better at this as I get older. Well, hope springs eternal…

Too much detail!

The above vignette makes the point that directors and high-level managers think and talk at, well, a high level. No, really! They don't want a lot of details.

This can be bad (consider the Challenger disaster) but it's also necessary: before we can engage in a detailed discussion, somebody's got to set the rules of engagement, or terms of reference. This is obvious when talking with partners or customers; it's less obvious but sometimes still essential within the company.

When a director asks how it's going, she probably doesn't want to know that I've examined so far at 17 of the 26 potential callers of a particular routine. She is thinking about a milestone we need to hit, or whether a particular design decision looks like it was working out. What we need to do is give them the information they want in a way that they'll understand.

And I don't just mean "easy to understand"; I also mean "nearly impossible to mis-understand." But that's another blog post.

But I spent so much time on this!

When I'm in the midst of analyzing logs and core dumps (or trying to), and somebody asks me what's happening, I want to answer the question as I hear it. My whole mind, hence my whole world, has been wrapped up in these log entries, and these backtraces, and so on. The discipline I need to embrace in these moments is two-fold:

1. to disengage enough from what I'm thinking about and put myself in the other person's shoes, if just for a minute; and
2. to restrain myself from talking too long about something just because I've been thinking so long about it.

An example of how #2 was done right is from the motion picture industry. In Star Wars Episode VI: Return of the Jedi, Luke Skywalker confronts "Jabba the Hutt" at the latter's lair, an intricately constructed craft that looks like an ancient sailing vessel. This thing was carefully designed and beautifully contructed; I seem to recall that there were many arguments over the design and that it took months and months to construct. But it's on the screen for no more than 5-10 seconds.

Why only 5-10 seconds? Because that's as long as the audience needs to look at it. Contrast this with the earlier Star Trek: The Motion(less) Picture, where you feel like you're watching a shuttlecraft approach Enterprise for half the movie.

Conclusion

As my wife often reminds me—or rather, as I repeatedly bang my head against this same wall—there's often a big difference between what she wants to hear when she asks me something, and what I want to tell her about it.

Career advice debunked

Notes from a lecture by Norah Denzel at NetApp 01 April 2014. She does not endorse my transcription etc.

A few preliminary notes: She started in storage in 1984, spent 13 years at IBM. Went to Veritas, Legato, then HP, where she ran software: 10,000 consultants in 110 countries. She took 2 years off and went to Intuit, which had/has a very different model: millions of units where unit price less than $100.

She was the first person in her family to have a corporate job. When she was starting out in the work world, she asked people she knew for their advice -- the five smartest people she knew. Their advice follows, along with Norah's updated/amended (emended) version thereof.

1. It's not what you know; it's who you know.

   Actually, the more important thing is Who knows what you know.

   You can meet all kinds of people, but unless they know your expertise, your goals, what you do—in short, what you know—all those acquaintances are just acquaintances.

   What you need is a sponsor to help you. And they won't help you unless they know where you're going and what you can do.

   Note: telling people what you do is part of your work and reduces your learning curve. You want "epiphanies at scale."

   And don't wait 'til you're done; your sponsor can help you steer your way there.

2. Climb the ladder of success.

   Actually, it's more like "Chutes and Ladders"; it's an obstacle course. Think in terms of learning and strengthening yourself.

3. Always tell the truth.

   Best advice ever: "We really like you. You always tell the truth. Always tell the truth, but not so much of it." Press releases are edited/tuned, and they should be.

   If somebody says, "You did a great job on X," the correct response is, "Thank you!" Do not say, "Well, I got a lot of help from Chris" or "Yes, but I wish I had done this part better."

4. There's success and failure; just succeed.

   Well, you can play "not to lose", but that's a bad idea. Failure is part of success; learn from it and move on.

   I guess this is a lot like #2.

5. How hard can it be? You were smart in school; just be the smartest person in the room.

   Actually you can learn the most when you're the dumbest person in the room. Being ignorant isn't anything to be feared.

A few more notes...

There are stereotypes; they can't be avoided. The question is not how to stop people from stereotyping or pigeonholing you; it's "When they do that, what are you going to do?"

Another thing. Sometimes you may want to try something more exciting; other times, you might want to stay with what's comfortable. If you have small children at home and/or a lot of other out-of-office commitments, it's entirely valid and reasonable to do the latter.

42% “efficient”

Suppose a team of coders work on a project, and we say we want code reviews, or maybe inspections. We have estimates for how long various parts will take to code -- adding up to 3 engineer-weeks, say. How much effort (engineer-days) should we allocate to cover code reviews, discussion and rework?

Well, that depends of course on how much time we think it will take to review and discuss and rework the code. Let's suppose for a moment that if my colleague spends a week coding and doing some basic testing, then I will stare at the code for two days. Actually, let's say there are two reviewers, so two of us will stare at the code for two days each.

Then we have a day where three of us meet (in the morning, say) and talk about the code for a while. After 1½ or 2 hours, we go back to our desks and think some more about what we heard, and the person who wrote the code makes some changes. We repeat that but at the end of the day we're all happy with the code.

As I write this, that seems like a lot of review time, but if we do it that way, the total engineer-days spent add up thus:

• 5 engr-days coding
• 4 engr-days reviewing (2 reviewers @ 2 days each)
• 3 engr-days discussion and rework (3 participants @ 1 day each)

Twelve (12) days total, for a thing whose coding estimate was 5 days.

That works out to 5/12 ≈ 42%. In other words, if you have 10 engineer-days available, then at the above rates of "overhead" you can spend only 4.2 days coding; the rest is review, discussion, rework. That doesn't include integration or system test, etc.

Perhaps I have the wrong ratio of (review + discussion + rework) to (code and basic test), but I'll confess to being surprised at the result of 42% given the above.

Improving quality of a multi-component system

Suppose you have several product testing teams -- let's call them the "A", "B", "C", "D" [etc] teams.

Suppose each testing team focuses primarily on testing "their" component, but teams can also find defects in other components, so for example the "A" team mainly tests the "A" component, but they might happen to find a problem in the "B" component.

The "A" testing team has a manager, who is probably being rated on how well the "A" team is finding defects in the "A" component. The "B" test manager is rated on how well the "B" team finds defects in the "B" component. And so on.

Each manager will tend to say "I want the bugs in our component to be found by us, so whenever those other turkeys find bugs in our component, you guys explain to me why they found it and we didn't."

What will happen then? Whenever the "B" team finds a bug in the "C" component, say, the "C" team will be motivated to duplicate the portion of "B"'s tests that found the "C bug," and they will spend time on this that they could have spent writing new tests.

So here's a puzzle: how to put a stop to this behavior? Because if things go on like this, the "C" team will waste a bunch of time

• writing reports for their manager (who is also in a lousy position) explaining why the "B" team found bugs in the "C" component, and
• duplicating parts of the "B" tests.

In the worst case, everybody will copy everybody else's tests, which means the same tests will be run multiple times, rather than writing and running different tests. How does this improve product quality? (Really, the "C" team should be thinking of other ways to test the "C" component, and the system for that matter, rather than duplicating all the "B" tests that happened to find some "C" bug.)

Here's what needs to happen: The QA Director or VP needs to be told that this nonsense is going on, and they need to put a stop to this sort of internal competition. In particular, they must not ding the "C" manager if the "B" team finds a "C" bug, and so on.

I mean really, if the "B" team finds a bug in the "C" component, the "C" manager's response should not be "Grrr, we should have found that, not those turkeys"; it should be "Terrific! Let's see if we can learn anything from them and write new tests to more thoroughly test our stuff."

Because every bug found inside the company is caught before the customer hits it, and for that we should rejoice. The point of quality assurance is to assure quality of the product as seen by customers; it really shouldn't matter if the "B" team finds "C" bugs or the "D" team finds "B" bugs -- so long as we find and fix the bugs before they get to the customer.

When people don’t stay long on your team

In a conversation that hasn’t happened, I chatted with someone about the team he manages.

“People don’t stay on the team for long,” he says. The team is staffed entirely by volunteers who want to support the team’s purposes, which for purposes of this short essay I’ll describe as “helping people grow.”

Why might people not want to be on this team long? Is it because they don’t really understand what the team’s mission and vision are? That’s possible.

Another possibility is that the work is too difficult—either absolutely (Just Too Much Work) or relative to the results they can see (i.e., “What is the larger organization getting for all this effort I’m putting in?”).

Or there may be something about team dynamics: is the team hard to get along with, is there too much criticism and not enough encouragement for new members’ work? Is the leader hard to get along with?

Now that I think of it, I know of at least two teams with long-term (multi-year) recruiting challenges. Let’s call one of them the “G Team”; it’s hard to get people interested in joining this team. It’s kind of nerdy, to tell you the truth. I was on the team for a while, but then other responsibilities took me away from it. Today it’s still hard to get people to sign up for it. Once people do, though, they seem to stick with it, at least for a few years.

Another team, I’ll call it the “T team”, has people sign up, but they seem to stay on for a fairly short time. I’ve talked with two ex-members of the “T team”; one of them had the odd experience of showing up for a meeting and being put to work stuffing envelopes. This person left the team shortly after that meeting.

Another ex-member had a, ah, an altercation with the team leader. This ex-member apologized for their part in the unpleasantness, but the team leader never ’fessed up to theirs. As far as the leader was concerned, the issue was 100% the ex-member’s fault.

This sort of thing isn’t unique to the non-profit or volunteer world. There are some managers who have a hard time holding on to subordinates. You may have met them; some of them are like the engineer who was never wrong; some have multiple faults (hopefully your manager isn’t like Michael Wing’s composite anti-manager “Burt”), some just work in awful organizations.

But if you’re leading a team of volunteers, or managing a group of employees, and you’ve got high turnover (you get to define the term), you might want to look in the mirror. Some questions to ask (and not ask):

• How have I solicited input from the team about my leadership style, my strengths and weaknesses, things I could change? And how have I responded to that feedback?
• How do I show each team member that their efforts are important? How willing am I to delegate decisions (rather than tasks)? And if they decide something in a way other than I would have, how often have I overridden their decision?
• How often do I give direct, specific encouragements to my team members? The “specific” part is really important. “You’re great” is nice, but it could be insincere. And it could sound insincere. Better to find something they’re doing right and making a sincere and appropriate affirmation about that: “Thank you for putting in the extra effort to find those details supporting our plan; that really improves our chances...” or something like this, is much more powerful.
• When a team member does something I don’t like, how often do I to tell them, vs complaining to someone else? And if I tell them, do I do that in a punishing or a non-punishing way?
• How readily do I admit my own mistakes, misjudgments, failures, to my team?
• Don’t ask: Why are you leaving? (And don’t ask HR what was said in the exit interview, either, if there was one.) Really. An employee leaving the firm knows there’s no percentage in saying anything negative about their ex-manager. And in the non-profit world, what’s the point of saying anything negative to you? If they thought you would/could change, wouldn’t they have said it earlier?
• When was the last time I showed concern for each team member’s personal or emotional life?

"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