"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

When I work with new managers (and some managers who have been around for a while), some of the first questions I ask are:


How does your unit/department/team contribute to generating revenue for the company?

How does the work of your unit contribute to gaining new customers and keeping existing customers?

A surprising (to me) number of managers don’t have clear answers to these questions. (When I ask the people actually building the software, some people know, but more don’t…. which is less surprising, but still problematic.)

If a manager can’t answer these questions, how can he make good decisions about prioritizing work and analyzing trade-offs? How can he decide what not to do?

Here’s another set of questions to ask:


Who is the customer (internal or external) for your product?

Have you talked to your customers lately?

How do they use your product?

How does your product fit into their world?

What challenges do they face?

When employees can answer these questions, they can see how their work fits into the bit picture. Most people find work more satisfying when they can see how their work contributes to something bigger.

When employees can answer these questions, they make better decisions.

Both can affect the bottom line.

posted by Esther Derby at 6:38:00 PM  

|

I’ve been thinking about auditions since I had a conversation with a friend who hired a bunch of analysts who all reported they’d worked with use cases, but when it came to actually working with use cases didn’t have a clue.

I asked my friend if he’d used auditions as part of the hiring practice. He hadn’t, because he was worried that candidates would be insulted that he didn’t take them at their word. Further, he’d never been asked to do an audition as part of the hiring process, so he assumed auditions aren’t standard practice.

If they’re not, they should be. Candidates don’t have to perform perfectly in an audition, but you do want an indication of how they think about the problem.

For my friend’s analyst position, I can think of at least three auditions:

1) Given a domain and a goal, ask the candidate to draft a set of interview question to ask the customer or subject matter expert.

2) As a follow up, have the hiring manager play the SME, and have the candidate perform an interview.

3) Provide a set of actors and goals and, with the hiring manager playing the SME, have the candidate tease out the use cases.

4) Give the candidate a set of story cards (with big stories) related to the domain and ask him to break them into smaller stories that have business value.

5) Have the candidate demonstrate one or more prioritization methods he’d use with a customer. If you have multiple customers, have the interview team act as the customers and have the candidate lead the group in prioritization.

Okay, I’m on a roll...And I bet you can think of a bunch more.

Don’t hit a candidate cold with auditions, tell them when you set up the interview that you’ll be asking him to demonstrate some of his skills.

If you haven’t prepped the candidate that auditions are part of the process, avoid asking, “Can you do this” followed by “Show me.” That one-two punch is a set up for “What!? You don’t believe me?” response that my friend worried about.

Johanna has a post on auditions on her Hiring blog.

posted by Esther Derby at 8:34:00 AM  

|

Last week I did a feedback workshop at the AYE conference. I do this workshop from time to time, and while each workshop is unique, and there are consistent patterns.

As I walk around the room and listen to people practice giving feedback, there’s always at least one person all tangled up with subjective measures.

Some examples:

1. Talking to a co-worker who has a suggestive cartoon pinned up to his cube wall: “It’s not professional.”

The dictionary defines professional as “Conforming to the standards of a profession…” Most of us have different ideas about what this means in practice, and my idea of professional probably doesn’t match yours. Unless there’s a written code this one invites rebuttal.

2. Talking to a co-worker who listens to his voice mail messages on speaker phone (and is broadcasting personal and intimate messages from his new girlfriend): “Any reasonable person in a shared workspace would pick up the handset.”

This implies that the other person is currently not “a reasonable person.” Most people believe they are reasonable, so you’re likely to get an argument, not a problem-solving discussion or a change.

3. Talking to a co-worker who wears revealing clothing: “It’s not appropriate.”

Another subjective assessment that invites rebuttal.

Feedback is effective when it’s descriptive and informational – not vague and not evaluative.

When you give feedback,

Start by creating an opening. This can be as simple as “I’d like to talk to you about something.”

Describe the behavior or result – without using labels, or evaluations.

State the impact using “I” language. No one can argue you out of what you feel.

Make a request. Depending on the situation, you may ask for something to stop, continue, or change. You may ask to work on solving the issue together.

posted by Esther Derby at 9:28:00 PM  

|

A nice list of Simple Things that Can Amplify Effectiveness from a session lead by Dwayne Phillips (author of Software Project Manager's Handbook: Principles that Work at Work) on the AYE Wiki.

posted by Esther Derby at 7:51:00 AM  

|

I want to let you know about "The Secrets of Agile Teamwork: Beyond Technical Skills," a workshop that Diana Larsen and I are presenting December 6-8, 2005, in Portland, Oregon.

The workshop focuses on the interpersonal, collaboration and leadership skills Agile teams need to be successful at self-organizing into high performing teams. The workshop will benefit Scrum Masters, XP coaches, Project Managers, Development Managers, team leads, team members, or anyone who wants to work with an effective, collaborative team.

If you'd like more information about the workshop, for yourself or to pass along to others, you can find a fuller description and a registration form at:

http://www.estherderby.com/workshop.htm

This is the second time we've opened the workshop to the public. We've also done the workshop in-house to several companies. Here are some comments from people who have attended the workshop:

“Great workshop! Very thought provoking.”

“This workshop gives you great skills in communicating with co-workers. Finally, I have a nice, friendly way to tell my coworker about that annoying habit they have.”

“I think this is a must-attend workshop for almost all levels of career.”

“Very positive. Worth the time and energy if you want a better understanding of communication with your peers. Informative and useful.”

“Not boring corporate techniques. Real processes that help and accommodate everyone’s feelings.”

“Interesting. Illuminating. Introspective.”

"Esther and Diana teach the soft skills that you think you already have down. Attend it and you’ll know the value.”

So come on down.

posted by Esther Derby at 10:59:00 AM  

|

In my talk at PNSQC, I told the story of a manager who knew that multitasking was sapping productivity, but chose to assign people to Multiple projects anyway. This manager had a bunch of different stakeholders to please --all with different interests and priorities. As long as he said "Yes" to all of them, he avoided conflicts and uncomfortable conversations.

Dale Emery writes a post along similar lines here Multitasking and Conflict.

Of course, choosing multitasking doesn't avoid conflict -- it merely postpones the conflict and shifts it to a different dynamic.

posted by Esther Derby at 7:24:00 AM  

|