Steve Smith's Being Effective

Tradeoff: Go For Quality

Thu, 22 May 2008 02:00:00 +0100

What typically happens when product development decides to create a superior product? Answer, slower delivery and costlier development than previous products. Why?

You don't get something for nothing.

Producing a higher quality product takes more development time, which delays delivery to the customer and drives up development costs. For instance, if you buy tailor made clothing, you receive a superior product. But the garment will cost you much more than off the rack clothing and you will typically wait weeks before you can wear the item. It simply takes more time for a tailor to create the customized garment. And that time and expertise increases the cost and delays the delivery.

This triangular relationship is a general law of development. Increase one of the variables -- quality, speed, or economy -- and one or both of the other two variables decreases. Every decision about these variables is a decision that involves making a trade-off.

Beware of the typical reaction of management to compensate for this effect by adding more people to the project, especially when the people are added late. This action may elongate the delivery rather than shorten it.

Unless changes are made to the development process and those changes work as planned, I suggest you make sure that your customer believes in the value you intend to produce. Don't lose the customer you are trying to please. Negotiate a scorecard with your customer to assess the value of your product plans rather than assuming you know. Development cost and speed are part of that scorecard.

Tell Me What You Want Me To Do

Tue, 15 Apr 2008 12:51:24 +0100

Are you overwhelmed by a mountain of email?

I suggest you take a page out of the playbook of my colleague Eric Sperley who knows how to ask for what he wants.

Eric sent the following message to the people who reported to him:

Guys,

Look, I am getting well over 250 emails a day. I can get 10-20 a day from each of you where I am just cc'd. I already have 71 email messages just this morning. I also get a ton of messages from the PMO, BSP's, and on and on. I am very concerned that I/You don't miss something important.

I may be missing something. If I am, please let me know. Otherwise, let us tighten this operation up a bit.

If I get an email from you, I should be on the To... line. I see no reason why I need to be on the Cc... line. Your email should say:

1) Eric, I need you to: (Tell me what you need me to do.)

2) Eric, you need to be aware of the following situation: (Summarize the situation and tell me why I need to know, i.e. history, risks, and what you think I need to do.)

3) Eric, I have a question: (State your question)

I will attempt to do the same. I will ask other teams to do the same. I do realize that teams do need to post status, but that is a different type of communication all together.

What do you think? If we could get everyone in the company to do this, we could free up a couple of hours a day of reading email.

Thanks,
Eric

This message was highly effective. It reduced the number of emails Eric and the members of his team received. And when someone received a message they understood what was being asked of them. The sender told them clearly either what they wanted them to do, what they wanted them to know, or what question they needed them to answer.

Messages like this from people whose opinion count the most in organizations would eliminate the deluge of worthless emails received by people in organization after organization. This simple message starts a revolution to improve communication. My, oh my, imagine that, you receive less messages and the messages you do receive are meaningful! That's something worth asking for.

You can start a communication revolution in your company -- ask for what you want -- send a message like Eric's now.

A Wild Horse Called Chaos

Mon, 14 Apr 2008 10:02:37 +0100

Is chaos like a wild horse?

The root for the word "manage" is an Italian word that means "to train a horse."

Inhumane horse trainers (managers) see a rebellious animal who must adjust to a new environment. They transform the horse through a process they call "breaking." They break the will of the horse so it submits to the will of the human. Their methods may include:

Saddling and riding the horse until its will is broken
Tying the saddled horse to a tree until it ceases to struggle
Drowning the horse until it submits

Humane horse managers see a frightened animal who can adjust to a new environment. They transform the horse through a process they call "gentling." The horse is led to trust human beings. Their methods include:

Observing the horse carefully
Familiarizing the horse gradually with the saddle and additional weight
Securing the horse's willing agreement

If a people manager sees chaos as rebellious, they may resort to tactics similar to a inhumane horse trainers. They may try to break the will of the people in the organization. That makes the surface of the organization look smooth, but underneath it's churning with fear and anger.

Effective organizational leaders, in my experience, see chaos as a period of adjustment. A time when things that were working have broke down and need renewal. A time when things can be reassembled in creative ways to respond to the disturbance between the organization and its environment. For instance, when the organization doesn't make its revenue goals for two consecutive quarters.

Leaders realize the things can't be recreated until the impacted individuals discover their own transformational ideas for how to respond so that it benefits themselves and the organization. They give people the time and space to respond willingly.

This is not some touchy feely nonsense. Would you rather own a horse that was gentled or a horse that was broken? I'll take the horse that was gentled every time. I want a partner rather than a servant.

Some people believe that a leader who is kind can't be firm. I guarantee you that a humane horse trainer is firm. You can manage horses and people both kindly and firmly.

Chaos doesn't have to be interpreted as a rebellion. If it's interpreted positively, as a signal that the organization is adjusting to it's environment, there will be more opportunities for growth and positive change

I suggest following the lead of humane horse trainers -- transform chaos through gentling rather than breaking.

Catch Them Doing It Right

Wed, 02 Jan 2008 10:02:37 +0100

Rewards can be powerful management tools, but only if you implement them effectively. Discover how the right timing and getting to know your employees better can improve the impact of your recognition methods.

My article Catch Them Doing It Right was published in the January, 2008 issue of Better Software Magazine. Check out a copy of the article on stickyminds.com by clicking here.

Ban Crackberries from Meetings?

Tue, 04 Dec 2007 18:13:26 +0100

Todd Wilkens advocates banning crackberries from all meetings. I agree with Todd that people distracted by emails and phone calls aren't focused and become impediments to an effective meeting. But, in my experience, too many organizations have terribly ineffective meetings. If your organization's meetings are terrible, will a ban on crackberries make them effective?

No.

A pattern of consistently terrible meetings is the result of a sick organizational process. Banning distracting devices will, at best, lead to a less terrible meeting. At worst, it will lead to angry people who believe they are being treated like children. Banning crackberries and laptops does not guarantee more focused participants; for instance, eavesdrop on the thoughts of Bryan:

Who they hell do they think they are banning my wireless devices? I'm at this meeting to listen and occasionally answer a few questions. Most of the time the stuff they are saying has nothing to do with me. Why shouldn't I be able to process my email so my time is used efficiently? Dumb asses! I've got things to do. I'll write emails on my notepad and transcribe them to Outlook as soon as I'm released from this prison. Everyone will think I'm taking notes about the meeting. :-)

A pattern of consistently effective meetings is the result of a healthy organizational process. Leaders in these organizations design their meetings. They define its purpose, objectives, participants, and agenda. They use the meeting's type as a pattern for focusing and organizing the meeting. They invite only the people who are needed and who will receive an ROI from participating. They treat the participants like adults. They have a process for each agenda item that helps the group produce the desired outcome. They share information about the meeting in advance so that participants are prepared before the meeting starts.They start the meeting on time. They manage the meeting so it finishes early or on time. They collect and use feedback to constantly improve their meetings.

A ban on crackberries is neither needed nor desired in organizations with highly effective meetings. Participants are engaged in a highly interactive meeting. Participation has value to the participant as an individual, as a member of a team, and as a member of the organization. Participants neither have the time nor desire to use their wireless devices. If they must take an interrupt, which they don't make a habit, they alert the group to that need and process interrupts outside the meeting room.

I'm sure it's difficult for people who haven't had a positive experience with meetings to believe a consistently effective meeting is possible. It's not only possible -- it's a reality in organizations who believe that meetings are the lifeblood of their business. It's also a reality under the wing of a strong leader who decides that meetings in their part of the organization will be conducted differently.

If you aren't fortunate enough to be a part of an organization with consistently effective meetings, engage in guerrilla actions to help create highly effective meetings. Start by buying a copy of How to Make Meetings Work by Michael Doyle and David Strauss and put what you read to use.

If your organization wants to heal a sick process that is producing terrible meetings, contact me. I will help.

The Recipe for an Effective Proposal

Fri, 30 Nov 2007 17:08:12 +0100

Does management reject your ideas? A typical cause for rejection is a failure to frame the idea effectively. Frame your idea effectively and it becomes a proposal, which will demand consideration by management. What is the recipe and key ingredients for an effective proposal?

The key ingredients are X (the idea), Y (the benefits), and Z (the cost of doing nothing). The following shows the recipe that turns an idea into a proposal:

If you do X, you will get Y.

Otherwise (if you do nothing) it will cost you Z.

Do I have your approval to do X?

Is that exactly what you should say to management? No, of course not. I designed the recipe and ingredients to help you spot a missing ingredient or portion of the frame. For instance, uneducated proposers typically fail to explicitly ask management for approval to do X.

For instance, David believes his company should buy software to track trouble tickets and issues. David talks to Ruth, his manager, about his idea.

David: Ruth, I think we should buy the ABC software to track trouble tickets and issues.

Ruth: I don't have budget for that.

David: But we can't make sense of what we are hearing from our testers and clients.

Ruth: No, now is not the time.

David: @#!~

David has articulated X but he is missing Y and Z. And he hasn't asked Ruth to do anything. Using the simplest version of the recipe, the conversation could be transformed to:

David: Ruth, if you approved the purchase of the ABC software to track trouble tickets and issues, you could justify to Stan (Ruth's manager) the additional people you want to hire by giving him unequivocal information about our clients and testers opinions about problems with our product. If we continue to be unable to clearly articulate the problems with our product, we will continue ineffectively prioritizing the use of our people.

Ruth: We don't have the budget for it.

David: Do we have the budget for continuing to do business as usual?

Ruth: @#!~

David: Do I have your approval to buy the ABC software?

Ruth: Let me think about it.

David: When should I check back with you?

Ruth: Friday.

Did David get what he wanted? No. But he is much closer than the first conversation. If Ruth says "No," he can appeal to Stan. If he appeals, David will want to change Y (the benefits) so they resonate with Stan. As you move up the management chain, its often important to articulate the benefits in economic terms.

The same recipe and ingredients applies to making a proposal to anyone, such as a teammate or client. Focus the benefits (Y) so they resonate with the other person.

I lead a terrific workshop on this topic. Read Chris Kay's feedback about the workshop. Please contact me about brining the workshop to your organization.

The Art of the Discovery Interview

Fri, 30 Nov 2007 09:50:29 +0100

My article Drawing Out the Facts: The Art of the Discovery Interview was published in the July, 2007 issue of Better Software Magazine. The article explores how to conduct effective client interviews.

Topics include suggestions about what to do --

Before the Interview
During the Interview
After the Interview

You can find a copy of the article here. I would appreciate hearing your feedback about it.

We Know Best

Fri, 28 Sep 2007 12:22:20 +0100

"We know better than they do about what's needed." Whenever you hear an influential member of your team utter those words, fasten your safety belt. The team is nearing the Twilight Zone.

The person saying, "We know better than they do about what's needed," is referring to the customer.

When decision-makers say "We don't have time for their feedback--we'll get it during the Beta," welcome to the Twilight Zone. The time period during which the development team completely severs its communication link with the customer.

It's costly to stop talking to your customer. And it's especially costly when the product's foundation is being poured. Failures during the Beta will reveal some of the design faults in the foundation. But discovery happens after substantial parts rest upon the foundation.

Propping up and repairing the foundation is, at best, difficult and costly. At worst, the foundation can't be repaired, which means:

starting over;
terminating the product; or
working around the cracks throughout the life of the product.

Why do decision-makers choose to sever communication with the customer? My experience is that decision-makers don't believe they will receive the results they need from the development process. Possible reasons include misunderstandings about the process and lacking faith in it.

Misunderstandings can be cleared up and faith restored through process renewal, which will also renew the organization and its individuals.

Renewal requires changing the organization's status quo so it can become more effective. Shouldn't that happen naturally? In some organizations it does. But in most organizations, it's an unnatural act so engaging outside help increases the success of renewal efforts.

Outsiders can see the obvious that people inside the organization who are wedded to the status quo can't. And an outside coach has tools for working through the inevitable resistance that bogs down efforts to change things that have become familiar to people in the organization.

Process renewal typically includes many of the following elements:

Creating a safe environment where everyone can contribute
Making the process visible so everyone can explore and improve it
Comparing the visible process with the process of similar organizations that are more effective
Renewing the process by closing the gaps between yours and the more effective organizations
Testing the renewed process by walking through it with the members of the organization
Transforming the process again based on feedback from the walk-through(s)
Running periodic retrospectives to discover the parts of the process that are working and the parts that aren't
Preserving parts that are working; renewing parts that aren't.

If your organization keeps straying into the Twilight Zone, renew your process. Don't buy into statements that imply that the development team knows things better than the customer. They don't. Stay in continuous communication with your customer throughout the development process. Use their feedback to build a solid foundation and reliable structures that don't cost you dearly to rebuild or work around later.

Ingredients for Successful Teamwork

Tue, 04 Sep 2007 23:36:26 +0100

I have had the good fortune to be a member of many successful teams during my career: But my career hasn't been all bliss -- I have also been a member of unsuccessful teams. In my experience, the recipe for the most successful and satisfying team experiences contained ingredients that were ignored by the unsuccessful teams. What ingredients fostered both teamwork and success?

Listening to teammates personal desires
Encouraging teammates to ask for help
Processing the team experience

At the beginning of a project, explore the desires of the members by using the focus questions: "What would you like to have happen for you during this project? Why?" It's a question designed to put the desires of team members on the table for consideration. For instance, a teammate may answer the focus question, "I would like to participate in the architecture work. I'm thinking about becoming an architect."

People who haven't experienced explicitly sharing their personal desires with others may have difficulty answering the questions. They may not trust the process. You can't force them to share their desires so don't try to. But you can lead by example by putting your desires squarely on the table to show them it's okay to share.

The obligation for a teammate is to listen to the desires of another teammate. The team isn't obligated to satisfy a member's desires. I am regularly amazed though by the power an individual gains by articulating what they desire. And how much more helpful I and other teammates can be in helping satisfy those desires when they are visible rather than invisible.

During the project, encourage your teammates to ask for help. Teammates learn it's okay to ask for help by being asked for help so ask them for help. For instance, when I had a family emergency, I asked a teammate to complete one of my tasks. I have found that the following words are particularly powerful, "I need your help." and "I need a favor."

If there is anything that is certain in a project, it's that the members of a team will need help from time to time. Asking for help fosters a healthy interdependence between teammates. And make no mistake about it -- the members of a successful teams are interdependent. If they aren't, it's not much of a team.

At set intervals, process the team's experience using a retrospective. I am astonished by how few teams actually process their experience. If all your team is concerned about is the product, you are abandoning one-half of your team's potential value. Your team's process is also a product.

If you constantly improve the process, it's value to your company will continue to grow. After all, the process used on this project will be the default process for producing the next product. Nurture rather than neglect your process.

When the members of a team can ask for what they want; can ask for help; and can process their shared experience -- the team's recipe contains key ingredients for success.

Rethinking Stand-Up Meetings, Part 2 (Revised)

Mon, 30 Jul 2007 10:49:42 +0100

I argued in my first article about stand-up meetings that the right participants were the key to a successful meeting rather than whether the participants were standing up or sitting down. Despite my dislike for forcing people to stand up, I mentioned in that article my positive regard for other elements of the standard stand-up meeting.

What elements do I like? Why do I like them? How can we innovate?

Rethinking Stand Up Meetings, Part 2 is posted on the Amplifying Your Effectiveness (AYE) Conference web site. It's a major revision of the ideas first posted on my blog under the same title.

Full Time Pay for Half Time Work?

Sun, 22 Jul 2007 22:27:07 +0100

Albert, without fail, has exceeded all of his production objectives for the past five years. He is a top performer who produces high-quality results. Colleagues like him. Clients adore him. But Albert never works more than 20 hours per week. That's less than one-half the amount of time his colleague's work.

Albert receives a compensation package equal or better than his colleagues. He has a single requirement for his manager and his organization, "Don't waste my time." You now control the organization. Would you continue to employ Albert under the same arrangement?

This isn't a trick question: Albert produces in less than 20 hours as much or more than his colleagues do in 40 to 60 hours.

I would continue this arrangement in a heartbeat.

But when I shared these facts with two development managers I respect and asked them whether they would continue the same employment arrangement, they both said, "No."

Whoa...

I was surprised by the development managers' responses. I probed them about their answer. The vagueness of "production objectives" seemed to be a problem. They abhorred the idea of full time pay for what they considered half time work. They also were concerned about the demand that Albert's time not be wasted.

I decided to ask a a different group of managers -- sales managers -- about hiring Albert to be a salesman, a job whose results can be described quantitatively. I shared these facts with 1 second-level sales manager and 2 first-level managers: If your hire Albert as a salesman, you are guaranteed that he will generate at least 105% of his quota but never more than 110% each reporting period; his colleagues will like him; his clients will adore him; but he will never work more than 20 hours per week and he demands that his time not be wasted.

I asked each of them "Would you hire Albert?"

I thought this was a no brainer question for a sales manager, but "No," was the verdict I heard from each of them.

Whoa...

I asked them, "What's preventing you from hiring Albert?" A manager sneered as he said, "The notion of him only working 20 hours per week is insulting and his demand that his time not be wasted is absurd. He is being paid to do what he is told. And think of what he could produce if he worked a regular (40-60) hours. If I can't motivate him to work hard, I don't want him" The creases in my forehead became more pronounced as I said, "But isn't the guarantee of him producing 105% of his quota worth something to you?" "Doesn't matter. I might be able to hire someone who would work more hours and make 200% of his quota," countered a sales manager.

Whoa...

I didn't expect this response. Perhaps I didn't structure the inquiry well or I asked the wrong groups.

Both groups seemed to fixate on the number of hours worked and didn't like Albert demanding that his time not be wasted. Unlike me, neither group was impressed about the guarantee of results.

I like the notion of paying for results that are certain. And Albert's time management is superb so I'll support his demand that his time not be wasted. All other things being equal if Albert, or someone else, can consistently produce the desired results in one-half the amount of time as their colleagues, I am more than willing to pay him at least as much as their colleagues.

How about you?

But Is It Possible?

Wed, 18 Jul 2007 22:59:17 +0100

Your manager, Ellsworth, asks you, "But is it possible?" He wants you to tell him that it is possible for you to satisfy a project milestone despite the argument you presented him for the past five minutes that the milestone was unrealistic.

You feel like you are on the witness stand. Jack McCoy, the character from the Law and Order television series, comes to mind. D.A. McCoy buttons his suit coat and approaches you on the witness stand. He sneers and asks, "Yes or no, Mr. Smith, is it possible to satisfy the milestone."

If everything went perfectly, you could meet the schedule. But in development, you know things never go perfectly.

Ellsworth asked you the same question about a previous project, you replied "Yes." But the required perfection failed to materialize and you were unable to meet the schedule. During your annual performance review, he reminded you that you didn't satisfy the schedule. Despite your reminder about the arguments shared with him that everything would have to go perfectly, he only remembers you saying, "Yes, it's possible." He uses the failure to justify giving you only an average salary increase.

You recall that Suzzanne answered Ellsworth's question with a flat "No." Despite her being right, Ellsworth branded her as someone who wasn't a team player. She told you that Ellsworth rated her performance poorly during her review, which resulted in no raise.

You are facing a double bind, which means you are in jeopardy regardless of whether you answer yes or no.

You could say, "Yes, I estimate there is a 1% chance of satisfying the deadline." But Ellsworth will only hear, "Yes, blah blah blah blah."

Step back and look at what is typically happening in this situation:

Upper management imposes a deadline for delivery. Why? They believe the revenue forecast will be impacted if the schedule isn't met

Working backward from upper management's deadline, middle management (Ellsworth and his colleagues) create a project plan consisting of a series of milestones. Why? They want to gain agreement between themselves about what and when things must happen to satisfy upper management's deadline

You hear about the milestones from your manager. Why? Middle management wants you to buy in to their schedule. An they want a sanity check for an egregious scheduling error they may have missed.

Now ask yourself, what haven't I heard about? You've heard about speed of development. Middle management assumed that costs would be similar to the last development effort. But what you haven't heard is anything about the quality of what you are supposed to deliver.

So another option for answering the question is, "Yes, and the quality of my part of the project will be poor. Ellsworth will again hear, "Yes, blah blah blah blah."

There is another possibility. It's risky; it requires a relationship with someone in upper management; and it requires you to be savvy about your company's business. Use your relationship with someone in upper management to propose an alternative approach for satisfying the revenue objectives of the business.

Ridiculous? Perhaps. But is it possible?

Office Hoteling

Sun, 17 Jun 2007 21:36:58 +0100

What is office hoteling? Why is the practice spreading? What are the unintended consequences of its usage?

Office hoteling changes the traditional model for how office space is used. Rather than assign permanent office space to each employee, hoteling is a system for assigning just-in-time temporary office space to employees. The hoteling systems I've experienced allowed me to reserve a small cubicle somewhere in the office for a single day. These systems ran on a first-come, first-serve basis.

Why is the practice spreading? The financial side of organizations love it. Hoteling minimizes the square footage of the office. The lower the square footage of an office -- the lower the cost to lease the space and the lower the business taxes, which are partially based on square footage.

What are the unintended consequences of this practice? There is less employee interaction and the quality of the interaction is poorer. More employees choose to work from home rather than having to schlep their stuff to the office each day and work in a tiny cube. This change results in lower transportation costs for employees. But it also results in conference calls becoming the primary means of interaction rather than face-to-face interaction.

The winners with hoteling are visitors to the office. When the office space was permanently assigned to employees, they might not be able to find a place in the office to work. With hoteling, my experience is there is always space available.

The losers are management but they don't notice the loss for months or years. In my experience, management retains their permanently assigned offices despite the introduction of hoteling. They don't immediately notice the impact of hoteling; for instance, they fail to notice that employees aren't stopping by their office to alert them about something they've seen or heard.

If your organization is contemplating hoteling, I suggest moving managers from their offices to permanent cubicle space. They will benefit from experiencing the change, which will enable them to take actions to fix problems, rather than merely observing the change to hoteling. Furthermore, I suggest converting all management offices to meeting rooms so more private space is available for employees to meet. Hoteling works best, in my opinion, when abundant areas of private space are available for people to use for meetings. If more meetings are happening in the office, more people will come to the office and that will foster productive, unintended face-to-face interactions.

I believe that face-to-face interaction, when possible, is the most powerful form of interaction. If an organization discourages the employees who live in the same area from going to the office through the practice of hoteling, then it should be prepared to suffer the consequences. The organization will enjoy less expensive office space and suffer through poorer communication and thus lower productivity.

Don't short circuit the ability of employees to interact through the practice of hoteling. If you must hotel because of a financial crisis, increase the amount of your office's private meeting space to facilitate face-to-face interaction.

Rethinking Measurement Concepts, Part 1

Sun, 10 Jun 2007 22:43:04 +0100

What is a measurement?

I would answer a careful observation.

Ponder the following questions as you encounter measurements today:

What observations do you trust?
What observations are you skeptical about?
What observations do you believe are phony?
What observations don't have any value?
What new observations would have value?

Brownfield Software System

Thu, 07 Jun 2007 23:06:02 +0100

The term brownfield site means real property, the expansion, redevelopment, or reuse of which may be complicated by the presence or potential presence of a hazardous substance, pollutant, or contaminant.

Source: U.S. Environmental Protection Agency.

Does the term brownfield software system have merit?

I'm not sure. Let's step back and explore.

I thought my use of the term "brownfield software system" was new, but a quick web search yielded a paper by Janet Lavery and Cornelia Boldyreff who use the term. In their paper, Lavery and Boldyreff say,

"Throughout the UK there are thousands of sites which have been contaminated by previous industrial use, often associated with traditional processes which are now obsolete, which may present a hazard to the general environment, but for which there is a growing requirement for reclamation and redevelopment." This quote was taken from the UK Government Environment Agency web site [1] and refers to land based brownfield sites. It could also refer to the challenges facing the software engineering industry today in transforming legacy systems with their dated software, distributed data, and entrenched business processes into useful, web accessible systems. Unlike the derelict land brownfield sites chosen for reclamation and redevelopment, software brownfield sites are usually functioning systems supporting an ongoing institution or business in its continued existence while not fully supporting or adapting to the changing needs of their user communities.

It seems to me that the Y2K crisis treated software systems similar to how government agencies treat brownfield sites, such as toxic waste dumps, so the concept is growing on me. I'm struggling with whether a maladaptive system is like poison. I think it is. It harms the people who use the system. If the Y2K problems weren't corrected, the brownfield software systems would have harmed people.

Do you think some legacy software systems are like brownfield sites? Post a comment. I would like to know your opinion.

People Act Like Themselves

Wed, 06 Jun 2007 22:59:01 +0100

When you interview for your next job, I recommend analyzing how people treated you during the hiring process.

Why?

The treatment you receive will mirror the treatment you will receive on the job.

For instance, analyze the responsiveness of the people involved in your hiring process. If people were responsive to scheduling appointments and answering your questions, expect that you will receive similar responsiveness working inside the organization. Otherwise, expect the same kind of unresponsiveness that you experienced during the hiring process.

Jason, a colleague and friend, is interviewing for a new job. He told me about his experience interviewing for an IT management position at an insurance company in the Seattle area. A manager inside the organization scheduled an interview with him. But to Jason's surprise, the hiring manager didn't tell him until a few hours before the interview that it would be a phone rather than a face-to-face interview.

Jason must have did well enough during the interview because the manager talked to him about scheduling a series of panel interviews with other managers. Thankfully they were to be face-to-face meetings, but it took three weeks to schedule the meeting. When the meetings finally happened, they consumed Jason's entire day. What was the result of the panel interview? He doesn't know. Although it's been over a month since the interviews, no one has contacted him.

It's not hard for Jason to imagine what it would be like working inside this organization. He doesn't care any longer whether they contact him. He doesn't want to work with the people who interviewed him. Would you?

My experience with the people who do the hiring is they can't help but act like themselves. However they treat you during the hiring process is valuable information about how you will be treated if you decide to work with them. You choose whether you want to continue being treated like you were during the hiring process.

Critical Lesson in Estimation

Tue, 05 Jun 2007 17:04:39 +0100

What critical lesson have I learned about the process of making an estimate?

Have your most pragmatic, experienced people do the estimate.

Minimize the number of people who are members of the estimating team. A team size of three, in my experience, is ideal. That's enough members to trigger divergent estimates, which creates arguments, which leads to better estimates. And it's also a team size that converges without the pain that happens too often with larger teams.

If your organization's management demands that inexperienced people attend the estimation meetings so they learn how to estimate, have each of these attendees wear a baseball hat with Observer labeled on its front panel. Make it clear to the observers that they are only to observe the process rather than to participate. The hats are symbolic and will remind you and them of their role as observers.

Why? Inexperienced people may not know what the don't know, which will slow down the estimation process without increasing the quality of the estimate.

For instance, I was a participant in an exercise at a workshop where we were ask to order estimated times for a series of a kitchen remodel tasks, such as changing the electrical wiring, adding granite countertops, and adding hardwood floors.

A few of us in the group had experience either doing the work or contracting the work. The majority of the people in the group had zero experience, but a few of them didn't want to opt out of the experience. They wanted to learn the process, which was laudable. But by participating, the inexperienced people only slowed down the experienced people. Again and again, I heard, "it shouldn't take that long..."

I felt bad telling the inexperience people they weren't helping, but I it was true. Meaningful participation happens when someone brings something to the table that furthers the process.

Don't ensnare yourself in the web of other people's inexperience. Insist that only pragmatic, experienced people do the estimation task. If you only have a single person with the proper credentials, let him or her make the estimate.

Process Revelation

Mon, 04 Jun 2007 18:44:28 +0100

A participant in a workshop that I led drew the above picture to describe the role he played in his company's process:

Do drawings help members of a team to better reveal their point of view?

In my experience, they do.

But more importantly, the process of drawing with virtually no constraints helps the drawer reveal their point of view to themselves better than when they are required to use prescribed symbols.

A drawing is a channel for conceiving and conveying ideas. Interpreting the picture with words provides the drawer with yet another channel for conceiving and conveying ideas. Increase the number of channels someone uses to describe something and you help them conceive more ideas and increase their ability to successfully communicate them.

A drawing is revelation.

Drawing is used with the permission of a source who wishes to remain anonymous.

The Effective Project Manager

Sun, 03 Jun 2007 22:48:20 +0100

What do effective project managers realize?

If a project fails, it's the PM's fault.

If a project succeeds, the PM credits the team for the success.

People versus Process Orientation

Thu, 31 May 2007 23:24:53 +0100

People have passionately argued about whether people are more important than process or process is more important than people. Tune in; for instance, a colleague writes passionately about the triumph of people over process. Another colleague writes passionately about the importance of heroes. A pundit writes passionately about how great systems (process) are more important than great people. And yet another colleague writes passionately about a method that helps competent people perform better.

I can reveal a lot about my biases by answering the following question: How do I feel about the thought of being employed by a company with a great process?

Threatened.

My first thought is of a totalitarian process that turns me into a gear inside a machine.

I want to be a person who is part of a team of people who use an evolving process rather than a cyborg working with other cyborgs following the rules prescribed by a totalitarian process.

My work experience is there is always someone in a company attracted to the idea of a totalitarian process because it appears to them as the most efficient way to produce something.

Perhaps in some industries there is a "most" efficient method. But in the Information Technology industry,I believe anyone designing the most efficient method for producing our products has a screw loose.Before anyone tries to create the most efficient method, we need to become consistently effective at producing products that please our customers and learn from those experiences. In my opinion, we have a long way to go.

There is a another part of me that likes and believes in process as long as it treats people as humans rather than machines. I have been a member of teams that have had a highly-effective process. It helped me structure my thoughts and feelings and use them to create better products for our customers.

I don't have to feel threated by a company with a great process. I need to investigate whether people who do the process have a say in the process. If they do, it's a worthy company.

It doesn't have to be about people over process orientation. It doesn't have to be great process over great people. People design process. Don't have outsiders design the process for a workgroup. Let the people who do the process design the process. And I gather this action is exactly what some of the best manufacturing companies do. We can learn from them.

Tradeoff: Go For Speed

Wed, 30 May 2007 18:00:56 +0100

The people whose opinion counts the most choose to go for faster delivery speed. Their thinking may be sound; in this case, they want to beat their competitors to market.

Choosing faster product delivery visibly sacrifices product quality and, in my experience, it often invisibly sacrifices the economy of product support. In this post, I answer the following questions:

What is a tradeoff?
What distinguishes a conscious from an unconscious tradeoff?
What is the impact of trading off quality for speed?
What can you do to change the choice?

A tradeoff is an engineering tactic for generating as much value as possible for your customer and your organization when circumstances don't allow you to satisfy every desire. I have yet to experience a development project where everyone's desires could be satisfied so I expect tradeoffs. And I want the choices about tradeoffs to be conscious rather than unconscious.

It's a conscious choice when I know:

What are we getting?
What are we giving up?
Why?

It's an unconscious choice when I or any member of the development team can't find answers to the above questions. And when the answers can't be found, the team is wishing rather than planning for success.

Let's return to the choice of going for delivery speed. In QSM Vol. 4, Jerry Weinberg insightfully points out the triangular relationship between the variables -- product quality, delivery speed, and development economy. In development projects, Weinberg says these variables are locked in a stabilizing feedback loop. A choice to increase any one of the variables will decrease one or both of the other variables.

For instance, if we choose to increase the delivery speed, we decrease product quality or decrease development economy or decrease both of them.

What are we getting? Faster deliver speed.

What are we giving up? Perhaps desired functionality. Perhaps a defect free product. Perhaps employee morale. Perhaps delighting the customer.

Why? Perhaps beating our competitors to market. Perhaps satisfying a big customer who will buy other products if we deliver early. Perhaps winning an industry award.

I don't like all of these answers, but I like that they are explicit. Regardless of whether I like them, they are all legitimate.

When development organizations go for speed, my experience is management rarely focuses on the additional support cost triggered by shipping a product faster. In these companies, development and support were in separate organizations. They each had their own budgets. Development had financial incentives to go fast and that choice had a big impact on support. What can be done about this problem? Create a strong feedback loop back to development. I suggest charging development for support. They won't like it, but the less the number of faults, the less they pay, which puts part of the economic impact of their development choices back on them.

What can you do to change choices? If the tradeoffs are unconscious, provide the team with your interpretation of what the team is getting, giving up, and why. And compare it to a tradeoff that you consider will provide more value. You may be surprised how making things explicit offers an opportunity for management to choose differently.

Reference

Jerry (Gerald M.) Weinberg, Quality Software Management: Volume 4, Anticipating Change, ISBN 0-932633-32-3, pp. 175-192.

Gradient of Agreement

Wed, 16 May 2007 00:17:39 +0100

I'm a big fan of Sam Kaner's Guide to Participatory Decision-Making, ISBN 0-86571-347-2. I highly recommend it to anyone who leads meetings.

In my post on Decide as a Team, I wrote about using a method called Roman Evaluation to reach a decision. Kaner talks about a more formal concept he calls Gradient of Agreement in his book.

I am less enthusiastic about the Gradient of Agreement today than when I was first introduced to it.

Why?

The following table compares Roman Evaluation versus Gradient of Agreement:

Roman Evaluation		Gradient of Agreement
Thumb up	I agree.	Endorsement	I like it.
Thumb Sideways	I will accept the majority's decision and support it.	Endorsement with a Minor Point of Contention	Basically, I like it.
		Agreement with Reservations	I can live with it.
		Abstain	I have no opinion.
		Stand Aside	I don't like this, but I don't want to hold up the group.
		Formal Disagreement but Willing to Go with the Majority	I want my disagreement noted in writing but I'll support the decision.
		Formal Disagreement With Request to be Absolved of Responsibility for Implementation	I don't want to stop anyone else, but I don't want to be in involved in implementing
Thumb Down	I disagree (veto) or I have something to say	Block	I veto this proposal

Although I know the Gradient of Agreement will work, especially with large groups, it seems overly complex to me compared to Roman Evaluation. And Gradient of Agreement has levels (blue font) that seem ambiguous to me. I question whether a participant could support the decision; for instance, it's hard for me to support a proposal which I don't have an opinion; or I don't like; or I disagree with; or I don't want any implementation involvement. I suspect a participant that voted that way would provide, at best, lukewarm support.

I prefer the simplicity and clear meaning that comes from using Roman Evaluation.

Exploring Requirements Podcast

Mon, 14 May 2007 22:32:16 +0100

Last year, my colleague Esther Derby interviewed me about leading requirements workshops for an Amplifying Your Effectiveness (AYE) Conference Podcast.

Esther probed me about my favorite questions to ask workshop participants.

I answered:

What are elements of the problem?
Why (is solving this element important)?
What will happen if you don't solve this element?

To listen to the podcast click here.

Be Ashamed of Your Silence

Sun, 13 May 2007 21:00:35 +0100

Robert, a project manager, told me he uses the weekly project status meeting as a bully pulpit to shame any member of the team who didn't satisfy their task deadlines. I've seen him in action -- his face becomes grotesque as he verbally assaults his teammates.

I believe it's wrong for Rob or anyone else to attempt to shame another person. But it's also wrong for a teammate NOT to satisfy a task deadline.

Is it shameful not to meet a deadline?

Yes.

Attempts by people like Rob to shame me in front of my teammates don't shame me. When I fail to satisfy a task deadline, I'm ashamed of my silence. Nothing prevented me from notifying my teammates that I wasn't going to meet a deadline.

On a functional team, you can notify teammates about deadlines that won't be met; and you can ask teammates for help. The sooner you ask or notify your teammates, the more effective a teammate you become. It may be possible to make the deadline with help from teammates. But that isn't a possibility unless you ask for it.

Your employer may have an unwritten rule (see my post about an impact of corporate culture) that says don't pop the collective fantasy about the schedule by notifying your teammates of an impending delay. Each time you follow the unwritten rule, the more ineffective a teammate you become.

You can choose again. Inappropriate silence hurts every member of the team, especially you. Find a different employer or a different team or a different mindset that enables you to be an effective teammate who can say, "I need help" or "I won't meet that deadline."

An Impact of Corporate Culture

Thu, 10 May 2007 23:04:12 +0100

Project Managers from ABC and XYZ, which are located on the opposite side of the same street, differ in how they report project status: The PMs from ABC are forthright with their sponsors, and the PMs from XYZ are evasive.

Why do the PMs at ABC and XYZ have opposite approaches to reporting status?

Their very survival depends on providing information according to the rules of their corporate culture. The cardinal sin at XYZ is failing to support the fantasy. The cardinal sin at ABC is failing to inform management about changes and their impacts.

Let's explore. Each company has the same number of PMs, and each PM at ABC has an identical twin working at XYZ so their isn't any differences in capability. All the PMs from both companies participate in the same intensive training on risk management.

What's the impact of corporate culture on applying the risk management training? The risk management done by ABC's PMs will be clearly superior to that done by XYZ's.

Why? Let's hear from Tom Demarco and Tim Lister :

It's okay to be wrong, but not okay to be uncertain.
If that rule describes your company, you're sunk.

The rules says you may miss your promised delivery date -- even miss it by a mile -- but in the months and days leading up to that date, you're not allowed to express any doubt that you will indeed deliver on time. Failure is tolerated as long as you don't commit the capital crime of admitting beforehand that you might fail. Another expression of the rule is that you can ask for forgiveness for being late (afterward) but you can't ask for permission (beforehand).

Until the people at XYZ whose opinions count the most recognize the impact of the culture on the work product and seek to change the culture, their investment in training will return only frustrated employees back to the business.

Reference

Tom DeMarco and Tim Lister, Waltzing with Bears: Managing Risk on Software Projects, ISBN 0-932633-60-9, p. 42

Problems: Cope, Manage or Solve?

Wed, 09 May 2007 21:55:56 +0100

When faced with a problem, I suggest considering three strategies:

Coping
Managing
Solving

Let's apply the strategies to the situation where you have a new pet who defecates in your house. You (I hope) don't like poop on the floors of your house.

You could cope with the problem by cleaning up the poop. Your strategy is to deal with the undesirable effects.

You could manage the problem by keeping the dog outside. Your strategy is to tradeoff more time bonding with your dog for eliminating the constant cleanup.

You could solve the problem by training the dog to signal you it needs to go outside to poop. Your strategy is to invest time training the dog to eliminate the problem.

Coping doesn't intervene. It deals with the problem's undesirable effects.

Managing intervenes. It makes a tradeoff and controls the problem's undesirable effects.

Solving eliminates the problem.

Each strategy is effective for a class of problems. I believe all of us cope and manage more problems than we realize. And that's okay.

But if the strategy you are using isn't working, you can choose again.

Consider some of the big problems you face this week.

Which strategy are you using?
Was the strategy intentional?
Would you like to change your strategy?

Be Up Front

Tue, 08 May 2007 23:30:49 +0100

You and Jeff are members of a project team. You've know Jeff for years. You like and respect him. He is new to the team. In what looks to you like an effort to prove his value to the other members of the team he has taken on too many tasks. He isn't completing his high-priority tasks on schedule. And he keeps taking on new tasks.

What do you do?

I suggest you have a one-on-one conversation with Jeff as soon as possible. Tell him about what you have observed. Find out whether you are right. You might not be. But that's less of a problem than suffering a project setback because you didn't act on your observations.

The earlier I detect the problem the easier it is to talk with the other person. When I deny what my senses are telling me, the harder it is for me to have the conversation. I suspect the same is true with many of you.

I might start the conversation by saying "Jeff, you seem to be having trouble completing your tasks. I've noticed that the high-priority task of gathering and analyzing feedback from our clients hasn't been completed. And you took on the task of writing an article for the next issue of IEEE Software, which seem like it will distract you from completing the client feedback study. What's the story?"

If you find yourself talking about the situation with Jeff behind his back or you hear another member talking about Jeff behind his back, I recommend that you immediately bring your observations to both Jeff and the other team members. This is no longer a problem with Jeff -- it's a team problem.

Over commitment is a solvable problem when the team faces it. If Jeff is overcommitted, everyone will suffer the consequences. He may need to hear from the team that it's okay to ask for help. He may need to reprioritize his work. He may need to decommit from tasks. It's up to the team to assess and deal with the problem.

Everyone is on the same train. If you see that the train is about to go off the tracks, stop the train and address the problem.

Elements of Effective Management

Mon, 07 May 2007 22:16:12 +0100

I am fortunate to have worked on a team led by Anne Cawley early in my career. Experience working with her enabled me to know, rather than speculate, about the power of an effective manager.

What elements of her management style made her effective?

Congruence: She conversed with members of her team as equals rather than subordinates.

Hiring: She has a keen insight into people and team dynamics. She hired people who were similar enough that they would bond with the team and yet they were different enough to generate powerful discussion, learning and commitment.

Work Ethic: She led by example. She was always willing to do her share of the work and more.

Meetings: She led our team meetings systematically. She made my previous managers look like amateurs. I never left her meetings feeling my time had been wasted.

Interaction: Despite the members of the team being located in three different continents, we had quarterly face-to-face meetings.

Process: Our group had a process and part of it was to innovation. Our process helped us produce high-quality products on schedule.

Consensus: She worked for consensus. But she didn't abdicate decisions to the team. She considered her vote as important as each member of the team.

Practice: She believed in practice. The group created and delivered lots of presentations to engineering organizations. The practice enabled us to deliver with authority.

Marketing: She assumed the larger organization would not fully see the value of her team. She constantly demonstrated the value of her team to the larger organization.

Fun: She knew that it paid dividends for the team to have fun together. At least once a year, we had events with our spouses at fun places.

Two decades later I still remember many lessons that I learned working with Anne and the other members of the team. Anne created the right results by doing the right things, the right way.

My previous managers taught me what not to do. Anne Cawley taught me what to do. Knowing what to do trumps knowing what not to do every time.

I'm grateful for the opportunity to experience true teamwork led by an amazing leader.

Communication Is Like Breathing

Sun, 06 May 2007 20:45:02 +0100

"Communication is to personal health, satisfactory interpersonal relationships, and productivity as breathing is to life. Effective communication can be both taught and learned. We were not born with the way we communicate. We learned it, mostly through modeling, in ways no one even knew or intended."

--Virginia Satir (family therapy pioneer)

For a tip on breathing better by communicating more effectively, see my post Elements of Effective Communication.

Source for Quote: The Satir Approach to Communication, ISBN 0-8314-0071-4, preface.

Types of Meetings

Thu, 03 May 2007 23:34:46 +0100

There are different types of meetings. Each type requires a different structures and supports a different number of participants. For instance, a status (feedforward) meeting has no limit to the number of participants while a decision-making meeting produces results faster with a small number of participants.

If you want to help your teams have more effective meetings, set the participants expectations about the meeting by stating in the agenda --

the purpose of the meeting.
the type of meeting

The typical meeting types are:

problem-solving
decision-making
planning
feedforward (status reporting and new information presentations)
feedback (reacting and evaluating )
combination meetings

For instance, the agenda states that you will be a participant problem-solving meeting to scale the application so it supports 500 simultaneous users. That description makes it crystal clear what you are there to do. And after you participate in a number of the same type of meetings, you will know that meeting's structure and your role.

Although it's in the list, I don't like combination meetings. Participants, in my experience, aren't as focused in a combination meeting; thus the results are poor. If you insist on combination meetings, I suggest your break them into segments of different meeting types. Despite segmentation, time management for a combination meeting is more difficult than a single type of meeting because you have more than one purpose to achieve.

If you want to save yourself and your teammates time and effort, propose to management that the purpose, type, and agenda of a meeting be clearly stated in the scheduling request for every meeting.

Reference

Michael Doyle and David Straus, How to Make Meetings Work, ISBN 0-515-09048-4, pp.159-166

Elements of Effective Communication

Wed, 02 May 2007 22:55:28 +0100

If you want to be a more effective communicator, keep your conversations focused on these three elements --

HERE

NOW

US

Conversations containing the opposites of the above elements --

THERE

THEN

THEM

-- will lead to ineffective communication.

For instance in a meeting of managers,

Ineffective: "They (the testers) didn't test the application properly so it crashes."

Ineffective. "They (the developers) didn't create the application properly so it crashes."

Effective: "We (the other managers and you) didn't manage the developers and testers effectively so users are experiencing crashes."

Talk about here, now, and us. Those conversational elements create an above the table conversation. Their opposites create a below the table conversation.

Waiting for Management to Set Direction

Tue, 01 May 2007 23:11:39 +0100

Several of my friends who work for the same large organization tell me they are bored with their job. I hear about them waiting for management to complete the process of setting a new direction for the organization.

What opportunities are available to employees when management is in the process of setting a new direction?

1. Offer to help management set direction

Start with finding out who is setting the direction. Large organizations like to use terms such as "management team" to describe the team who is setting the direction. Take a tip from my colleague Dwayne Phillips who asks his management, "May I have the names of the people on the management team?" He contacts the members of the management team and offers to help them.

2. Complete mundane, low-priority tasks

When the organization is busy, mundane low-priority tasks aren't done. For instance, deleting old files from the network drives; inventorying tools; and so on. I'll bet you could stay busy for weeks completing tasks that remove clutter so it's easier for you and your colleagues to work. Recruit some of your colleagues. Call it the spring cleaning project. The project isn't glamorous, but no one would argue that its long-term effect isn't positive.

3. Research

You have been saying for a long time that you want to research a new technology. You have the time now so use it to do the research. Share your finding and recommendations with your colleagues.

4. Write

You know things that would benefit people both inside and outside your organization. Write and article about what you know. At the very least, you can share the article with the people inside your organization. Perhaps you can find someone to publish it outside the organization.

5. Exercise

Increase your fitness: run; hike; bike; lift weights; play tennis; play soccer; play basketball; or whatever you enjoy.

6. Vacation

Can you think of a better time than now?

7. Do nothing

Doing nothing is always a choice. You may be doing it now. Are you okay with days of doing nothing?

8. Act like your working

Acting like you are working is harder than working for some people. Is it harder for you?

I'm sure I've only scratched the surface of opportunities available to employees while management is busy setting a new organizational direction.

What have you done in similar situations?