Career Bookends

According to my offer letter, I was supposed to start at IBM sometime in June, 1976 (I’ve forgotten the exact date) and work on a compiler for the minicomputer that would be released as the IBM Series/1. However, I delayed reporting to work in favor of becoming engaged to Diane, and by the time I got to Boca Raton, the spot on the compiler team had been filled.

  • First day at IBM: July 19, 1976, Boca Raton, Florida, General Products Division

My first job at IBM was on the team writing telecommunications code for the Series/1. I wasn’t enthralled, especially when it came to testing the code, because we had to short out the peripheral cards to load in our code, and I didn’t realize that there was only low voltage in the Series/1’s card case! And the idea of dealing with information that left the machine and might or might not return successfully was strange, too.

So after a few months, I made a deal with my management — if I would provide a complete unit test plan for the code I’d written, they’d transfer me to the Operating System group (just down the hall). They were happy to oblige, so I wrote the first of many productivity aids, one which read the structured assembler code and annotated it according to our unit test scheme (“Test Plan 7”). It took me a day or two to produce the test plan for all of my code, and away I went.

The Series/1 was an interesting beast; it had 64kb address spaces (we only used one in the first release of the OS) and not enough registers. It also had short and long forms of many instructions (the short form had, if I remember, 256 bytes of addressability from “here” — anything else took the long form). We were perpetually running out of room in the address space, and it struck me that it would be a good idea to have a peephole optimizer which would convert long form instructions to short form when possible. So I wrote it, learning PL/S in the process. And people loved it — it was in our “Quality Plan” almost immediately. That was the first time I really understood how much leverage smart tooling could provide.

I created quite a few other tools while I was in Series/1 development; I’m not sure why other people didn’t do the same thing, because I found that doing so always saved me time, and then providing the tools to my colleagues really provided a big payoff, at no extra effort. And I even got to learn new languages in the process (most of which I have, mercifully, forgotten), which I greatly enjoyed.

I mentioned that we were writing “structured assembler” code — this was in the days that using structured code instead of GOTO statements was considered an “Improved Programming Technique”. There were many “Improved Programming Techniques”, not all of which were used well.

In particular, we documented our code using a technique called HIPO — the documentation for HIPOs said, very clearly, that they were not used to document the logic of a module, just its overall function; however, our “Quality Plan” called for us to use HIPOs as flowcharts to document the logic. I found this silly (not to mention very tedious), and so I wrote my first memo at IBM: “HIPO: Threat or Menace” (playing off a National Lampoon cover), quoting the HIPO documentation to make my point. In those days, we actually hand-wrote memos, and the secretaries typed and distributed them — my department’s secretary tried very hard to get me to change the subject line, but I refused. In hindsight, the subject line probably didn’t help my case, but the HIPOs vanished.

It’s been a long time since anyone has had to type a memo for me; I can’t remember the last time I got a real hardcopy memo, for that matter. Email has taken the place of memos, and, for better or for worse, nobody else sees them before they go out to the world.

I wanted to find a way to reuse the subject line of my first memo in my last IBM email, but the joke wasn’t all that funny in 1976 and hasn’t improved with age. So my last email had a more personal subject: “33.7 years – that’s not too many”.

  • Last day at IBM: March 31, 2010, San Jose, California, Business Transformation/IT

And you know what? I never did get to work on a compiler at IBM!

Google is not idempotent

Today was my last full day at IBM; I decided to spam thank some close soon-to-be-ex-colleagues before I left. Since I wasn’t sure that those who wanted to respond would do so before my IBM email address expired, I directed replies to an address at a domain that I set up for my family (let’s call it example.us, just to keep the real spammers at bay).

Mail for example.us is MX’ed to Google Apps servers; I’ve set up forwarding there for each of us to our real preferred GMail addresses. This has the advantage of letting me move from GMail if I want to, without anyone being the wiser.

But today, I discovered that Google isn’t consistent in its mail filtering. A friend at work thanked me for sending her the note and mentioned that she’d replied — but I was pretty sure I hadn’t seen her reply. And when I searched the GMail account, there was nothing from her. But when I looked at the mailbox on example.us, her note was there. And, in fact, there were several replies that hadn’t made it to GMail but were safely in the inbox for example.us.

So I guess I need to rethink my mail strategy and let mail for example.us stay there instead of forwarding it to GMail.

Life was easier when all my mail went to singer@almaden.ibm.com! (I’d worry about spammers getting that address, except that it’s been visible on the Web and well-spammed for many years, and, of course, it expires tomorrow.)

Competencies and Derailment Factors

When I wrote about derailment last week, I thought I was just punning from my manager’s question to me. But several people have asked if I could share more information about IBM’s Leadership Competencies and the Career Derailment Factors.

I was hesitant to do so, since the last thing I want to do is leak confidential or proprietary information, but it turns out I didn’t have to worry; IBM has published quite a bit about these topics, and I’m perfectly happy to point to what they’ve already shared. I haven’t explored these items very deeply, but they look like they might be useful.

Competencies

I’ll start with the Leadership Competencies. There are 11 of them:

  • Client partnering
  • Collaborative influence
  • Developing IBM people and communities
  • Earning trust
  • Embracing challenge
  • Enabling performance and growth
  • Informed judgment
  • Passion for IBM’s future
  • Strategic risk taking
  • Thinking horizontally

(Source: IBM Zurich Research)

Most of them would apply with slight changes to any large company (and probably to small companies, too). The most important, in my opinion, is “Passion for IBM’s future” — when someone loses that, it’s time to look elsewhere (or to find a way to recharge). Jay Conger at the Center for Effective Organizations at the Marshall School of Business at USC includes a useful diagram of the competencies in a broader presentation on leadership competencies in several organizations, and Fast Company wrote about the competencies in “IBM’s Management Makeover” in late 2007.

IBM also has a set of “Foundational Competencies” for “outstanding non-management employees”:

  • Teamwork and collaboration
  • Trustworthiness
  • Communication
  • Taking ownership
  • Client focus
  • Drive to achieve
  • Passion for the business
  • Creative problem solving
  • Adaptability

(Source: IBM South Africa Graduates Facebook page)

Finally, Walter Pistarini in IBM Professional Development gave a presentation about both sets of competencies and IBM’s “Professions” to the World Computer Conference in Milan in September 2008.

Current IBMers should also note that there seems to be work in progress to merge the two set of competencies and produce one set of “IBM Competencies” for all IBMers; there is a presentation in the Media Library (inside the firewall)

Career Derailment Factors

There are about 30 derailment factors, which are grouped in 10 categories:

  • Lack of Adaptability
  • Lack of Self Awareness
  • Lack of Work/Life Balance
  • Lack of Self Control
  • Lack of Interpersonal Acumen
  • Lack of Independence
  • Lack of Trustworthiness
  • Lack of Strategic Perspective
  • Lack of Backbone
  • Lack of Organizational Acumen

I took the list from the slides which accompany the Derailment Factors – IBM episode of the OneSHPE podcast series on education, career, and engineering created by
IBM and the Society of Hispanic Professional Engineers (SHPE).

And if you want to know even more, Audrey Murrell, Sheila Forte-Trammel, and Diana Bing have written Intelligent Mentoring: How IBM Creates Value through People, Knowledge, and Relationships, which discusses the Career Derailment Factors.

Lasts

As my days at IBM grow shorter, I’m beginning to realize how many “lasts” have already happened or are imminent.

Some passed unnoticed, because I didn’t realize they were the last of their kind:

  • I’ve already changed my intranet and Notes passwords for the last time
  • I’ve already created my last PBC (Personal Business Commitments)
  • I’ve already submitted my last TEA (Travel Expense Account)
  • I’ve already ordered my last set of IBM business cards (and didn’t get a chance to use any of them!)

Some happened after I got the word:

  • My office has been vacuumed for the last time (at least while it’s my office)
  • I’ve qualified for the Fitness Rebate for the last time
  • I joined my last “Community Builders” conference call

And some are yet to come:

  • I have the opportunity to attend a final Architecture Review Board call on Wednesday
  • I’ll be giving a last GTD-at-IBM presentation on Friday
  • I could even attend a final CIO DE community meeting on March 31st

No, they’re not all significant, but they’re all steps towards what comes next. And so they matter.