This week I attended a workshop in San Francisco called The Art of Storytelling with McSweeney’s. The course description promised that I would learn “How to craft persuasive stories for a variety of business contexts” and “Applied exercises to make your storytelling skills stand out in business settings.” While the workshop was enjoyable and inspiring, there was nothing business-y about it; it was more about defying conventions and subverting expectations to create more interesting, entertaining stories.
For example, the instructors explained that most stories answer the basic questions who, what, when, where, and how: Who are the main characters? What happens to them? Where does the action occur, and when is the story told? How will you choose to tell the story? By playing with one or more of these parameters, you can tell an otherwise conventional story in a more interesting way. They cited several clever examples from McSweeney’s:
“She’s been in there a long time. I hope she’s OK!”
I sat motionless in the women’s restroom stall, hiding my shoes, desperately hoping that concerned woman wouldn’t ask me if I needed help.
Why was I in a women’s restroom?, you ask. Fair question.
I was 21 years old; my family was on a road trip from our home in Portland, Oregon to Northern California. We had stopped for breakfast at a Denny’s restaurant somewhere along Interstate 5. After breakfast, I had said, “Let me just use the restroom, and we can get back on the road.”
I went into the stall and closed the door. A few minutes later, I heard a woman come into the bathroom. I thought, This woman is in the men’s room; maybe I should say something. I decided not to; we couldn’t see each other, so no harm done.
A moment later, another woman entered the restroom. Wait, two women? Must be me. I figured I would just wait until the place was empty and make my escape.
Unfortunately, it was the morning rush hour: one woman after another came in to powder her nose. (At one point, my mother was in the stall next to me. I briefly considered alerting her to my presence. I ultimately decided against it; she’s a screamer.)
Aside: When I was four years old, my father took me to a baseball game at Dodger Stadium. He took me to the bathroom, and from the stall I said, “Daddy?”
“Yes, Philip?”
“I love you.”
All the burly dads in that restroom chuckled and said, “Aww, he loves his daddy. Isn’t that sweet.”
Back at Denny’s, my father went into the men’s restroom. There was someone in the stall, whom he naturally assumed was me. (As far as he knew, I only used men’s rooms.)
Later, when I told my father what had happened, he said, “You don’t know how close I came to saying, ‘Hey, you in there: I love you.’ It’s a good thing I didn’t; I would have had to say, ‘Sorry, the guy I love is in the ladies’ room.’”
Eventually, the ladies’ room cleared out and I was able to sneak out undetected. (No, I did not wash my hands.) To this day, over 30 years later, whenever I enter a public bathroom, I always check for a urinal.
During the workshop, I thought about other ways I could tell this story: How about a Denny’s PR piece about how they were at the forefront of the gender-less restroom movement? ☺
I had a good time and definitely learned some new ways to enliven my stories; I’ll have to think a bit about how to apply these techniques at work.
Imagine two teams: The first (“Team Monica”) begins a project with a kickoff meeting, followed by meetings with stakeholders and subject-matter experts, and a recurring weekly meeting to discuss progress. The team creates various artifacts along the way: a project plan, process and procedure documents, wireframes and prototypes. Finally, after months of discussion and dozens (or hundreds) of pages of documentation, the team delivers its final product. Hopefully, it accomplishes its goals and satisfies stakeholders.
The other team (“Team Phoebe”) has an initial meeting to assign deliverables to each individual, then gets to work. With fewer meetings and less process, they are able to deliver much more quickly (weeks instead of months); with less up-front planning, however, there is some duplication of effort and inconsistency among deliverables.
Which team would you say is more effective?
If the teams are building something ephemeral (software, documentation, training content, etc.), as opposed to, say, a skyscraper, then count me squarely on Team Phoebe. Though its output may be less consistent, the team produces results much more quickly. Team Phoebe can produce a second iteration that incorporates feedback from actual users in less than time than it takes Team Monica to release version 1.0 (which will itself likely require revision; to paraphrase Helmuth von Moltke, “No plan survives contact with the enemy.”)
None of this is new, of course: In software development circles, there is decades-old tension between proponents of Waterfall and Agile methodologies; instructional designers have begun moving away from process-heavy ADDIE toward more iterative, learner-centered techniques. But the debate is far from settled; somehow I keep finding myself the lone Phoebe on a team of Monicas.
I recently came across this presentation by Justin Searls that resonates with me. The whole thing is good, but I especially enjoy the section in praise of small teams beginning around slide 65. Some highlights:
Consensus corrects for the team’s needs; feedback corrects for the users’ needs. Sadly, time spent gaining consensus costs you in feedback, because consensus and feedback compete for the same resources.
“How can we build something this big with a small team?” is exactly the wrong question. [We should be asking,] “How can we build something this small and start failing or succeeding?” If Small Thing™ is wildly successful, then the team can grow organically; if Small Thing™ is a spectacular failure, then at least it was a small thing.
How do you find a Small Thing? Simplify the idea so much that one person can build it.
That’s my dream: to be part of a team that empowers individuals to create Small Things without a lot of up-front process, gets them into the wild as quickly as possible, and incorporates user feedback to improve them over time. Who’s with me?
Imagine that you’re an auto mechanic. After working as a mechanic for many years, you take a job training other mechanics. You get to work in the field you love and the trainees seem to like you. Life is good.
Then your employer is acquired by a larger company. They see the word “trainer” in your title, so they assign you to their training department. The problem is that their trainers are driving instructors; nobody on the team really understands what you do. They ask you to pitch in and teach a driving class now and then, but you still spend the majority of your time training mechanics and your bosses mostly leave you alone, so you stay.
The plot thickens: Your team is reorganized, and you get assigned to a manager responsible for dispatchers. At the same time, the company begins hiring fewer mechanics. Now there’s less demand for you to train mechanics, and the focus of the team shifts to dispatching: “We have two dispatchers out sick today. We need all hands on deck to answer the phones!” Your mechanic skills are underused and becoming obsolete, so you decide to move on.
When you give your two weeks’ notice, your bosses suddenly realize that you perform a critical function that no one else on the team knows how to do. They ask you to document everything you do, and they send driving instructors to attend your mechanic training so they can deliver it (or teach it to someone else) after you’re gone. Yeah, right.
What can we learn from this cautionary tale? If you have an employee who performs a critical function:
Make sure you understand that function and appreciate its importance;
During one-on-one meetings, ask the employee if they’re satisfied with their job. If not, ask what changes he or she would like to see to make it more satisfactory;
Don’t wait until the employee gives notice to try to find and train a successor.
Interesting: “On June 20th 2013, we decided that our 4-day work week at Treehouse wasn’t insane enough so we went further: We removed all Managers… We give all employees 100% control of their time and let them decide what they work on each day.”
I recently bought a new car. As I was about to drive off the lot, the salesperson said, “In a few days, you’ll receive an email with a survey to rate my performance today. If you don’t give me a perfect score, it may as well be zero. Say anything you want in the comments, but if you don’t think you can give me all 5s, let’s talk about it now so I can make it right.” I’ve had similar comments from customer service people at hotels and car rental companies.
How did this happen? When did it become unacceptable to receive anything less than a perfect score?
Worse, the top rating on many of these surveys is, “Exceeded expectations”. If I expect my experience to be problem-free and it is, then the experience met my expectations, it did not exceed them. To exceed my expectations, the employee would have to do something remarkable, above and beyond the norm. It’s unreasonable for a company to expect employees (or for employees to expect themselves) to receive this rating routinely.
When I deliver training, I provide students with a feedback survey. I tell them I don’t mind if they give me less than a perfect score, as long as they explain in the comments why they gave me that score and what I could have done differently to improve it. My goal isn’t to amass a collection of surveys with meaningless perfect scores; it’s to receive honest feedback so that I can (hopefully) improve. I’m sure there’s something about every class that I could have done better; I welcome the opportunity to know what it is.
Update: What prompted this post is that I had my year-end performance review on Friday, and my manager was practically apologetic as she explained that only a small percentage of employees receive a rating of “Exceeds expectations”. Apparently some people are disappointed when they don’t receive the highest rating; they feel that it reflects poorly on their performance. As you may have guessed, I am not one of those people. But then again, I was always satisfied to be a B student. ☺
What [engineers] need is someone who will set them clear goals, give them the necessary tools and training, and protect them from distraction. That’s leadership.
I have not come across many leaders in my career. Lots of managers. Few leaders.
(2) Give them clear direction, then get out of the way.
Too many managers behave as if they are indispensable. That’s often because they fear they might not be.
Engineers need to know what’s expected of them, and what their priorities are to be. Then (unless he/she is a newbie), leave them to it. Remain accessible, but out of the way.
Amen! The rest of the list is good, too, but those are my favorites.
I joined Corillian Corporation in July, 2004. I spent about a year in tech support then switched to training, where I’ve been ever since. Last June Corillian was acquired by CheckFree, an online bill-payment provider. In December, CheckFree was acquired by Fiserv. In the space of about six months (without changing jobs), I’ve gone from a company of about 250 employees to one with over 22,000 employees!
One advantage of working for a larger company is the opportunity to explore different roles within the company. I’ve been fascinated by user experience (UX) design since I read Alan Cooper’s Guest Opinion columns in BASICPro (now Visual Studio Magazine). Those columns were excerpts of Cooper’s first book, About Face, which I similarly devoured as soon as it became available. And I found his VBITS keynote presentations in the mid-1990s thought-provoking and inspiring.
As an independent software developer, I wanted to create applications that were not just functional, but were a pleasure to use. My clients were usually more interested in having their apps delivered as quickly and inexpensively as possible. This conflict was a repeated source of stress to both me and my clients, and contributed to my decision to leave software development for the less schedule-driven disciplines of tech support and training.
When CheckFree acquired Corillian last year, I was excited to learn that CheckFree has an entire team (“User-Centered Design Solutions”) devoted to UX. The team was in the early stages of a major research and design project and, aware of my interest in the field, invited me to participate as an intern. It has been an incredible experience. It’s one thing to read about personas and how they can be used to inform the design of an application. It’s quite another to actually participate in field research and data analysis, to help design an application that will help real people achieve their goals.
Just before Thanksgiving, three teams of two visited the homes of 20 online banking users in Atlanta, GA; Columbus, OH; and Portland, OR. I was a member of the Portland team. We showed up with audio and video recording equipment and spent two to three hours talking with each participant about their financial and life goals, their current online banking experience, their desired experience, and how an ideal online bank could help them achieve that experience. (For more information on participatory design research, see Making Connections Through Participatory Design.)
Next, we spent several days going through our notes and recordings, entering data items about each participant into an Excel spreadsheet and assigning the items to various categories (e.g., demographic info, breakdown/frustration, ideal experience, quote, etc.)
At this point, I had spent about 15 hours with six very interesting people, and another 30-40 hours entering and coding their observations. They had shared some fascinating insights, but it wasn’t clear to me how we could distill all this raw data into something actionable. Thankfully, the team invited me to join them the following month at Lextant in Columbus, OH for the data analysis phase.
We began by having each field team present an overview of their participants. Our data entry items had been printed on Post-It notes; as we discussed what we thought was significant about each participant, we stuck the associated Post-It on a large sheet of paper representing that person.
As we talked about the participants, we began to see patterns emerge. At the beginning of the analysis phase, we had no idea how many personas we would end up with, but it soon became apparent that our 20 participants fell very clearly into three distinct groups. We created affinity diagrams to determine which characteristics of each participant were statistically significant. Next, we analyzed the three groups to determine the differentiating factors that caused an individual to belong to one group but not the others.
I’ve just described the process in two short paragraphs (and unfortunately I can’t go into detail about our findings for reasons of confidentiality), but in fact it was a full week of intense, exhausting, rewarding discussion. There were numerous inspired brainstorms and “a-ha!” moments. By the end of the week, I wanted to start my own online bank to deliver some of the amazing ideas we had come up with!
So, would I want to do this for a living? Yes and no. I find UX research extremely interesting, and interaction design is a wonderful creative outlet. I’m passionate about usability, but therein lies the problem: usability is not a verb. Toward the end of my week at Lextant, it began to dawn on me that ultimately we must create an application that Fiserv can sell to banks, which are primarily interested in “optimizing the online channel”: finding ways to separate customers from their money. Usability is a tool to attract eyeballs, but it’s far from the top priority.
I’d consider a career in UX if it were in an environment in which usability is a first-class citizen, where the people making the decisions are as passionate about UX as I am. Otherwise I would just be tilting at windmills.
As I entered my books into LibraryThing, I was surprised that I had read so many books last year. Most of my reading is technical in nature, so I tend to prefer electrons to atoms. Two factors contributed to my reading more than usual in 2005:
Our trip to China. There’s plenty of time to read on a 12–hour flight (especially when the movies are in Chinese!) I polished off four books on that trip, including the only fiction title on the list, which I purchased at Shanghai airport for the flight home.
Starting a new job. Two of the books on my list are related to my new position as a trainer, and Kathy is responsible, directly or indirectly, for both of them.
The first, Head-First Java, bears her byline. I purchased it after she revealed in an e-mail that “the exercises in our head-first books come right from our classes.” Variations of the book’s exercises have indeed proved effective in my C# classes.
In that same e-mail, Kathy recommended the other book, Designing World-Class E-Learning, whose primary message is that students learn by doing (and failing); to teach effectively, we must let students experience what we want them to learn. No more Death by PowerPoint!
The only disappointment on my list is Gerald Weinberg’s Weinberg on Writing. I bought it on Johanna Rothman’s recommendation; she seemed to promise that the book would help me become a prolific writer. Weinberg is an engaging storyteller, but his book is really about accumulating ideas for writing: he advocates carrying a notebook at all times and recording “stones” (ideas) with which you can construct “walls” (finished works).
Ideas are not my problem: I have a long list of topics about which I’d like to write. My problem is lack of motivation. After 40+ hours of work and 10 hours of volunteer work each week, all I want to do is sleep or watch TV. Unfortunately, I haven’t yet found a book to solve that problem.
My new boss likes to remind me that I’m an experienced presenter, but I have a lot to learn about being a trainer.
After one such humbling conversation, I fired off an e-mail to Kathy Sierra asking if she offers or could recommend training for trainers. To my surprise and delight, she replied promptly with a number of helpful suggestions. A few days later, she fleshed out those suggestions and posted them as a blog entry.
The day that entry appeared, I was on the final day of my first C# class, which I had condensed from five days to four, thinking that much of the material would be familiar to the students. But they had surprised me with many questions and lots of discussion, about which I had mixed feelings: it was great that they were so engaged, but here it was noon on the last day and I still had four units of fairly deep material to cover: advanced scope, delegates and events, attributes, et al (we had been covering two or three units a day).
During the lunch break, I read Kathy’s post and was struck in particular by these points:
If you're short on time, always cut the lecture, not the exercises! (Unfortunately, this is the opposite of what most trainers do.)
It is almost always far more important that your learners nail fewer subjects than be “exposed” to a wider range of subjects...If your students leave feeling like they truly learned — like they seriously kick ass because they can actually do something useful and interesting — they'll forgive you (and usually thank you) for not “covering all the material.”
Don't let the class fizzle out at the end. Try to end on a high...Ask yourself, “what were my students feeling when they left?” Too often, the answer to that is, “overwhelmed, and stupid for not keeping up.” And usually, the fault is in a course that tried to do too much.
After lunch, I called an audible and announced, “There’s no way we can cover all of the remaining material this afternoon, so here’s what we’re not going to get to.” I spent about half an hour explaining the various terms and describing some practical applications. Then I said, “If you wish, you can read this material on your own and contact me if you have any questions. Now, let’s write an app...” I wrote a spec for a simple flashcard program on the whiteboard, and we spent the rest of the afternoon creating it.
The class definitely ended on a high. The students were thrilled that they had been able to create a working application, and the class evaluations were great: not one of them complained that we didn’t cover all the material.
Due to my increased .NET evangelism, I was reappointed an MVP.
On May 1, I changed jobs. Same employer, but I’m now the Internal Training Manager. I don’t actually manage anyone; I educate employees and contractors (and occasionally customers) on Corillian’s Voyager platform and products.
Did a couple of nice bike rides this Summer: Cycle Oregon: The Weekend in June (I wasn’t feeling well, so I only rode Day 1), and the Vine Ride in August. Managed to not expose myself to any strangers this year.
For much of the past five years, I've been a remote employee working from home. While I certainly enjoyed the flexible hours and lack of commute, I did occasionally miss interaction with coworkers. No longer...
One of the benefits of my new job is an informal Professional Development Book Club: Each week (more or less), we read a chapter of a popular business book (we're currently working through The 7 Habits of Highly Effective People), then discuss it over lunch.
During a recent discussion of Habit 2 ("Begin with the End in Mind"), my friend Bala shared this article from Fast Company magazine. I'm sure it will resonate with many of us, particularly anyone who has worked on a dysfunctional software development project.
Last day of Summer! For those of you who care (Hi, Mom!), here's what I've been up to:
Work: I was laid off on May 21, so I spent most of June looking for a new job. Received two offers during the third week of June; accepted a position as a support engineer with Corillian Corporation. (We still have an open position, by the way, so if you know C#, VB, SQL Server, ASP/ASP.NET, XML, Javascript, DCOM, systems troubleshooting and Star Trek trivia, send me a résumé.) Didn't start the new job until July 12, however, because I was scheduled to go on...
Vacation: Went to Edmonton, Alberta, Canada to visit my wife's family and friends. It was nice to see everyone again; I hadn't been there for over 10 years!
Cycling: Did Cycle Oregon: The Weekend in mid-July: 120 miles over two days. Beautiful scenery and great company, but it was over 100 degrees that Saturday, which made the 75 miles we rode that day feel like a hundred. The Vine Ride, in August, was less arduous: my butt gave out before my legs did.
Music: I can go years without seeing a concert, then I'll see four in as many months. So far this year I've seen Don Henley, Prince and Tears for Fears; I'll see Sting on Oct. 7. I've also been playing bass more regularly: Met some fellow musicians at work and have gotten in touch with my inner Tito (Puente, not Jackson).
If there's an upside to being involuntarily unemployed twice within seven months, it's that it incites introspection: Am I the common denominator? Do I have some fundamental flaw that leads my employers to conclude that I'm not worth my salary? Might I simply be choosing employment that's poorly suited to my personality and abilities?
I've read a few things over the past several months that have resonated with me:
Programming — constructing release code — isn't the same as engineering.... Production programming['s] primary goal is producing a shippable product, not solving its technical problems....On the other hand, technical problem solving demands experimentation, which is naturally repetitive and empirical....Clearly — for the sake of the schedule, the budget, and the customer — programmers should never be tasked with engineering duties, and engineers should never be directly responsible for programming release code.
Reading that was a lightbulb moment: Engineering — problem-solving — is what motivates and inspires me; I find writing production code tedious and repetitive. Cooper also nailed the reason I've always had difficulty accurately estimating how long my projects will take: Engineering is inherently unpredictable, especially when dealing with unfamiliar technology, and should be done before the schedule is set and production coding begins.
Craig Andera, pleased that one of his side projects had achieved "1.0" status, wrote:
This is really a milestone for me. Like many people in my line of work, I have a fairly short attention span - I tend to focus on something intently for a while, figure out about 80% of it, and then move on to the next thing. That's an asset when you're teaching a class or researching a new technology, but I've long been aware that "real" developers don't have the luxury of moving on once the interesting bits are finished.
Amen! If I could, I'd hire a ghost programmer to do the grunt work, so I could concentrate on the juicy bits. (Hmm, maybe that's a good case for offshoring?)
"Most organizations are built on two flawed assumptions about people:
Each person can learn to be competent in almost anything.
Each person's greatest room for growth is in his or her areas of greatest weakness"
And likewise:
"These are the two assumptions that guide the world's best managers:
Each person's talents are enduring and unique.
Each person's greatest room for growth is in the areas of his or her greatest strengths."
Reading that, I wondered: What are my strengths, and how can I capitalize on them while managing my weaknesses? I bought the book this week and took the online assessment; my results are here.
Last week, I received two job offers. One of them was similar to what I've been doing for the past five years: Working from home, self-managed, developing ASP.NET applications from start to finish. I love the flexibility and independence of working from home, but it's a two-edged sword: It's too easy not to work when I don't feel like it. And I've learned that I often don't feel like it if I'm not doing something new and challenging.
The other, the one I accepted, is unlike any job I've had before. I'll have to get up every day and commute to an office, just like real adults do, and I'll have co-workers and a manager. But rather than writing production code, I'll be supporting other developers, debugging their code, solving the problems that have them stumped. It will be interesting to see if I've correctly identified my strengths. Stay tuned!
When I went dark last August, I was in the final throes of a death-march project, one of those that seems like a good idea at the time, but ends up going on far longer than anyone anticipated. It was my first experiment with an "agile" methodology, but I obviously did it wrong ('An agile methodology is neither agile nor a methodology. Discuss.') Bottom line: I spent my last couple of months there working overtime to finish the project and trying (unsuccessfully, as it turned out) save my job; I was laid off in October.
Thankfully, I was able to land a consulting gig within a month: I worked on a medical transcription app for a large healthcare provider. Like resuming dating after a divorce, it was reassuring to have a client who liked me and my work ('I am still attractive!') It was, however, the first time in over four years that I had to actually go to work -- I'd been working from home since early 1999 -- so by the time I got home in the evening, blogging was the last thing I felt like doing.
About the time that project was ending, I was offered what seemed like my dream job: developer evangelist for a consulting firm/component vendor. I would be paid to promote the company's products and services among the .NET developer community by writing technical articles, speaking to user groups and participating in online discussions; blogging was actually in my job description! Unfortunately, after only four months my employer decided he couldn't actually afford a developer evangelist, and my position was eliminated.
Thankfully (again), I've landed a new job; I'm scheduled to start in mid-July, after my vacation. This time, I've made sure it's with a financially stable company and that the position capitalizes on my strengths, so hopefully I can remain employed for at least a year this time.
So, Heather, I hope that answers your question. ;-)
I started with Fawcette Technical Publications in February, 1999, to work on developing its growing network of Web sites. In January, 2000, that network was spun off as a separate company -- DevX.com -- and I with it. I stayed for just over a year, then returned to FTP because I wanted to work with .NET (DevX was transitioning to ColdFusion).
It was interesting and educational to work for a Silicon Valley startup during those heady days of the dotcom boom. I'm thankful for the experience, and wish DevX continued success (as long as it doesn't adversely affect my current employer! ;-)
