The bear says, “You see? It really does work.  Now make yourself light again.” Whereupon the hedgehog quietly retorts, “How about you doing something once in a while?”

Midnight Train

A few months back, I wrote a post on various “Astounding Sayings” that I’ve encountered in my career in information technology.  It turns out that it’s been one of the more popular posts I’ve written, judging from page views, so in true Hollywood fashion, it must be time for a sequel.  I am retitling it slightly, though, to distinguish it from the Peterisms I post from time to time.  The point of writing about the “astounding” sayings was that they usually reflect misguided energy (or, to put it bluntly: wrong-headed thinking); the point of the Peterisms, on the other hand, is to distill and communicate absolute, undeniable, sublime truth and wisdom at every possible turn. (Hopefully it’s unnecessary, but just in case, <insert smiley face here>.)  Hence, I’m now going to call these non-truthful, unwise sayings “astounding utterances” instead.

Here are two more such utterances, with moral-of-the-story observations for each.  Note: as before, these are true stories.  I may have changed some of the facts, lightly, to make them less identifiable.  They also always come from at least several years in the past, to provide a healthy amount of distance for everyone.

The utterances that I consider to be astounding, in their context, are highlighted for you below in bold.

• Looking out for #1, and, um, that would be ME.
  

Regular and formal goal-setting, to my mind, is one of the key managerial ways to focus and align everyone’s efforts in the business world.  Done well, it ensures that people are working on the right objectives, and are incented to achieve things for the common good of the business. The exercise often also brings to light any number of disconnects (teams working at cross-purposes, etc.) that would otherwise go undetected.

Usually, the way I’ve found this kind of goal-setting works most effectively is to actually collaborate with the employee on establishing meaningful goals for their role.  This isn’t exactly a jaw-dropping insight.  Workers themselves usually are quite expert in what needs to be done in their area; managers can help prioritize, push for improvements, and “ripple down” the larger goals of the company at that particular time.  So, the manager will typically draw up a list of suggested goals, ask the employee to do the same, and then they work together on aligning the two so that it all makes sense.  Goals should of course be “SMART”—Specific, Measurable, Attainable, Realistic, and Timely—but I won’t go into the specifics of that here; check out the links at the bottom for more information.

All of that’s pretty obvious, right?  Well, during one such goal-setting exercise a few years back, one of my managers came to me and reported that one of her employees had gotten upset at the draft suggestions the manager had drawn up for possible goals.  The employee didn’t like seeing specific targets for her work, such as measurable throughput, successful completion of projects, improvement of operating results.  Her response to seeing her manager’s suggestions was to snort, “Those aren’t my goals—those are the company’s goals!”

We can of course laugh at how obviously misguided this person was (just why she imagined that the company was paying her, if not to push for improvements and to help achieve certain company goals, I have no idea).  But I think the incident reveals an all-too-frequent attitude in the workforce, sometimes at all levels.  People who aren’t focused and actively driven to working on achieving meaningful overall company goals will simply hold everyone back. They’re in it for themselves, first and foremost.  If you find someone who doesn’t innately understand that having the company succeed will almost certainly tend to augment their own situation (salary, position, etc.), you need to work with that person quite seriously to see if you can bring them around.

• We wanna do what WE wanna do. Why are you asking these annoying questions?
  

You’ll note a theme, as usual, in this pairing of utterances.  For my second story, I’ll describe just a bit (tip-of-the-iceberg style) about a situation I walked into several years ago, where a development team had gone whole hog, tooth and nail, hook-line-sinker-and-the-whole-nine-yards, into Extreme Programming as their operative model.  Now, my purpose here is not to bash Agile or Extreme Programming, because there are actually quite a few positive aspects of those approaches, and discussing them fairly deserves at least a whole separate post. 

But when I started my CTO role at the company, I needed, as always in a new position, to ramp up quickly on current projects, deliverables, time frames.  And I could find nothing to go on.  Far from being Specific, Measurable, Attainable, etc. in their goals, this team had come to a style of work (and had been allowed to do so) where next to nothing was ever written down, and few goals were concrete other than (it seemed) just getting through the day.  In fact, I’d been hired precisely because top management was growing ever more concerned at how little was actually getting delivered.  I sat the project manager down and asked him how they hoped to know when they were really done, or whether what they were delivering would meet the business needs, or how they hoped to test what they had produced if they didn’t have definitions of what the specific goals were.  Where, in short, were the guiding definitions and documents that would serve as their touchstones during such projects?  He looked at me, arched his eyebrows, and proudly stated, “We’re parsimonious on documentation around here.”

Whatever one thinks about Agile and Extreme Programming (and let me reiterate that that is a complex topic that deserves a separate post), this was clearly a situation that had gone to a bad extreme, one where accountability and purpose had gradually drifted out of the picture.  There’s room for a lot of different and viable approaches in software, but almost completely eliminating accountability and direction isn’t an approach that I’ve seen bear a lot of fruit.

And there’s nothing astounding about that.

Lagniappe:

• http://en.wikipedia.org/wiki/SMART_(project_management)
• http://www.goal-setting-guide.com/smart-goals.html
• http://www.topachievement.com/smart.html

Here’s a disquieting little secret that few of us ever really acknowledge, maybe because it’s rather painful and also an unavoidable part of the fabric of our existence in IT. I don’t know how to say it more eloquently (or less bluntly), so here goes: being in information technology is hard. In our day-to-day dealings with stakeholders, with end users, with management, even within our own ranks, it’s common to hear some pretty discouraging and recurring things, voiced either explicitly or implicitly. For example,

• “what have you (IT) done for us lately?”;
• “what do you (IT as a whole) do all day?”;
• “we’ve been asking for that system for years now and not gotten it”;
• “how can that be so hard? Why can’t you just …”;
• “at my last company we did that in just [names an absurdly short amount of time] and it worked really well.”

A major role of IT management, in my view, consists of steadfastly, repeatedly, and quietly combating these discouraging statements, of raising people’s consciousness of complexities and risk and levels of effort, of building ongoing trust, of establishing a clear and public record of excellence and collaboration. And it necessitates frequently reminding our staff not to get disheartened when we hear indications that we haven’t fully succeeded in that.

It’s normal that business expectations are high. Yet, those expectations are significantly and often unduly heightened by one of today’s realities: lots of non-IT people do “IT in the small”, working with spreadsheets, surfing countless applications on the web, even administering their home networks. But of course, this IT-like work “in the small” comes not even close to having the issues and complexity of enterprise-level systems. We in IT know this, but it’s anything but obvious to others. In essence, we’re in the position of constantly and actively having to fight some very basic resulting assumptions and myths about what we do. Those myths are often held widely throughout a company, including by senior management and boards of directors.

Here are just a few of the myths we combat:

• Software is like a toaster: you get it (or make it), plug it in, and you’re ready to roll.
• Maintenance shouldn’t take much of anyone’s time.
• Most changes to systems (e.g., to accommodate new business rules) are simple.
• Stakeholders’ role is to say what they need; IT simply has to deliver (all of it). Collaboration and careful prioritization isn’t all that necessary and boy, it consumes a lot of time.
• We should keep all data forever; disk space is cheap.
• Industry best practices don’t matter, especially if it means things will take longer. We can ignore best practices and we’ll be successful anyway.

I could (and probably will in future posts) write in detail on each of the above myths, but for now I’ll tell just one illustrative anecdote that demonstrates the kind of world view I’m discussing here.

Quite some years ago, I worked for a company that was bought by a much larger entity. At the time, we were pushing hard to finish the construction and deployment of a revolutionary (for its time) CRM-like system for use in the company’s call centers. One of our stakeholder meetings featured the following statement from a newly hired VP of Marketing: “Well, we just got bought by company X–they have call centers. Hey, why don’t we just snag some of their code?”

Everyone needs to be wary of any systems-related statement that includes words like “just” and “only”. Of course, the notion of reusing other companies’ software, when possible, isn’t something to dismiss out of hand (hence the subsequent rise of ERP packages). But the word “just”, combined with the artful word “snag,” revealed an amazingly dismissive world view about the complexities of building and integrating systems. We had a long discussion with that executive about how the word “snag” pretty much didn’t apply to the level of systems we were discussing.

So again, it’s hard being in IT, and it’s hard being the leader of IT. You need a large dollop of resilience, optimism, and stamina as your psychological armor. It’s definitely possible (indeed, necessary) to break these myths down, but it takes coming in fresh every day, ready to work hard and ready to face the same kinds of misunderstandings of the basics.

As is my frequent practice, I’m going to follow up on this post with another that talks about the flip side: the ways that IT itself can unfortunately perpetuate some of the myths I’ve been discussing.

This may be the hardest posting to write so far, but it is a necessary bookend to my other recent posts about hiring. It’s hard to write because actually firing anyone is hard: it’s emotional and full of moments of self-doubt, before and after. And I can only scratch the surface of the subject here in a normal-length post.

Terminating people is, of course, a necessary part of any senior manager’s responsibilities, but it never gets easier. It affects people’s lives, families, careers, self-esteem. I’m going to focus here on performance-related terminations, not on general staff layoffs (“RIFs”, or “Reductions in Force”, as they now seem to be universally called). And I won’t be talking too much about the nuts and bolts of how to do it most effectively or kindly; see the Lagniappe section below for some helpful tips from others on that subject.

Donald Trump aside, concluding that you’re going to terminate someone because of his or her performance is never a snap decision (or at least it shouldn’t be). Being a manager is primarily a people job, and people are, well, difficult at times. Technical people may be especially so: extremely bright, specialized, independent, resistant to coaching. Nearly everyone in a technology role has the ability to contribute in some form, otherwise they wouldn’t be in the job in the first place, or (at least) your decision wouldn’t involve quite as much anguish. Determining, conclusively, that the downsides of dealing with a problem employee outweigh the upsides of his or her contribution: that, in my experience, is the tough part.

There are really three sorts of individual that are under discussion here, when it comes to considering termination:

1. People who can’t do the job. In some cases, they may have been prematurely elevated into the position (“the Peter Principle“, however unfortunately that may be named); in other cases, the role may have outgrown them. If you can’t identify a clear path to upgrading the individual’s skills and/or temperament so that they can do the job, your decision is clear.
2. People who won’t do the job. Sometimes these are people who have simply lost their motivation or become complacent. They’ve stopped striving for excellence, stopped looking for ways to push the envelope. They’re just putting in the hours. In my view, it’s worthwhile to take at least one run at understanding and turning this behavior around.
3. People with behavioral problems affecting how they do the job.

Examples:

• spreading bitterness, gossip, negativity, or frequently manipulating others
• out-and-out HR-worthy behavior (sexual harassment, anger towards fellow workers, behavior unbecoming their position)

Many times, it turns out in these cases that it’s usually something affecting them outside the workplace, in their personal life. Every case here is different and all of them touchy; your HR department should be your closest ally as you work through the nuances.

A word of warning for the first two categories: be especially careful of the “devil you don’t know” syndrome. In your own executive urge to “shake things up”, make sure you’re not focusing on symptoms rather than root causes. In other words, does the reason for the employee’s lack of productivity possibly lie elsewhere in the organization? Perhaps they’re being whipsawed by conflicting stakeholders and themselves don’t have the seniority or perspective to recognize (or fix) that. It’s easy to make almost anyone fail, if the organization consistently neglects to give them fertile ground to succeed. Do some soul-searching here; is there anything that you could do to help this employee succeed?

The key point I’d like to make, philosophically, is that firing someone should never be done lightly. It should always be tough; it should always cause you to lose some sleep before and after. I’ve worked in companies where I’ve seen executives almost strut with pride at their own toughness, as exemplified by the number of people they’ve fired, and I reject that kind of attitude. Firing people should never be a source of pride, a “notch on one’s belt” type of thing. Citing as rationale that “we’re Darwinists here at this company” is not acceptable. It’s possible to strive doggedly for excellence while remaining aware of the huge responsibility that stems from being responsible for others’ livelihood.

The danger, you see, is that for some people, firing an employee just comes easier than having to actually manage that employee to produce good work. Yes, it’s necessary to terminate people from time to time. But termination, absent any unambiguous “for cause” grounds, should always be after solid attempts to work with the individual on whatever gaps are causing the concern. This means coaching, counseling, frequent talks. Doing so isn’t just a way to avoid lawsuits; it’s simply the right thing to do.

Lastly, expect ripples, no matter what, no matter how justified. Every one of your staff has friends and allies in the company. Even if everyone already knows that there was a problem situation with the person you’ve terminated, there will inevitably be some element of staff upheaval, concern, even paranoia. Stay on top of it.

Lagniappe:

• Chris Musselwhite, How To Fire an Employee.
• eHow.com, How To Fire an Employee.

I made two really bad hiring decisions in a row a few years back, and I have to admit that it shook me for a while. I won’t go into details about why these two hires were horrendous (although I should note that the problem was not because the requisite technical skills were lacking), but the most important thing I can say about them is that both hires happened when, with all good intentions, I departed from the general hiring process and practice that I’ve evolved to over the years.

This process doesn’t always work out exactly as described below, for scheduling reasons, but here’s what I strive for and what I’ve found tends to get great results:

• Through resume screening and phone call interviews, narrow the field to between three and five viable candidates, all of whom appear, on paper, to have the necessary experience and skills to do the job;
• Construct an interviewing group, usually with 3-5 people on it, drawn from a cross-section of the people that the position to be hired will need to deal with. When possible and appropriate, get participation from business stakeholders, not just IT people.
• Hold a brief meeting with that group, coming to a general agreement on which of them will be asking what kinds of questions (technical, background, judgment questions, etc.). It makes sense for there to be a division of responsibilities here, so that every interviewer doesn’t try to cover all the bases in a short interview. This is also a great opportunity to make sure that everyone is on the same page about what you, as hiring manager, are seeking in the ideal candidate and why.
• Pull in each of the candidates for interviews, preferably all within about a week of each other. Have the interviews, generally, consist of half hour to 45 minute one-on-one sessions with each of the members of your interviewing panel.
• Get written feedback from each interviewer, and do not have the interviewers discuss their impressions with each other. The written feedback should consist of three important areas: pros for this candidate; cons for this candidate; and a single “hire” / “no hire” recommendation about this candidate. That recommendation is abstract, meaning “could the candidate fill the position and work out effectively here.” It’s not, for example, a recommendation with respect to the other candidates. It’s possible, in an interviewing cycle like this, for every candidate to receive a “hire” recommendation from everyone (and kudos to your screening process if that happens!)
• When all the interviews are complete, reconvene your interviewing panel, with you, the hiring manager, as facilitator / moderator. Ask that each person, independently, rank the candidates in order of choice, from 1 to n. Write up the results in a matrix on the board: candidates as rows, panel members as columns. Note that this is why you asked the panel members not to discuss their feelings in advance with one another; it’s best to have independent assessments rather than the kind of “groupthink” that tends to emerge when people collude on their impressions.

Most often, you’ll see a clear consensus emerge for the top one or two candidates of the bunch. Occasionally, but rarely, the results will be all over the map, and you’ll find utterly invaluable and revealing the resulting discussion as to why that’s so.

In the end, it should be clear that you’re the hiring manager, and it’s your call. The panel is there to help you and to provide input, not to make the decision itself. This process is no silver bullet, no guarantee, no automated recipe. You may have to override the panel, or certainly one or more members on it. Make sure, going into this process, that everyone understands that reality. The best hire I ever made was an example of my having to override the “no hire” recommendation of my chief lieutenant about the candidate, and by no means did I do so lightly.

Go through this process methodically and without fail, and, if your results resemble mine, you will discover that bad mishires, while not impossible, are few and far between. You’ll also reap the many benefits of having taken a solid, team-oriented approach to hiring. Hiring may be the most important thing you do besides resource allocation (to be sure, it’s really just a species of resource allocation, one could argue). Invest the time and care it deserves.

Lagniappe

• The Wisdom of Crowds, by James Surowiecki

I plan to make a couple of posts surrounding the very thorny issue of hiring (and firing) IT staff. To start off, here’s a recommendation letter I wrote a couple of years ago, at the request of a former employee. It shows at least one executive’s (i.e., my own) view of what matters in a job candidate most of all, and how certain characteristics can (sometimes, not always) make up for lack of background or experience. I’ll call him Harry. What I sought (and found) in Harry doesn’t necessarily pertain equally to all IT positions, but I offer it for consideration:

I have known Harry for over four years, ever since I hired him into the role of Project Manager at XYZ, where I was the VP of Information Technology.

Harry didn’t have an IT background, although he had certainly worked in and around high tech before. I went into the hiring process believing that I very much needed someone specifically with an IT operations background, so Harry’s resume, even though he came enthusiastically recommended by another XYZ executive who had worked with him before, didn’t make it into the interview pile initially. Hearing this from our HR recruiter, Harry then wrote me a polite but assertive letter, pointing out, with specific examples and in characteristically articulate and very persuasive fashion, his myriad skills, ability to be a quick study, and absolute passion for any task he takes on. I’d seldom encountered such a persistent and articulate individual, and as I reflected on what I most wanted in the individual who would fill the open position, I decided that those characteristics counted, and counted a lot.

I was anything but wrong. In my subsequent experiences with Harry as an employee, I found out that he exemplified all those traits and more, including the following:

• Ability to create order out of chaos, taking on sometimes vaguely formulated assignments, defining meaningfully what was really needed, and then delivering it beyond my expectations;
• Ability to reason, thinking out all the angles;
• Ability to forge consensus and, even while pushing hard on people to get things accomplished, still be well-liked, even by my (extremely) ornery sysadmins and DBAs;
• Versatility; ability to be a quick study, taking on tasks where he initially had zero background;
• A solid work ethic. This was an individual who “showed up,” organized his tasks, and simply got things done;
• Ability to accept feedback and coaching, adjusting his work as a result;
• Ability to hang in at an organization through ups and downs;
• Self-educating (reading 1-2 business-related books a month)

In short, this was an exemplary employee, exactly the profile that I wish I could hire each and every time in terms of basic, raw ability and attitude alone. And his actual output once he had the job? Harry exceeded my expectations every single time. Interestingly, I’ve actually hung on to some sample documents that Harry created, not so much for their specific content as for their overall quality and ability to serve as a compelling example as I push to get the best from my current employees. “Give me something like this,” I tell them.

If I currently had a suitable position available in my organization, you can be sure that I’d be trying to hire Harry myself, because his presence strengthens any company.

Lagniappe
I recommend nearly any book by Joel Spolsky, as I do with anything by Steve McConnell as well. This book is a sterling little gem with tons of wisdom and specific, actionable examples.

• Smart and Gets Things Done: Joel Spolsky’s Concise Guide to Finding the Best Technical Talent

One of the most frequent questions I’ve gotten after starting this blog pertains to how one can work up to the CTO or CIO role in IT. This isn’t all that easy to answer, other than with some platitudes. Every career is different; every individual takes a separate path. I can’t exactly recommend to people that they take the path that I took, because there were certainly some odd stutter steps and digressions along my route. That said, I do indeed have some biases and thoughts about how a motivated, talented IT professional can position herself or himself for a top management role in IT.

• Get broad. Strive to understand ALL of IT: development, quality assurance, operations, project management, architecture, user experience, PC help issues. And, of course, there’s no better way to understand those areas than to do some kind of rotation into each and every one of them, formally or informally. Diversify yourself. Doing so fully may require moving companies. One of my favorite Tom Peters’ quotes is “‘Repot’ yourself every ten years.” With respect to high tech, it needs to be more frequently than that.

• Get away. (Meaning, get away from relying on the technology knowledge that, in essence, limits and pigeonholes you today). Chances are, you’re an expert in one or more technologies, the “go to” guy or gal, the one who can run rings around everyone else technically in that area. Get ready to leave it behind, at least as the core of your day.
• Get mentored. Figure out who knows more than you do, higher up the chain. Not only does this foster an always-nice-to-have sense of humility, it’s also a useful exercise for confronting your gaps and figuring out how other people have filled their own similar gaps. Find someone. Ask for advice, feedback, tips on next steps.
• Get religion. So to speak, of course. Absorb the basic truth that IT itself needs to be the main “service-oriented architecture”, metaphorically speaking. That’s service in a business sense, to the rest of the organization. This obvious and incontrovertible fact seems to be lost on at least half of the IT people I’ve known.
• Get involved in customer-related and business-related projects. Interface with internal users in formal and informal ways. Get to know their concerns, their problems, their way of looking at things.
• Get savvy, financially: A long time ago, I read a magnificent slim volume, now sadly out of print, called Understanding a Company’s Finances: A Graphic Approach, by W. R. Purcell, and received a college course’s equivalent of an education in finance. If you also have gaps in this area, find the equivalent (see below for some ideas), and study up. Follow your company’s communications on financial results; read the annual reports and regular SEC filings.
• Get the word out. Communication as an ingrained ethic is one of the largest gaps, quite typically, in IT, and you’ll need to get good (and frequent) at it. “Always be publishable”: I learned this marvelous apothegm from someone who worked for me. By this, he meant always have readily at hand the basic elements (as in the Five Pillars, actually) that show how things are going, so that you could (for example) generate a status report at the drop of a hat.
• Get altruistic: Focus on your own people’s career growth. It’ll come back around. Thinking about others benefits you.
• Keep up technically. It’s a fire hose out there, trained at your eyeball. Pick and choose the key technologies, and get more than a dilettante’s familiarity with them. Yes, I realize that this seems to contradict the “get away” point above. Live with it. Part of ascending to the CIO/CTO role will entail exactly that kind of ambiguity in your life.

Lagniappe:

• Tom Peters’ strategies for pursuing good luck. Note that I don’t necessarily agree with many of these, but they’re definitely worth a read!
• Managing by the Numbers: A Commonsense Guide to Understanding and Using Your Company’s Financials : An Essential Resource for Growing Businesses
• Financial Intelligence: A Manager’s Guide to Knowing What the Numbers Really Mean

One area where I feel I’ve learned and grown in my career is achieving a much clearer understanding on how to communicate with upper management. Most advice along these lines tends towards simply warning against overuse of technobabble, and I can’t disagree with that. But there’s a lot more to successful communication than simply that, and I’d like to describe here a few ways to avoid the pitfalls that I’ve seen IT people (including myself) fall into in these situations. None of these ideas is especially new or difficult, but they don’t always seem to come intuitively to IT folks.

When presenting a problem and/or proposal to upper management, keep in mind the following:

• Outline the problem as clearly and succinctly as you can, with appropriate quantitative facts (metrics) and business-related impacts wherever possible, to demonstrate why you’re bringing it to their attention.
• Do it in writing, not just verbally. If you’re not as comfortable writing as “talking through” an issue, then you need to get comfortable. See my previous post on the importance of writing.
• Be succinct. Keeping to one page is a great goal for the bulk of the presentation. Anything longer than 3 or 4 pages will simply not get read.
• Avoid hyperbole/overreaction. Technology folks are unfortunately known for overstating things. It will help neither your cause nor your career if you come across as Chicken Little or the Boy Who Cried Wolf, let alone as Howard Beale.
• Marshal your facts carefully. Facts beat strong opinions every single time. Don’t make your presentation just a collection of strongly stated opinions. Present the facts as neutrally as possible, with relatively little advocacy besides your recommendation.
• Which facts matter most to executives? Mostly two major categories: direct financial impacts of the solution you’re presenting, and business/customer impacts. What facts matter least? Any notion of a technology being “better” or “newer”, except when you can translate that betterness into a form of measurable financial, business, or customer-related impact.
• Offer 2-3 alternatives as solutions, discussing the pros and cons of each, and then present your recommendation and your reasoning. Do not present a one-sided pitch that indicates that only one solution is remotely fathomable. Even when that’s the case.
• Provide background material, but in an appendix. There’s definitely some value to having meat and volume (“thunk factor”) to back up your statements and recommendation, but you don’t want to include that morass of detail in the body of your presentation.
• Don’t keep selling. Whenever possible, let your audience draw its conclusions, rather than having you continue to advocate.
• Always answer the obvious and ubiquitous questions they’re going to ask, before they ask them. Here are the main ones you’ll hear again and again:
  • “How much will this cost?”
  • “When can we have it?”
  • “What else will get pushed aside if we do this?”

Even if you follow all this advice, in the end we all need to recognize that communicating the full impact and flavor of technical matters can be difficult and murky, even with the best of intentions and the most adept skills. In short: people’s eyes tend to glaze over when confronting the detail they truly need to understand in order to help make a valid decision. IT people, faced with that lack of interest and comprehension, can often err on the side of throwing up their hands, avoiding communicating altogether, and simply taking independent action. I don’t recommend that. Turning around the famous declaration from War Games, “the only losing move is not to play the game.”

Lagniappe:

At times, you may need to communicate the nuances of a technical situation obliquely and through creative use of metaphor, rather than through mind-numbing, technobabble-laden directness.

At the early age of 13, I learned that some things were best expressed in parables, especially if they were difficult to express or comprehend. To that point, I read a fascinating anecdote back then that reverberates in my mind decades later. It came from page 49 of a slender red volume of mathematical and scientific anecdotes (yes, I was a strange child), called The Other Side of the Equation, by Howard W. Eves, (c) 1971, Prindle, Weber & Schmidt. This book is now available as part of a larger volume that includes material by Mr. Eves.

Here’s the anecdote, and in the spirit of my advice above, I’ll let it speak for itself:

Einstein and his blind friend

Not long after Einstein’s arrival in Princeton he was invited, by the wife of one of the professors of mathematics at Princeton, to be guest of honor at a tea. Reluctantly, Einstein consented. After the tea had progressed for a time, the excited hostess, thrilled to have such an eminent guest of honor, fluttered out into the center of activity and with raised arms silenced the group. Bubbling out some words expressing her thrill and pleasure, she turned to Einstein and said: “I wonder, Dr. Einstein, if you would be so kind as to explain to my guests in a few words, just what is relativity theory?”

Without any hesitation Einstein rose to his feet and told a story. He said he was reminded of a walk he one day had with his blind friend. The day was hot and he turned to the blind friend and said, “I wish I had a glass of milk.”

“Glass,” replied the blind friend, “I know what that is. But what do you mean by milk?”

“Why, milk is a white fluid,” explained Einstein.

“Now fluid, I know what that is,” said the blind man. “but what is white?”

” Oh, white is the color of a swan’s feathers.”

” Feathers, now I know what they are, but what is a swan ?”

“A swan is a bird with a crooked neck.”

” Neck, I know what that is, but what do you mean by crooked ?”

At this point Einstein said he lost his patience. He seized his blind friend’s arm and pulled it straight. “There, now your arm is straight,” he said. Then he bent the blind friend’s arm at the elbow. “Now it is crooked.”

“Ah,” said the blind friend. “Now I know what milk is.”

And Einstein, at the tea, sat down.