Dave's Whiteboard

One of the lesser-known treasures of Washington DC is the Folger Shakespeare Library, home to scholarly research, to intriguing exhibits about the Elizabethans, and to the Folger Theater, which presents at least three plays each year (this season’s were Henry VIII, The Comedy of Errors, and Edmond Rostand’s Cyrano).

And every April the Folger throws a birthday party for that glover’s son from Stratford (none of that elitist Oxfordian piffle, thanks). This year’s party is next Sunday, which was as much excuse as I needed to post this now instead of April 23rd.

Will never manages to show up (I’ve watched for him), though there’s a red-headed woman people insist on called Elizabeth I who does take part, making pronouncements and cutting a ceremonial cake.

(You can number monarchs as you see fit, but Henry VIII’s younger daughter was never queen of Scots, so to me that “Elizabeth I” means a certain wild and crazy grandmother with a lot of corgis.)

So here’s…

William Shakespeare on:

Career choice

To business that we love, we rise betime, and go to it with delight.
(Antony and Cleopatra)

Consulting

When I was at home, I was in a better place, but travelers must be content.
(As You Like It)

Email (or, perhaps, spam)

When sorrows come, they come not as single spies, but in battalions.
(Hamlet)

Needs analysis

Modest doubt is call’d the beacon of the wise.
(Troilus and Cressida)

The systems approach

If you can look into the seeds of time and say which grain will grow and which will not, speak then to me.
(Macbeth)

Professionalism

Have more than thou showest; speak less than thou knowest.
(King Lear)

The cult of leadership

Fortune brings in some boats that are not steered.
(Cymbeline)

The cult of thought-leadership

Reputation is an idle and most false imposition; oft got without merit, and lost without deserving.
(Othello)

Fads and bandwagons

The fashion wears out more apparel than the man.
(Much Ado About Nothing)

Conference keynotes (or, perhaps, blogging)

Brevity is the soul of wit.
(Hamlet)

I’ve been trying to get better control over the projects I work on and the data related to those projects.  So this isn’t me avoiding work; this is me reprocessing by talking about the challenges I felt and then about how I’ve tried to address them.

What I had wanted to do was:

• Reduce my paper clutter
• Reduce my digital clutter, which felt nearly as heavy
• Reclaim my workspace, both physical and virtual
• Seize more of the potential of electronic notes than I had so far

That sounds like mainly organization and housekeeping, but if you rise above the roadway, it’s managing.  I wanted to do better at managing both work and non-work projects.  I figured if I could accomplish any of those things in the list, and especially more than one at once, I’d be far more likely to get a project done.   Or at least get it moving.

What would matter?

At GE, we talked about CTQs: the critical-to-quality items that represent a customer’s view about what’s most important for a product or service.  My own CTQs for doing better included:

• Retention–whatever’s in the system is ultimately in my own custody, not solely a wisp in someone else’s cloud bank.
• Ubiquity–a system that I could use in my office, on a client site, or somewhere else.
• Dwell time–an increased ability for me to stay with the task at hand.

Was that a wrong note?

For some time, I’ve used Evernote, which modestly says you can capture anything, access it anywhere, and find things fast.  (Optional side trip: Evernote’s 90-second intro: http://www.youtube.com/watch?v=jQP0gkPnEcY .)

Evernote lets you create individual notes, store them in virtual notebooks, and access them on your own computer, from any computer, or through a smartphone–hey, ubiquity!  The database with your notes is stored not only on their servers (which you don’t own) but also on your PC, with automatic synchronization. You can cloudify if you like, but having a local copy of the database helps satisfy my CTQ for retention.

I’ve used Evernote for more than two years, mainly in that unfocused, plunge-right-in, that’s-kind-of-cool way. (A particular favorite: because I sketch a lot of ideas on flipcharts, I love being able to snap a picture, transfer it to Evernote, and later search for text in the image.)

Most of the time, though, I was also making multiple notebooks and creating a myriad of tags.  When it comes to tagging, some people believe that enough is enough and too much is plenty, but for me there’s a real problem with diminishing returns.  (We’ll skip over the issue of typos, as well as the pluralization dilemma: Is the tag finance or finances?)

I’d been cruising a predictable arc, from an initial everything-fits enthusiasm to a distressing suspicion that I’d reinvented the junk drawer.

To be is to be done?

On a separate track, I’d been reading David Allen’s Getting Things Done.  I approached this book with hesitation, or more accurately evangeloskepticism, because of the… well, let’s say, the ardor of some GTD adherents.  The people who always say “GTD.” If they were Apple users, they’d be the ones who care about the code name for the next operating system.

Messy and distractable I may be, but I appreciate the advantages of a system, even if I sometimes appreciate it from afar.  Allen’s approach is more about thinking systematically than about particular tools–though you can, if you desire, buy a set of 43 plastic file folders for only $39.95 (plus shipping).  So I’ve been applying elements of that system, and adjusting the way I work with my paper files and with Evernote, and I’m happy with how the results look so far.

Different ways to see your project

Two useful, intertwined concepts: first, a task is something you can complete in a single chunk of time. ”Peel the carrots” is a task.  If you’re like me, “do the grocery shopping” is also a task; I may have a big list of items, but I get them in one trip.

At my house, we have a cluster of grocery-related tasks: plan dinner  for the week, check the ingredients we need, build a grocery list, shop (ideally, with the list).  Getting Things Done calls such a cluster a project: “any desired result that requires more than one action step.”

Which leads to the second useful concept: you don’t do a project, you do the next step.  From a manage-your-work perspective, think of the project as the goal you want to achieve (groceries purchased, workshop delivered, kitchen remodeled).  You revisit the project to generate thoughts about what the next steps might be.  When you don’t have any more steps, the project’s done.

So I create what I call a project page, which is a highfalutin name for a note on which I put a short description of the goal of the project, along with a timeframe (however nebulous) and the tag I’ve chose for that project.  I’ll also use the project page to jot notes about ideas related to the project.  That means the project page becomes a kind of greenhouse where idea seedlings can germinate until they turn into action steps.

Action steps (things I can do) become separate notes, each tagged as part of the project.  So do reference items, like email that I forward to Evernote, making the contents of the email more readily searchable.  So do things like PDF documents, which can be dragged into their own note.

Now I have a Projects notebook.  I use Evernote’s filtering tools to control what I see when I click the Projects notebook, like this:

Previously, I had more than a dozen project-specific notebooks in that sidebar. And if I create a new notebook for any multi-step effort I have (even small one with long duration, like “get a digital copy of the LP that Mom has no turntable for”), I could easy have three or four dozen.

This works better.  And I can do the same sort of selective display across multiple notebooks.

If it’s not a step, it might be a reference

David Allen suggests putting all your project-support material (things that don’t require an action but that you want to retain) into a reference file.  He leaves the form of that file up to you, though he’s quite the fan of a single, alphabetical-order, paper filing system.  I have those, but I prefer keeping digital (i.e., searchable) copies, which now go into a Reference notebook.

Allen might be less in favor of a separate location for the work-specific diaries that I call project logs, so if you see him, don’t tell him that’s what I have.  I tend to make the logs for large projects; for small ones, I’ll jot ongoing notes on the project page.  Not necessarily consistent, but, oh, well.

More than a third of my Evernote items are in the REFERENCE notebook.  To me, this makes sense.  For active projects, a lot of the relevant material isn’t a trigger for action; it’s project support.  It’s reference material.

If an item appears useful to more than one project, I apply multiple project tags.  That way it’ll show up in project-specific searches.

I also have a Project Archive notebook.  When I complete a project, I select all its items from the Projects notebook and move them to the archive.  Why?  Because that’s what I’ve always done.

In my corporate, cubicle-based days, the bottom of my four-drawer file was labeled Attic. It became a combination of historical record, reference room, and security blanket.  (I’m no hoarder, though;  every year or two, when it got full, I’d weed it back by a third or so.)

The Projects notebook and the Project Archive account for another 20% of my notes, which means that together with Reference, half of what I keep in Evernote is in just three notebooks.

Not that there’s a prize for Fewest Notebooks Used–though if there were, Ruud Hein would be a real contender.  He wrote an Evernote GTD How To that inspired me to experiment and adapt.  (I also like his tone and his pragmatism.)

Speaking of pragmatism, this post is long enough.  I have a follow-up underway with some more examples of what I’ve tried and what results I’ve gotten.

Evernote examples are my own.
CC-licensed images: dwell time by Owen Blacker.
Junk drawer by windsordi / Di Bédard.
Archive of papers by Ben McLeod.

A discussion on lrnchat included lots of comments and questions about data collected about people’s performance, particularly in training, testing, or learning situations.

I’m always inclined to say you can’t do evaluation if you don’t measure, which means I quickly exasperate people who think evaluating is measuring.  For them, perhaps it is.  For me, measurement is a kind of quantification (Conor weighs 187 pounds, Raylene booked $4.7 million in  sales last year), while evaluation is your comparison of the measurement with some standard (Conor is overweight, Raylene made 125% of quota).

That seems straightforward, except for a depressing tendency to assume we’re all using the same standard–and that tendency’s sidekick, the assumption that our measures take in the right requirements.  In that lrnchat discussion, Jane Bozarth mentioned an online course where the instructor based his evaluation in part on the number of comments a student posted.  Naturally, someone set out to put up 100 meaningless posts.

What to do?  Well, you could turn to Tom Gilbert, who mused about what he called the dimensions of performance measuring back in 1978 (and probably long before that).  He saw three classes (or requirements) for measurement: quality, quantity, and cost.

“When we measure an accomplishment, any one or more of these requirements may be relevant, and one of our principle tasks is to identify them.”  In other words: figure out what’s important about the desired performance, which will help you determine what to measure and the standard to use.

Gilbert saw three possible aspects to each of these dimensions.

Quality, for instance, can involve:

• Accuracy–how well does the accomplishment match a model without errors?
• Class–is the accomplishment superior to most in some way beyond accuracy?
• Novelty–does the accomplishment demonstrate originality?  Does it embody features or aspects that distinguish it favorably in particular dimensions?

Quantity or productivity can involve:

• Rate –accomplishments per unit of time.
• Timeliness–accomplishment by some end point.
• Volume–accomplishment when time is not a significant factor (e.g., sales per month).

Cost:

• Labor–the amount spent for the labor and associated items directly related to the accomplishment.
• Material–supplies, tools, equipment, and so on.
• Management–the cost of supervision, administration, and support related to the accomplishment.

As Gilbert points out, the requirements are relevant only when people’s accomplishments vary based on the requirements.  So running a 10K doesn’t normally involve accuracy.

Framing a custom home involves timeliness, and could possibly involve rate, but most often novelty wouldn’t be a requirement. However, class as a quality measure might apply, if the craftsman needs to adapt quickly and successfully to changing conditions: “Leo, this suite needs to be wheelchair-accessible.  Can we move the doorway?”

I think it’s useful to have these categories in mind regardless of the type of work you’re considering.  But don’t take my work for it.  Here’s Gilbert:

…Jobs which seem unmeasurable are actually mesurable once we identify their accomplishments and relevant requirements.  Many jobs that people say cannot be measures (“you can’t measure show-horse breeding–it’s an art”) seem that way only because we are thinking of behavior rather than accomplishment.

How would we measure the behavior required in selecting good breeding stock?  I haven’t the faintest idea.  But we can measure results…

There’s more to say on this topic, but this will do for a start.

CC-licensed photos:
Measurement (of coffee) by flyzipper / Steve Michos.
Evaluation (of accomplishment) by afternoon / Ben Godfrey.

Guy Wallace said this on Twitter a while back:

I always wanted the Client to own the analysis & design data rather than me. I don’t convert their words to mine – or to Noun-Verb patterns.

He’s summarized a lot of good ideas about the consulting process.  And his phrase about noun-verb patterns reminded me of  two principles I keep in mind when dealing with performance problems (and with their much-smaller subset, training problems):

• Behavior you take with you; accomplishment you leave behind.
  (That’s Tom Gilbert talking.)
• A result is a noun; doing is a verb.

“Doing” is a good example of a fuzzy label, and that’s part of why I’m writing this.  When someone starts talking about what people do at work, it seems to me it’s easy for their focus to shift.

Sometimes when someone’s talking about what people do at work, he might mean the actions they perform, the processes they go through.  That’s how a person works.  It’s the doing part of what they do.  It’s a verb.

If you need to repair the water damage in your basement, then what the contractor does at work–the verbs he carries out–are things like measuring dimensions, testing materials, inspecting damage, examining structures, considering costs,  and calculating square footage.

Alternatively, when someone’s talking about what people do at work, he might mean on the things those people produce, what they accomplish–the result of their work.

A result is a thing.  It’s a noun. That’s the case even in so-called knowledge work and in service occupations. From this angle, what the contractor does–what he produces–is an estimate for the job.  Or a list of suggested approaches (on paper, or  verbal), or a series of questions for you to ask yourself–a kind of contractor’s initial consultation.

That’s what’s left behind when the contractor leaves.

I think this behavior/accomplishment distinction is crucial when you’re talking about performance on the job.  Companies and organizations are crammed to the institution rafters with ritualized behavior that continues in the absence of any real accomplishment except that the behavior got done: sales people are required to make 30 cold calls a day–not because of any company data about the effectiveness of cold calling, but because Veronica, the sales director, had three early successes from cold calls.

Working from the other direction, Umberto, who handles accounting for your department, tells you to charge the new software under “training materials.”  Not that the software is going to be used for training–but your boss has authority for twice the expenditure under that category than he has under “computer resources.”  Changing the accounting codes is such a slow process that not only would the software be out of date, but Umberto and you would both be retired, before it happened.  So Umberto’s helped accomplish a result (software deployed) but if caught you and he will both be sentenced assigned to Purchasing Refresher Training.

When you focus on results, you can work backward through the factors that influenced those results.  Sometimes (most of the time, actually) you’ll find that “lack of skill or knowledge” on the part of the performer is not the major hindrance to accomplishment.  That, of course, means you’ll likely be wasting your time (and the performer’s) if you try to resolve the situation through training.

As Guy Wallace said, you want the client to own the analysis and the design data.  I’ve said before that while I myself try not to use “understand” as a learning objective, I might go along with the client’s use of it, so long as the client and I can agree on what it looks like (what the results are) when someone “understands” how to perform a FEMA elevation certification.

Now, if the client is hell-bent on ignoring any data that doesn’t say “deliver training,” I’m pretty sure I’m not the right person to be working with that client.

Images adapted from this CC-licensed photo by Sebastian Werner / blackwing_de.

An article by Adam Bryant in the New York Times deals with Google’s “quest to build a better boss.”  Bryant looks at an effort by Google to mine its own data and figure out what made people better managers.  The list of behaviors, Bryant says, looks “forehead-slappingly obvious” :

• Have a clear vision and strategy for the team.
• Help your employees with career development.
• Be a good communicator and listen to your team.

(From the Times, a fuller list of eight good behaviors and three pitfalls for Google managers.)

More important is the source of the ideas, and especially their relevance to managing at Google.  The company collected data from a range of observations about its own managers: performance reviews, feedback surveys, and so on.  They coded that data to help uncover patterns.  They conducted interviews with managers to collect more data.

One thing they found that they hadn’t expected: a manager’s technical expertise ranks “dead last” among the eight behaviors they uncovered.

What employees valued most were even-keeled bosses who made time for one-on-one meetings, who helped people puzzle through problems by asking questions, not dictating answers, and who took an interest in employees’ lives and careers.

One drawback to lists of management behaviors like this one is a sort of horoscopic skew: you skim the list and decide that the ones that stand out are the ones that apply to you.  So a person who prides himself on his technical background might believe that as manager of technical people, he or she needs to have high tech skills.

That may be true on a project team, but to the extend you’re really managing, I don’t think so.  Think of the tongue-in-cheek definition of manager as “someone who gets other people to do the work.”  In a sense, that’s true: the manager is a kind of executive producer, helping to create the conditions in which the group can best accomplish its goals.  An often-overlooked aspect of that is acting as a non-judgmental resource to help people figure out how to solve their own dilemmas.

This is one of the main points of a classic article by William Oncken, Jr. and Donald L. Wass, Management Time: Who’s Got the Monkey? (PDF).  They compare business problems to monkeys, and discuss ways in which subordinates try to put the monkey on the back of their manager.  Here’s a manager who’s working at empowering his staff (which is where most of the problem-solving should occur):

“At no time while I am helping you with this or any other problem will your problem become my problem. The instant your problem becomes mine, you no longer have a problem. I cannot help a person who hasn’t got a problem.

“When this meeting is over, the problem will leave this office exactly the way it came in—on your back. You may ask my help at any appointed time, and we will make a joint determination of what the next move will be and which of us will make it.

“In those rare instances where the next move turns out to be mine, you and I will determine it together. I will not make any move alone.”

- Harvard Business Review, Nov.-Dec. 1974

Granted, you need to ignore a certain assumed hierarchical bias in HBR articles.  Even so, I’d argue that this, too, is head-slappingly obvious.  But “obvious” is often an after-the-fact label.  It’s easier, more dramatic, and perhaps more fun to pound the desk, to shout, and to act in general like a BlackBerry-toting gunslinger than to do the persistent work of helping people achieve the best results they can.