Musings on Agile Performance Reviews and Goals

September 28, 2010

One of my recent posts fictionalized how an organization that has adopted Agile development can work at cross-purposes. The moral of the story is simple: Agile development emphasizes teamwork in ways that are likely to challenge your existing management approach – ultimately demanding change.

The performance management process is one area that has been historically focused like a laser on the individual and will need to be adjusted as you adopt Agile development. Being a knowledgeable, capable individual contributor isn’t enough for Agile development. Individuals need to be good team players, an easy transition for some and not for others.

As a manager in an Agile organization, you won’t be assigning tasks to individuals, either. Agile development is about self-organizing teams that welcome and respond to change. This means that you cannot determine in advance what tasks individuals will be working on, nor should you. Teams will need to learn to self-organize, and their learning that means you cannot do the organizing for them. Period.

This is a good thing! This actually raises the bar on you as a manager and on those who are directly involved on an Agile team. People need to be technically competent and cooperative, collaborative team players. As a manager, you need to be able to grow your staff to operate in this new model – and do so from arm’s distance.

Abolishing performance reviews and focusing on previews is where I’d like to be. But we’re not there yet. Since we can’t predict what people will be working on because they’re a part of a self-organizing team, what do we do? Part of the answer lies in what is normal for any situation: It’s about what people know, how they apply that knowledge in actual practice, how they conduct themselves, and the contributions that they ultimately make:

Knowledge = what you understand

Skill = how that knowledge or understanding is implemented in actual practice

Behavior = how you conduct yourself in the performance of your job and how you interact with others

Contribution = the value that you provided through delivering something or helping others deliver on something

By using these ingredients, as a manager you can observe, solicit feedback, and discuss with each of the people that work for you where they are strong or weak, plus develop plans to leverage their strengths and shore up any glaring weaknesses. (I’m a believer in leveraging strengths as much as possible versus focusing on weaknesses, unless a weakness is strong enough to get in someone’s way or prevent them from advancing up the career ladder.)

In an Agile context, individuals require more than just technical abilities. They will need to expand their understanding of team dynamics and technical practices in order for the team to improve. I think the reason that Scrum/XP hybrids are taking hold is because this combination provides an excellent foundation for defining the rules and roles for team interaction (so the team doesn’t have to define them) along with technical practices that improve software development.

You can measure how much someone knows. Something like technical knowledge can be measured by testing – formally or through actual work where someone produces a design or working code that is peer reviewed. And in the technology industry, there is always new knowledge to acquire, and learning goals should be a part of the equation, including things like:

Technical: Learning a new technology or practice, such as a new programming language, test-driven-development, test automation, etc.

Process: Obtaining a deeper understanding of Scrum and/or some aspect of Scrum like planning, retrospectives, coaching Scrum teams, etc.

Professional Development: Written or presentation skills development, taking workshops on teamwork, etc.

In real life, there are those who acquire knowledge but fall short in implementing that knowledge. Sometimes they lack confidence or are afraid to fail. Other times, a little practice is required to develop the understanding into a skill that enables the knowledge to be used effectively.

For example, knowing how to give a good presentation and being able to deliver one requires a little stage time and constructive feedback. If you are a programmer, object-oriented design requires some real-world practice to cement your understanding or take you to another level. And your practice should be done under the watchful eye of someone with experience, so that you don’t adopt or reinforce bad habits.

Behavior, or how you conduct yourself, is obviously important if you are a member of a team. If you are a self-centered, arrogant, selfish person who can’t or won’t work with others – like sharing knowledge – you will have a problem being perceived as a good, Agile team member. While the former is an extreme example, small adjustments can make big differences in the context of teamwork, and sometimes individual preferences must take a back seat to align the actions of everyone on a team. In general, the best Agile team members have a blend of technical and interpersonal skills and the willingness to help others succeed that is unmistakable. I outlined some key behaviors in my post, Ten Behaviors Required for Effective Teamwork.

In the final analysis, we all must be contributing. If you want higher pay, your value proposition will be based on the above and the ultimate delivery that you make. Did you work on that really complex problem? Did you help someone else work through a complex problem? To contribute at higher levels, we all need to continually build on our knowledge and work at applying that knowledge, working in a virtuous cycle to deliver the goods.

DUMB Goals Trump SMART Goals

September 24, 2010

A little boy asks three bricklayers who are working side-by-side what they are doing.

The first bricklayer says, “I’m putting one brick on top of another. Isn’t that obvious?”

The second says, “I’m building a wall for the west side of a church.”

The third says, “I’m creating a cathedral. It will stand for centuries and inspire people to do great deeds.”

(From the book, The Art of Engagement by Jim Haudan)

There are goals, and then there are GOALS. Exciting goals are about engaging peoples’ emotions. Which bricklayer above was truly excited and engaged?

Jim Collins and Jerry Porras coined the term BHAG, or Big Hairy Audacious Goal in their book, Built to Last. A BHAG is a long-term goal that is big, bold, powerful and exciting. And people want to be inspired, to be a part of some greater purpose. They want what they do to have meaning.

How much inspiration, purpose, meaning, and excitement are contained in the average employees SMART goals? Not much, I’ll wager. While most goals undoubtedly fit the definition of Specific, Measurable, Achievable, Realistic, and Time-bound, I’ll bet that many find their goals to be Stale, Monotonous, Annoying, Rational, and Transitory – reasonable, yes, but long on perspiration and short on inspiration.

Roger Bauer, CEO of SMB Consulting, Inc, has a fun post: SMART Goals are out DUMB Goals are in. But just what are DUMB goals?

DUMB goals unleash the entrepreneurial spirit.

DUMB stands for Dreamy, Unrealistic, Motivating and Bold.

Dreamy goals repeatedly wake you up at night wondering if something is possible with an effort that is truly remarkable.

Unrealistic goals are the ones traditionalists warn against and believe aren’t obtainable by anyone.

Motivating goals are those that make someone wake up each morning ready to take on the day versus figuring out a way to muddle through it looking busy even though time is being wasted.

Bold is charting a course competitors don’t dare take because the fear of failure or success is too daunting.



If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. – Antoine de Saint ExupĂ©ry



BHAG and DUMB goals are all about having a mission and a purpose. Consider these goals from some well-known companies:

Microsoft: A computer on every desk and in every home.

Google: Organize the world's information and make it universally accessible and useful.

Amazon: Every book, ever printed, in any language, all available in less than 60 seconds.

Twitter: To become "the pulse of the planet."

SMART Isn't Always Intelligent

September 21, 2010

Sally was puzzled and concerned. The nature of her Scrum team’s daily standup had taken a step backwards these last several days. Because of the lack of meaningful response to her gentle prodding at the standups, Sally knew that as ScrumMaster, it was time to probe a little deeper. As she drove to work that morning, she resolved to talk to the three developers on the team one-on-one to see if they could shed any light on their recent behavior change.

The team was regressing from its highly collaborative state to a collection of individuals. The standups were no longer a coordination point where the team discussed their collective sprint commitment and their shared progress. Instead, the standup had devolved into a series of individual status updates. Sally noted just the day before that one developer who finished early simply took on another task instead of assisting someone else who was working on a higher-priority task – even when it was clearly evident that the other team member was struggling.

Worse, there was even some bickering between the developers about the various tasks. It seemed that suddenly, each developer had a strong preference to work solely in certain areas, to the exclusion of anything else and to the determinant of the team. And the effects and behaviors were beginning to trickle to the rest of the team.

Sally had tried to get the team to recognize the problem, talking to the developers using informal, open-ended inquires like, “How do you feel about the team’s standup this morning?”Sally was hopeful that she could guide them to reflect on their participation in context with Scrum practices.

Unfortunately, she received rather brief, “they’re fine” responses and shoulder-shrugs. While the QA staff had begun to voice some concerns of their own, those concerns were quickly dismissed by the developers. The new status quo was in danger of becoming good enough, odd for a team that had worked very hard the past year to understand Scrum and had seemed determined to excel as a team.

As soon as Sally reached the office, she walked directly to Mark’s desk. Mark was always in early, and she wanted to talk with him first, as the most senior developer on the team.

“Mark, do you have a moment?” Sally asked as she approached Mark’s desk.

“Sure,” Mark replied, turning away from his monitor and reaching for his coffee cup. “I need another cup of coffee, can we walk and talk?”

“Works for me!” Sally enthusiastically replied. She waited for Mark to get up and take a few steps away from his desk before continuing. Sally’s intent was to clearly state her observation and be direct as possible. She did not want any ambiguity or evasive answers.

“Mark,” she began, “I’ve noticed that during this sprint, you’re not interested in any task other than your own. Instead of collaborating, all that you’re doing is reporting your status. For example, you didn’t offer to help Allen with his task the other day, but chose instead to move onto another task. I’m sure that you have the knowledge and experience that would be valuable to Allen, but it seems that lately you and the other developers on the team don’t want to share any information or assist each other in any way. What’s really happening here?”

Mark’s eyebrows rose as he considered Sally’s questioning. Sally was a good mirror; he hadn’t considered how his behavior had altered in the past week or so, but he immediately recognized that Sally was right. And Mark was experienced enough to understand why.

He let out a deep breath and said, “Well, I’ve just had my annual performance review, and it’s a good bet the others did, too…”

After talking with Mark and the other two developers on the team, Sally determined that the management team, in an effort to “raise the productivity bar” – and conforming to the HR practices of the company – had worked hard at establishing SMART goals for the development staff.

Unfortunately, in an attempt to be as specific and measurable as possible, the line managers had established goals that involved each developer taking ownership of specific functionality along with the objective for each developer to personally and visibly drive results for improving that functionality. Aside from teamwork issues, sooner or later there would be debates about product priorities with the Product Owner!

This individual focus undermined the team-oriented nature of Agile/Scrum practices. It took a meeting with the VP of development to get agreement that the goals should be changed, and Sally pledged to work with the line managers to help craft goals that were team-oriented and fit within Scrum development. The VP also agreed to get more education for management on the Scrum process itself, so that they could understand how to change their management style and work with teams that ideally should become self-organizing and autonomous in nature.

While this post was a fictionalized account, I’m curious if any of those reading have experiences with performance management and goal-setting (good or bad) related to agile or team-based development that you would like to share. And does anyone have a great solution that they’ve implemented?

Book Review: The Art of Engagement

September 17, 2010

The Art of Engagement: Bridging the Gap Between People and Possibilities I’ve generated some posts about engagement and resourcefulness this past summer, so I feel that it is timely to review the book The Art of Engagement by Jim Haudan, CEO of Root Learning, Inc.

I’ll start by asking a question: Are your people afraid? If they are, they can’t be engaged. But just what are workers in the 21st century afraid of?

According to Jim Haudan, the list looks like this:
  • We’re afraid that our contributions aren’t really valued.
  • We’re afraid that our personal beliefs don’t align with those of the company.
  • We’re afraid that we won’t be able to adapt to changes in the way we work.
  • We’re afraid that we won’t have a safe place to practice new skills.
  • We don’t feel that it’s safe to say what we really think.
  • We don’t think it’s safe to suggest better ways of doing things.
  • We don’t know how to disagree and not become branded “a problem.”
Interestingly enough, Haudan points out that formality reinforces fear in an organization. Haudan states:

“Many of the formal aspects of our workplaces are reflections of the rules and procedures that define the culture of the business. Without a level of informality in the workplace, fear and caution take over and cause people to fall short of what they’re capable of achieving. Leaders need to remember that human beings work for them, and human beings need to feel safe.“

There’s also another problem with achieving engagement, and that’s the “piecemeal” problem. Haudan likens this to a thousand-piece jigsaw puzzle, where workers get sent pieces one at a time, minus the box top to show employees how the pieces fit together. Without the picture, the pieces don’t seem to hang together: “Once piece says ‘Innovate,’ and another says ‘Cut costs.’ One says ‘Go slow’ and another says ‘Go fast!’ One piece says ‘Delight customers’ and another says ‘Reduce Inventory.’”

The book outlines some typical “conversations” that highlight typical gaps between strategy and execution:

Leaders saying something like, “This is our vision and mission,” with those on the front lines are responding, “Sounds blue sky to me. What does it mean to me and my people?” Leaders are saying, “You need to work smarter,” and the doers are countering with, “We can’t possibly work any harder!” Leaders exclaiming, “You are empowered!” while the doers are responding, “More flavor-of-the-month management.”


The solution? The book drove an excellent point home about the strength of visualization, and how visualization is a critical ingredient of engagement with many benefits:
  1. Visualization makes it easy to think in systems. It allows people to understand, connect, and focus systematically.
  2. Visualization creates simplicity. It forces us to “think simpler.” You can’t draw a crisp picture of something that hasn’t been thought through in great detail.
  3. Visualization captures the drama of business. It illustrates struggles, risks, threats, opportunities, and emotion in ways that data and words cannot. Tapping into this emotion challenges complacency and inspires activism within a business.
  4. Visualization enables us to think big or think strategically by showing us the whole. Thinking big allows us to focus on the major forces that drive our business rather than the everyday tactics that often occupy much of our time.
  5. Visualization appeals to most learners. In general, a visual culture is quickly replacing the traditional print culture, and there’s no question that it will be the approach of choice in the future.
  6. Visualization provides for quick recall. Visual images help most people retain information efficiently.
  7. Visualization enables nonlinear connections. Not everybody learns in a straight, progressive path. Each of us has to personalize the connections.
  8. Visualization acts as a universal common language by minimizing misinterpretations. It’s a consistent way to communicate among different cultures and languages.
  9. Visualization allows visual storytelling. It enables people to easily see an integrated story and talk about how they can add to it.
  10. Visualization connects people because it can display both facts and emotion. It conveys not only how the business looks but how it feels.
The Art of Engagement provided an excellent portrayal and the benefits of the strategic engagement process through visualization. I like the concept of people connecting through images and stories; after all, how many times have we in the software realm represented systems visually?

As Haudan observed, when we use visualization to portray the operations of a business, employees can more easily understand difficult concepts. Images eliminate the opportunity for widespread misinterpretation and generate a common, quickly understood language. After all, without an understanding of a company’s strategy, people can’t take responsibility for change.

I like one other quote from the book about strategy, and ties to what other people are saying, such as Dan Pink and his Autonomy, Mastery and Purpose as motivators:

Strategy is an adventure; even more, it’s a purposeful adventure.

If you want to examine connecting strategy to execution from a fresh perspective, this book is a well-written, must read.


Illustrations in this post are examples from the book, The Art of Engagement

Work/Life Balance

September 14, 2010

The software field is a demanding one. My wife has referred to herself as a “software widow” during those times when I’ve been heavily involved in a demanding project. She understands my career choice and understands that sometimes I need to shift greater attention to my job. I’ve always viewed this as both a necessary evil and an opportunity to build greater knowledge and expertise in new technologies or some business-related aspect of my job. This gain, however, comes at the expense of personal/family time.

Sometimes the price can be higher than you expect because the project becomes more involved and drags out far longer than anyone anticipated. It's easy enough to figure out when things are going on for too long; I get little signs, like my wife begging me to put my computer down on a Saturday morning to attend our daughter’s soccer game. (This is a true story from several years ago.) As a manager, I keep a watchful eye out on our staff and insist that they take some time off if I feel that they are pushing themselves too hard.

Most of the time, we're in control over our work/life choices. There are times, however, when life does the balancing for us. I’ve experienced some major challenges this past year that were out of my control, and those that I work with have been very supportive as I dealt with Life's curve-balls. To all of them: Thank you, I deeply appreciate your thoughts, concern, and support.

I’m still setting direction for our products, managing the development staff, and I continue to devote my own time reading books about software development and management as well as maintaining this blog. But it hasn’t been easy. I’ve been fortunate to have built up a good backlog of blog entries that get posted automatically; this has helped me keep this blog active during some difficult spells. On the work front, there have been times when my colleagues have had to fill in some gaps or otherwise work around my absence because I’ve needed some unanticipated time off.

The first half of the year involved my father – he started the year off being hospitalized with a collapsed lung. This started some serious family discussion and action about putting my parent’s house up for sale and drawing up blueprints for an in-law apartment at my house. Before we could get my father to commit to selling his house he ended up in the hospital with another collapsed lung. Fortunately my wife was able to work with her brother – who owns a woodworking company – and get the blueprints drafted for the in-law apartment.

After six-plus weeks of hospitalization and an evaluation of his condition in a Boston hospital in hopes that an experimental procedure might help, my father passed away. The entire episode was an emotional drain, compounded by the fact that my parents had made no preparations for their deaths. During this period I found that my mental faculties were reduced in ways that I haven’t experienced before; it was all I could do to focus on making the funeral arrangements for my father.

We’re are now in the process of building an apartment for my mother, and her house is up for sale. I the interim, I’ve been pulling double-duty maintaining her property and my own. During this time my mother has been staying with us in a room that we set up as a temporary arrangement. Needless to say, my wife and I have been dealing with a great deal of change and demands of our time.

This has turned into a major hurdle due to an unexpected medical condition that I ran into a little over a week ago. The day after returning from a business trip with a few others from our office – a trip that involved my driving from Connecticut to Maine – I left work thinking that I was going to stop by the grocery store to pick up a few things and then head out to watch a local high school football game (my wife is a cheering coach, and I enjoy a good game of football). While in the store, I had a moment where my vision went fuzzy and the world quickly closed in on me. I didn’t have time to even mention to someone that something was wrong; it was lights-out, and fast.

I woke up in an ambulance with someone telling me that I had experienced a seizure. I also felt like crap. The next day I was very tired and slept on and off for most of the day. I took some time off during the middle of the week so that the doctors could run some tests on me, but so far they haven’t discovered what caused my seizure. This had never happened to me before, and so far they’ve determined that I’m not epileptic and that no tumor is present. All they know is that my blood sugar dropped – fast.

I’ve been very healthy for my entire adult life, rarely missing work because of illness. And I’ve exercised regularly for most of my life – I had even gone running the same morning of the day that I had my seizure. I admit that I felt a little tired when I left the office that day, but I thought it was due to the effects of travelling and working, plus maintaining my running. I wasn’t expecting an ambulance ride, but I got one. I feel fortunate that nothing happened while I was driving myself and a couple of others back to Maine!

Some things in life are unpredictable, and you have to roll with the punches. I’ve had to rigorously prioritize and focus my attention all year long, and it looks like I’m going to have to continue prioritizing, planning, and now coordinating a little more, since I can’t drive by state law for at least three months after having a seizure. This will place a strain on my family, which I will try to minimize. And ultimately this does drive home the need for work/life balance.

Distinguish Yourself

September 10, 2010

Dan Pink’s recent quote of the day asked, “Have your skills become commodities?” Dan quoted Catherine L. Mann from a New York Times article, where Catherine observed, “C++ is now an international language. If that’s all you know, then you’re competing with people in India or China who will do the work for less.”

I agree with Catherine, if C++ is all that you know, then you have a problem in the making, and your skill – understanding a programming language – will rightly be perceived as a commodity skill. To be perceived as more than a commodity worker you need to move beyond coding skills. You need to be able to design and architect software. You need to be able to collaborate effectively with other people. You need to contribute to solving those difficult problems that can’t be completely specified in advance.

I’ve been concerned about the commoditizing of white-collar work like software development for while. In my post, Is Commoditized White-Collar Work on the Horizon? I referenced the book The Numerati by Stephen Baker, and how there is a movement to turn white-collar work into numbers with the goal of “optimizing productivity.” Unfortunately, this optimization is all about keeping those defined as commodity workers laboring as close to 100% as possible, making it impossible to generate the creativity and innovation that companies claim they desire.

Commoditization is all about keeping white-collar work in the mold of factory work, or at least duplicating the factory model as much as possible. I explored this topic (referencing Dan Pink, Micheal Lopp, and Seth Godin) in my post, Are You a White-Collar Factory Worker?

In the final analysis, you definitely don’t want to be viewed as a commodity worker whose work is indistinguishable from that of someone else; chances are, those skills can be easily and cheaply obtained elsewhere. Be a difference-maker and tackle the difficult problems. And don’t let the fear of failure get in your way.

Some Wisdom from The Wisdom of Teams

September 7, 2010

Teamwork in a business sense can be difficult to for some people to get their arms around. As we increase the use of software teams – particularly as Agile development takes hold – understanding the nature of teamwork and what to expect is vital.

The book, The Wisdom of Teams: Creating the High-Performance Organization by Jon R. Katzenbach and Douglas K. Smith was published in 1993, but having read it recently I find that it has a great deal of insight that is applicable in today's teamwork-oriented approach of Agile software development. If you want to understand teamwork, this book can provide you an excellent primer on business teams.

What is a team?

"A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable."

Can you have large teams?

"A larger number of people can become a team, but they are likely to break into subteams. Large numbers of people have trouble interacting constructively as a group, much less agree on actionable specifics."

Here's a problem the book discusses that Scrum solves by defining the roles and protocols of team interaction:

"Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership is to be earned, and how the group will make and modify decisions, including how and when to modify its approach to getting the job done."

The book makes note of key behavioral and mindset changes that must take place:

FromTo
Individual accountabilityMutual support, joint accountability in addition to individual accountability
Dividing those who think and decide from those who work and doExpecting everyone to think, work, and do.
Building functional excellence through each person executing a narrow set of tasks ever more efficientlyEncouraging people to play multiple roles and work together interchangeably on continuous improvement
Relying on managerial controlGetting people to buy into meaningful purpose, to help shape direction, and to learn.
A fair day's pay for a fair day's workAspiring to personal growth that expands as well as exploits each person's capabilities

Finally, the book illustrates the Team Performance Curve, which traces the development of a team from the beginning stage of Working Group through the ultimate goal of becoming a High-Performance Team:


As a team moves from a Working Group that is nothing more than a collection of individuals towards a real team, the effectiveness of the team increases. The Potential Team is just barely coordinating its efforts, whereas the members of a Real Team have ceased to compete with each other and are working as a team, leveraging complimentary skills. A High-Performing Team maximizes effectiveness and impact due to their deep commitment to both each other and the business's needs.

While team effectiveness increases as you move anywhere along the curve, the performance impact can actually decrease as the working group transitions to an actual team. Moving along the curve and becoming both more effective in an impactful way involves patience, time, and commitment.

How NOT to be Resourceful

September 3, 2010

“The process is the thing.”

“Give me the instructions for trouble-shooting these types of problems.”


These are a couple of quotes from others that have come up in my personal experience, and they have one thing in common: There are those who want someone or something to carry them through the easy way. Don’t’ get me wrong, I like reducing the complex into simple execution whenever possible. But there are problems inherent in the attitude present with these statements.

“The process is the thing.” No, I’m not against process; quite the opposite, in fact. If people want to share work and collaborate effectively, process becomes important, as everyone needs to be on the same page about how to approach the work. Process provides benefits like ensuring that critical steps that can cost you time and money are not inadvertently missed.

I get concerned when process becomes a singular focus – with no mention about a desired goal or outcome. Process is a means to an end, a course of action to take in achieving a goal. It’s frustrating for top performers who have a strong desire to achieve and an established track record of producing results to be pulled into dialogs centered exclusively about process by (sometimes self-appointed) “process police” whose aim is to enforce the “rules” above and beyond anything else.Delivering something that isn’t valued by the customer, despite “nailing the process,” doesn’t provide a true sense of accomplishment.

As a manager, I’ve been involved with individuals and teams who felt that process was stifling their ability to execute. Sometimes they were right and we’ve had to make adjustments. Sometimes it was our understanding and execution of the process that was really at fault. On other occasions there have been other difficulties at the heart of the matter, like an organizational roadblock. And at other times there was simply a need for a fresh perspective on how to apply our process to a new situation.

The key is to never limit the dialog about the process itself – unless the goal is to teach people about the process. When contending with real-life, day-to-day issues, talk about how the process should be applied to the work at hand, how it can help reach the goal, or where it is falling short of reaching certain objectives.

And before deciding to make changes in a process, make sure that you understand more than just what the process is. Understand why it is defined as it is and how value is derived from following the process. Then make informed decisions about process change. Like I said, process is simply a means to an end.

“Give me the instructions for trouble-shooting these types of problems.” I’ll go on a bit of a rant on this one. Ever try to get service over the phone from someone you know is following a script? Did you think that the person lacked any form of intelligence?

I’ll concede a newbie needs guidance. So train them and have someone experienced direct them at first, progressing to coaching as they improve. Then cut them loose! Scripts are for Hollywood, not for dynamic situations like technical support. They become a crutch that helps throw common sense out the window.

I’ve had more than one time-consuming phone call with technical support personnel where listening and common sense left the building. Like the time that I called to get a faulty network card that I had just purchased replaced. Because I had actually bought two identical cards, I thought this call would be a simple call.

Wrong.

The tech support rep began clicking away, asking the usual “Who are you?” and “What is the nature of your problem?” questions. I was able to describe my problem early on: “I bought two identical network adapters,” I explained, “and when I plug one of the adapters into my computer, I can’t get onto the network; no Internet, nothing. When I exchange this card with the other card – keeping all of the network cables and the computer the same, I get connected to the network. I can access the Internet without a problem. The only thing that I changed was the network card.”

Simple, right? I had hoped to eliminate the need for any further conversation; I expected to at least shorten the call. But this person had to follow his process – which meant following his script – and forty-five minutes later, after running test after test, I was confidently told that my network problem was with my Internet Service Provider, and that I needed to contact them.

I laughed, and replied, “I don’t know how your script got you there, but did you listen to what I told you at the beginning of the conversation?” After a little more dialog and one more phone call, I had a replacement network adapter on its way.

I don’t fault the script in this situation – I was asked to create one years ago. The problem that I ran into then is one that I’m sure continues to be true today: It takes a significant effort to capture all of the contingences and possibilities in a way that successfully navigates an unknowledgeable person to a successful conclusion. My feeling then (and it remains this way today) was that training and the expectation that people have problem-solving skills would be much more effective than trying to capture intelligence in a script.

For dynamic, difficult scenarios of today’s business world, the resourcefulness of people will always trump procedure and scripts. The message is simple: Don’t rely on a process or scripts to carry you. You won't be carried too far.