Category Archives: mentoring

Thinking about mentoring

One of my mentors invited me along on client interviews with one of my mentors. He took notes while I asked questions, and I learned how to ask better questions.

We’re doing this because you can’t learn consulting in school. You have to do it to learn. Learning consulting skills under a mentor’s guidance is much better than getting pushed out on solitary engagements and figuring all of this stuff on your own.

I wonder: why can I tell tons of stories about wonderful learning experiences when other people have such a hard time finding mentors? And what can we do to help more people connect?

One of my mentors said that visibility plays a big role. You have to get yourself into a position to be noticed by people who can mentor.

The mentor who’s been teaching me about interviews said that people have to want to invest in you.

Blogging and public speaking get me out there. Passion and enthusiasm help me connect with other people who care.

What would it take for more people to experience this?

Things that work well for me:

  • I share what I’m interested in, which makes it easier for people to help me.
  • I share what I’m learning, which gives mentors more return on their effort.
  • I ask lots of people for help, and I learn a lot from other people’s experiences.


Learning from interviews

David Ing (one of my mentors) thought it would be a good idea to help me learn not only facilitation techniques, but also Smarter Cities domain knowledge. He was working on an Industry Business Value Assessment study. In the interviews I observed, David set up the discussion, then focused on taking notes while another IBMer asked questions. Pairing up meant that one person could ask follow-up questions while the other concentrated on capturing knowledge.

Some interviews were scheduled for a week when none of David’s colleagues were available, so David asked me to lead the interviews instead. I was nervous, but I knew that he could always step in and ask questions to bring the conversation back on track if needed.

David handled the overview and the discussion guide. My role was to actively listen to the interviewee and occasionally ask follow-up questions.

What worked well:

Listening to people and guiding the flow of conversation through questions was surprisingly like hosting the tea parties I have at home. All I had to do was be interested—and with how passionate our interview subjects were about their different areas of responsibility, that was easy.

What I’m looking forward to doing even better:

I still need to work on asking more open-ended questions, but I’m sure that will come through practice and domain knowledge. Keeping a discussion guide in front of me will help, too!

It’s amazing how experienced people can put different insights together and make sense of a complex system. David and the two people helping us saw a lot of things I didn’t see until they pointed it out to me. =) This is great! I’m looking forward to building that kind of knowledge.

So now I know a little more about interviewing, and I know a little more about what people in city government think about. I’m glad I moved things around so that I could join the interviews!

Coaching people on how to give better remote presentations – Thinking out loud

We need better web presentations. There are so many opportunities out there. I think I can help more people learn how to speak, and I can help people learn how to speak better.

If I were to coach someone on how to give a better remote presentation, what could I help them with?

  • Finding something to talk about: testing your ideas through blogs, shared presentations, and webinars
  • Refining your message: figure out the next steps, the key message, and any supporting points
  • Supporting your story: planning how your slides will support your talk, and revising them to be more engaging
  • Pitching your talk: tweaking your title, abstract, bio, and picture; finding venues
  • Planning for interaction: how to make the most of webinar tools, how to engage the audience
  • Technical setup: familiarizing yourself with the system, getting your webcam going, cleaning up your background and lighting; testing everything beforehand
  • From presentations to conversations: getting used to the back-and-forth of backchannels, working with a host/moderator
  • Dealing with Murphy: What to do when things go wrong
  • Asking for feedback: Running surveys and learning from them
  • Reaping the rewards: Capturing assets, scaling up through sharing

In addition, I can help give feedback on their presentation content and delivery. Personally, I prefer focusing on content and organization rather than just ums and ahs, so you’ll get more substantive editing from me than surface editing.

Hmm. I think that might be interesting to explore. I’d learn a lot, other people would learn a lot, and I’d write up and share that with even more people. It might be some time away, or it might be an extracurricular thing if I can clear it with IBM, or plans might change. =) I’ll probably start with just one student first.

Would you like to hear from me if I do set up something like that? What would you like to see in it? Leave a comment or contact me and tell me what you think!

Not just a word

During the Art of Marketing lunch break, Alan Lepofsky wanted to know how I got to know his team when he was at IBM. I explained that Matthew Starr had invited me to the IBM Web 2.0 Summit even though I was just a graduate student doing research, and that was when I got to meet Carol Jones and Alan’s other colleagues. When he heard that, Alan told me this story about the word “just”, from when he was twenty-five years old.

One of his mentors had taken him to a very exclusive restaurant, the kind that looks like a home. It was a scene right out of the movies. The waiter greeted his mentor by name and offered his mentor’s usual table. His mentor ordered a drink. When the waiter asked Alan what he would like, Alan said: “I’ll just have a Diet Coke, please.”

After the waiter left, Alan’s mentor told him to never use the word “just” to make himself or his decisions smaller. Instead of saying “I’ll just have a Diet Coke”, Alan could say, “I’ll have a Diet Coke.” There’s a subtle difference, but an important one.

Reflecting on this in the afternoon, I couldn’t help but be struck by how many of the presenters apologized for themselves. It was casual — self-deprecating humour, apologies for slides or technique, apologies for nervousness — and almost unconscious, like something that people say to cover up gaps. Perhaps they thought of themselves as “just” themselves, too.

How many times have I asked for just water at a restaurant? Perhaps it’s to forestall the questions: Perrier? Carbonated water? Bottled water? But it seems even more awkward to clarify with “regular water” or “house water” or “tap water”. (What do people ask for?)

How many times have I described myself as just a lucky newbie? I often feel that I am. I feel like that child in the IBM Linux commercial, receiving insights from all sorts of amazing people. But to call it luck would be to frame this experience as difficult to reproduce, and
to call myself just a newbie dismisses the beginner’s mind that I deliberately develop and maintain – the one that lets me focus on learning and sharing as much as possible instead of staying within my comfort zone.

So who am I, if not just a newbie?

I am excited and amazed by the opportunities that I have. I am doing something incredibly right. I want to figure out not only how to do even better, but how I can share that with as many people as possible and help them do their best.

And yes, I am going to change the world. =) Why not? It’s possible. How wonderful can it be?

Moving from testing to development


One of my coworkers asked me for advice on shifting from a testing role to development. Inside IBM, cross-role experience can often be picked up within a project, on a BizTech opportunity, or by assignment to another role (if the project manager really, really believes in you). Here are some tips if you’re considering the shift yourself:

Although you can build your skill in steady increments, building expertise can be a long and frustrating process. You’ll make a lot of progress in the beginning, but you’ll probably hit a plateau. Don’t be frustrated.

Unless your project manager is okay with taking a risk on you, you probably won’t be able to immediately spend time developing those skills on the job. Here’s how you can free up some time to work on improving your skills:

  1. Look for ways you can work more efficiently and effectively, so that you can save time.
  2. Document those processes so that you understand them better and so that other people can take over your role when you leave.
  3. Automate as much as you can, saving more time and enabling more people to do your work.

You want to be replaceable. You can’t spend time learning something else or move on to another project if that would leave a big gap in your previous team.

How can you learn more about development when you’re testing?

  • You can improve your processes, learning more about available tools along the way.
  • You can learn how to script while automating tasks.
  • You can learn an in-demand skill and get pulled into projects that way.
  • You can focus on providing additional value while testing. For example, if your project is okay with it, do whitebox testing in addition to blackbox testing. By reading the source code, you might be able to think of test cases that should be covered. You can try helping with problem identification, using tests to narrow down where the bug might be. Once you get good at that, you can try documenting your problem-identification process and commonly-encountered bugs. When you’ve got a good feel for the structure of the program and how things are generally fixed, you might even tentatively propose fixes.

What other advice would you give to people who want to move from testing to development?

Learning more about interviewing

David Ing let me tag along on a client interview for a Smarter Cities engagement. He and Donald Seymour interviewed the CIO and other staff of a region in Ontario. In the afternoon, David gave us a crash course on Media and Entertainment to help Donald and another consultant take over that area of responsibility. It was fascinating to watch their easy rapport and interviewing style. Here are some of the things I learned:

  • Working in pairs makes interviews much easier. When David interviews, he usually asks someone else to lead the conversation. He asks the occasional question and focuses on recording notes, staying as close to the actual words as possible. This frees him from having to think about processing the words. He does this instead of recording the interview because listening to the recording would require lots of additional time.
  • Keep the conversation-setting presentation as short as possible, so you can focus on the conversation.
  • Don’t plan too much up front. Let the conversation take you to where it needs to go.
  • One-slide summaries with the question structures nudge the conversations in the right direction and help you ensure you cover everything of interest.
  • Capture notes on your computer to make it easier to share those notes with others.
  • Working with one client can be seen as self-serving. Working with several client organizations and bringing them together to learn from each other—that has a lot of value.
  • Hollywood is a strange and interesting place.

David, thanks for sharing!