Presenting to Managers

From Edward Tufte's one-day class "Presenting Data and Information," my key epiphany is this:

Your audience is not dumb; they are busy.

There's a common "wisdom" that we need to dumb-down presentations to managers, but this is a hindrance to your message.

No, instead, imagine you are really busy, and you have a lot of demands on your time and, more importantly, your attention. In that mindset, what information do you need, and presented in what order, so that you can make a decision?

As technical people, we like puzzles. We like climbing over multiple steps to discover an answer. We are at times prone to structuring our presentations this way, too: Here's a neat problem, and here are all of the things I tried before finding an answer.

This is a waste of time.

Professor Tufte's argument architecture is this:

• Problem
• Relevance (why it is relevant)
• Solution

Note that there is no time spent on how we came to the solution. Note also that there is no step for dumbing down the problem or the solution.

Your audience is smart, but busy.

My Kind of Cleaning

In answer to my previous puzzler—that was a real cliffhanger—here's the walkthrough for cleaning my route. Recall that this was my first time, so I'm describing what it was like, not giving instructions. Learn to climb from a qualified guide. I mean it.

First, think through the whole scenario and collect the gear you will need. Realizing you are one biner short when you are up in the air is too darn late. I needed two slings of webbing, each with its own locking-gate carabiner, plus an extra biner. For each sling, I used a girth hitch to attach one end to the front of my harness, then clipped the loose end with a biner into a gear loop at my hip. I hung the spare biner in a gear loop, too.

Next, you climb on top-rope back up to the anchor, and ask your belayer to "take" (take your weight; hold your rope locked off). You clip each sling into a hanger, to set up your personal safety system, and screw shut the locking gates of the carabiners. At this point, you should be held to the rock by your slings and not depending on the rope. Test this by asking for some slack, and noting that, as the rope goes slack, your slings become taut and bear your weight. Then you can ask your belayer to take you "off belay."

Now that you're set to hang out here all day, tie a backup knot to make sure you don't lose that dang rope: Grab a bight of rope and tie a quick knot and clip it into the spare carabiner. Because you're about to do the exact opposite of what your frightened little monkey brain would want you to do—you're going to untie the rope from your harness. And if you drop it, you will get to hang out here all day.

So, yes, untie the knot. The umbilical figure 8 from which you so often hang your precious hide. Untie it.

Remove the rope from the quickdraws and run it through the bottom links of the chains. We use the chains for lowering from the final climb out of necessity, but avoid using them all the time in order to minimize the erosion we subject them to. Retie your figure 8, untie the keeper knot, and retrieve your quickdraws.

Hoist yourself up a bit and ask your belayer to take, so that you can confirm that you are back on belay and the rope will hold your weight. Unhook your personal safety slings and clip them back to your gear loops to keep them out of the way. You are ready to be lowered to terra firma.

In addition to being a MYST-like brain teaser, I found route cleaning to be a good barometer of my mental state. Late in the afternoon, I'm hanging from the slings, and I think, "Okay, I have no idea what to do next... Must be time for dinner."

And it was. So we three girls drove back into town and ate three cheeseburgers, and they were very, very good.

Climbing Logistics

Great day of climbing yesterday with SheClimbs on Zoe's Wall at Reimer's Ranch--never too hot, patches of sunshine and blue sky, great company. I cleaned a sport route for the first time, and this was really neat. It's just like a MYST puzzle. I'll set up the challenge for you...

Goal: Before your climb, a teammate lead-climbed the route and set up an anchor for you at the top, using some of your equipment. Now you need to climb up there, retrieve your equipment, and get safely back down.

Setup: At the top of the sport route, there is an anchor system. This system comprises two hangers, bolted into the rock, and a few links of chain hanging from each hanger. Your lead climber clipped a quickdraw into each hanger, and ran the rope through the bottom carabiners of the quickdraws. (Here's an anchor using a rope instead of two quickdraws.) This allows many climbers to use this rope and anchor while minimizing the wear and erosion on the chains. But you want your quickdraws back.

Constraint: You're 25 or 30 feet in the air. You climbed that high using your own muscle power, and you've been climbing for hours already. You're tired. You don't want to fiddle with ropes and clips and slings while hanging by the tender fingertips of one hand above the rocks and trees below.

Solution: What to do? (Open the spigot to drain the water from the chest, close the spigot, fill the tower with water to make the chest float up...) I'll let you think about it for a bit. Perhaps if you look around, there might be some more gear here at the bottom that you could click on.

The problem-solving challenges is one of my favorite things about this sport. Hanging with great people and the sense of accomplishment are two more. You really make a connection with the woods when you're that close to the rock.

Convincing through Understanding

People resist change out of fear. Winning people over to change requires identifying, discussing, and collaborating to resolve their fears.

I had the opportunity last week to talk with a small software company about what's exciting about scrum. My battle scars all come from years in a BDUF (Big Design Up Front) shop, so I was non-plussed to find that this small, smart, co-located group was looking to scrum because they craved more structure. It's an important reminder: Agile methodologies are processes. They're just processes for adapting to change, instead of anticipating and squelching change.

Not everyone in the audience was a fan of scrum. Some were skeptical, or intrigued but full of questions, while others were adamantly opposed. A totally different company from the one I work for, yet the objections were eerily similar:

• Maybe that works for a [big/small] company, but it won't work in our [small/big] company.
• More meetings?!
• We don't have enough resources for [testing/support/pair programming/a Scrum Master who isn't a developer].
• Constant feedback? That's so disruptive. They keep changing their minds. I'll never get anything done if I talk to them every day.
• If you build the architecture as you go, what if you get it wrong?
• When do you create documentation?
• Who prioritizes the requirements? How do you prioritize? How do I get infrastructure and foundation pieces onto the list?
• How do you know if you're on time?
• I prefer my private cubicle. I don't like talking with people all the time. I'd rather be efficient than social.

You can hear the fears behind these objections if you listen openly:

• I know how to do what we do, and you're talking about changing how we do what we do. That's going to make me look less competent.
• I'm stressed about deadlines and my workload, and it sounds like you're increasing my workload.
• I'm constantly harrangued about dates and deadlines, and you're proposing a deadline every [1 to 4] weeks. That sounds like incessant stress.
• My past conversations with my [customer/user/business partner/product owner] have been abusive and dysfunctional. Every time they tell me what they really want, I have to disappoint them because of resource constraints. They have no faith in our estimates of effort or duration. I can't convince them to invest time in supportability, maintainability, or scalability requirements. There's no love here.
• Face it, I'm an introvert. Why do you want to force me to be extroverted?

Once you're hearing what people are really telling you, then you can discuss the underlying concerns. Together, you and your audience can collaborate to clear up those concerns. What was initially a roadblock—a rigid resistance to change—becomes a challenge to be solved together.

I feel like a big cheese monkey for quoting The Seven Habits, but it's elegant and succinct on this point: Seek first to understand, then to be understood.

A little light reading

John Long's Climbing Anchors, a technical guide to setting protection equipment into rock, could be subtitled "50 ways to leave your lover."

Life-saving, perhaps, but not relaxing. Sheesh.

Kitchen Ah Has

Some incredibly useful forehead-slappers I have learned from Mr. Alton Brown...

Heat-proof gloves for oven mitts: Go to the hardware store and look for welding gloves. They're leather, far more protective than kitchen-type oven mitts, and they have fingers, so you can wrangle hot, difficult things like an evolved primate.

#16 ice-cream scoop for muffins: In art, my medium is muffins. Scooping the batter into the muffin tins is always the most difficult step: time-consuming, likely to spill on the counter, wispy scraps of batter around the outsides of the tin burn and affect the flavor, and you need to do it fast so you don't lose all the fluff from your baking powder. Enter: ice-cream scoop. A #16 is the perfect volume, and the thumb trigger dumps the batter right on target.

Egg slicer, with blades, for mushrooms, strawberries, what-have-you: I used to think egg slicers were a unitasker, but I just wasn't thinking creatively enough. If you get one with metal blades instead of wimpy wires, you can quickly slice anything small and squishy. Which includes the tips of three fingers in one efficient pass, so watch yourself. *sniff*

Cast iron skillet: Somehow I took it into my head that cast iron is difficult to clean or care for or cook with. I don't know where I got these ideas, because they are completely wrong. My cast iron skillet is the most used thing in my kitchen. Okay, to clean and care for: Follow Lodge's instructions to season it once; from then on, clean only with water and a scrubbie, dry it right away, and coat it from time to time with a little fat (cooking spray, butter, or... bacon!). The easiest way to clean it is to dump water in it right after you take food out of it (deglazing, the foodies call this), scrape off the bits with your spatula, and dump the water out. The heat of the pan will probably dry it in a hurry, or you can wipe it with a towel if it has cooled. Then, as far as cooking goes: For nearly every application, the weight and heat inertia of a cast iron pan will make you so happy. With a wimpy aluminum pan, as soon as you add ingredients, you cool the pan way down. You'll never get a nice brown crust on a steak with an aluminum pan. And with teflon pans, you have to be so neurotic about which utensils you use and how you wield them. Mr. Cast Iron is not afraid of anything in my kitchen drawers.

I could watch Good Eats all day, and I have no self control when there are Alton Brown DVDs in the house. I like the nerdy food science, and I like his "Anyone can cook!" approach to cooking instruction, but my favorite parts are the world-altering revelations of new ways to use kitchen implements. "Holy cow, why didn't I think of that? This changes everything..."

Do you have any Ah Has?

What tools do you use?

I've been meeting with other teams at work who are curious about how my team is using scrum. The most common first question is: "What tools do you use?"

I've finally hit upon the answer. Previously, this question had been so daunting to answer because it is inherently the wrong question, when you're just starting out. At least, if you translate "tool" to mean "software application." eScrum or Mingle or VSTS does not make you agile. Your philosophies and your strategies make you agile.

Here are the tools that we use:

1. The Agile Manifesto.
2. Shared sense of ownership, where developers, testers, and business people have an equal stake in, and equal responsibility to, the success of the project. We're all pulling together.
3. Rigorous software engineering practices, especially source control, continuous integration, readable (soluble? grokkable?) code, and automated unit tests.
4. Communication. All the damn time. As much like face-to-face as you can manage. We do our best with a globe-spanning agile team; if your teammates all reside in the same city, then for goodness sake take advantage of that luxury and meet in person.
5. Frequent feedback, in many different forms. CruiseControl always tells us the health of our build; testers are testing functionality every day; business partners are reviewing and providing corrections all the time. The elapsed time between making a change and knowing if it is good is as short as possible.
6. Retrospectives, where the team talks honestly and candidly about what is going well and what could be improved, and then takes direct action on those improvements. Contrast this with end-of-waterfall "Lessons Learned" sessions; by the end of the project, it's too late, there's no point in trying to implement any changes because you won't be working with these people. Instead, meet every week or two weeks, or whatever works for your team, to decide what you want to do together to help your team.
7. Empowered, self-directed team members, who collectively decide what fits best with their team. I'm happy to tell you which tools (from the "software application" sense of the word) we use and how long our sprints are and what processes we follow, but your team is best qualified to determine what will work for your team.

From this sense, what tools do you recommend?

Race, soon

In a week and a half, I'll be running in the Komen Race for the Cure again. I would gladly welcome your pledge to support breast cancer research.

Will you be there on race day?

Makers, Hackers, Crafters, and Geeks. Woo!

Photos from the 2007 Austin Maker Faire:

Automate, Numb Bot.

The Pragmatic Programmer advises automating repetitive tasks—not just computer tasks but, y'know, everything.


Neal Ford made the point at No Fluff Just Stuff that you're not just automating to save time (because sometimes creating the automation takes more time than the repetitive task); no, instead he said: Repeating a task makes you dumber; automating a task makes you smarter. You will invariably learn something while figuring out the automation script. Even if not, you are using your brain, instead of dropping into numb bot mode.


I've noticed that if I am automating to save time, I will repeat a task until I notice that it's a recurring task and worked out the pattern for its repetition; then I will automate it. The more growthful pattern is to automate all kinds of tasks, and when I need to perform one of them again, adjust and generalize my automation to fit.


To support my point, a helpful example from XKCD: http://xkcd.com/196/ (I suppose it's safe for work, given that they're stick figures, but it does make mention of acts between consenting adults, so there you are. Also, I wouldn't have left, but that's why I married a geek.)