Years ago at Borland. My first real gig. I was poached from an internship into a full-time QA gig. When I accepted the offer, they sent me a box of Borland schwag, t-shirts, notebooks, and pens. I was elated. No more hourly wages, I was full-time.

Six months in, my manager sat me down at her desk and slid a piece of paper over. She was quiet and, in hindsight, nervous. I read the paper and realized she was documenting how I had failed at my job. She asked me to sign the piece of paper I’d barely read.

I did. Next to my signature was a date. It wasn’t today; it was 90 days from today.

Disclaimers

I wrote a piece about performance management a few years back. This was entirely for managers. This piece is for the individual contributor on a performance plan, but I need to set two initial conditions to make this helpful.

First, there are bad managers who use performance management not to address a performance issue but to let go of an employee as quickly as possible. Sorry. These managers suck. For this article’s sake, we assume the manager intends to address the performance issue.

Second, I’m assuming this is a fixable situation. You are in a job you can do, and through a combination of your and your manager’s focused effort, it is possible to succeed.

The First Challenge: Acceptance

“I had no idea I was failing.”

I thought this when my manager slid the paper over to me. I’ve heard this when I was the manager, and I hear this over and over via the recap when my managers deliver a performance plan.

This is the overwhelming first reaction to a performance plan, and the contributing factors for this reaction are:

• Humans really don’t like to give negative feedback. In fact, we’ve rebranded this type of feedback as constructive feedback because we are some profoundly uncomfortable delivering it. Because we avoid giving it early and often, this is likely the first time you’ve heard it in a focused and direct way.
• Humans really don’t like to receive negative feedback. It’s a self-preservation thing. It’s pride. We effortlessly twist the story to hear the narrative that best suits our worldview.

Your first of four challenges is entertaining the idea that you can fail. You’re not going to wholesale believe this right now, but if you can’t consider the possibility of failing, you certainly won’t be able to address it.

The Second Challenge: Clarity

After your initial reluctant acceptance of the situation, the second challenge is clarifying the current state and remediations. Assuming you have a competent manager, this data should be sitting right in front of you in a written form, but here’s what you need to do, preferably during this first meeting:

• Read the description of the situation. Forgetting your instinct to holler, “This is a total surprise” does the description make sense? Is it fair? Does it describe reality? If you declare, “Everything here is wrong, and this is a travesty,” you fail the first challenge. Clarifying misperceptions, adding critical missing data, and asking for more detail are the first healthy steps in resolving this situation, and they demonstrate your willingness to do so.
• Read the expected next steps. This is a description of the work you need to complete. Like the description of the situation, the goal is understanding. What work do you need to complete? Is it obvious how success will be measured for these tasks? How often will we be meeting to review progress?
• Finally, there’s that date at the end of the document. What does it mean? Delicate topic here because it could mean, “We’ll check-in on this date” or “This is when we’ll decide on your status at the company.” Understanding what this date means is critical data you need.

The time you take to review this document the moment it lands is essential. Yes, it’s okay to sleep on it and have additional questions later, but at this first moment, you are setting expectations with your manager about how you will approach this work. Constructively engaging in the conversation sets a starting constructive tone.

The Third Challenge: Do the Work

Once everyone agrees on what actions to take and what success looks like, we begin the third challenge: do the work.

The challenge here is focus. Remember that piece of paper she slid over and had me sign? I asked about that date, which was 90 days in the future. The answer was, “If we don’t fix this by this date, then we will take action.” The date exists to give the plan structure, but it feels like a threat. It sounds like an angry clock ticking in the back of your head, and if all you do is obsess about the ticking, you won’t do the work.

Focus on the work. Back at Borland, I was so new to the industry that I didn’t understand the gig. Borland was experiencing rapid growth, so my manager didn’t spend sufficient time with me, and I was all over the place.

The work:

• Write test plans that exercise new features.
• Find defects by executing these test plans and performing ad-hoc spot testing.
• Report these defects in a manner that is helpful to the folks who will be fixing these defects.
• Carefully confirm when these defects are reported closed.

That’s it. That was my job. Why was I failing? My memory is hazy, but I think we were many months (years?) away from having a testable product, so I was tinkering. Writing little throw-away automation scripts. Goofing around with a partially implemented product. Waiting for someone to tell me what to do. The features weren’t close to done, so no test plans and no defects were filed, so I tinkered. I goofed around, probably until the paper slid across the table.

Time to work.

Test plans. Yes, the feature was still being built, but two conversations with the engineers in the hallway quickly described what was and wasn’t working. Great, here is the first draft of the test plans for the working portions of the feature. Yes, they would change once the complete feature landed, but a partial test plan both framed my initial thinking and could confirm what was even partially working for engineering.

Find, report, and confirm defects. From the test plan. Yes, most of these defects were never fixed because the product changed so much, but the defects I filed demonstrated that I understood the current state of the product. When the defects were particularly heinous, they were fixed quickly.

And I asked for help. With the angry clock tick tocking in your ear, it’s easy to narrow your focus to what you can do right now, but the clarity you defined in the first challenge will only take you so far. You need help, and while asking might feel like admitting weakness, it builds strength. Your request for help tells those you ask that you care about their opinion and are serious about the work.

The Final Challenge: Exceed Expectations

You will succeed at this performance plan by achieving what your manager describes in the document. The final challenge might be optional, but I think it’s critical. I’ve repeatedly reminded you to face this situation stoically, calmly ask for clarification, and purposefully attack the work, but…

… it’s still a hit. An ego hit. I thought I was doing ok until I wasn’t. I was embarrassed when I realized what was written on the paper and ashamed while considering my next steps that weekend.

The final challenge isn’t just to do the work but to exceed expectations. My approach at Borland and whenever a helpful someone gives me constructive feedback is to hear it, address it, and act on it in a fashion that demonstrates that I am the expert.

My testing area back at Borland was database creation and editing for Paradox for Windows. The user interface to create a database and later change its structure. When I arrived, the user interface did not exist. Databases were being created and edited via the command line or the prior DOS-based version of the product.

My goal: become an expert in this area. Develop a deep understanding of the database’s characteristics, the different record types, performance, and storage characteristics. There was much to know, and little was written down, so I wandered the halls. I badgered the engineers for any data they could share. Yes, just scribble on the whiteboard. That’s fine. Product management? Tell me what you think. Hopes and dreams are fine. Here’s a piece of paper — scribble away. This is useful because, amongst the chaos of developing a 1.0 product, I began to have the clearest view of our goals for creating and editing a database.

Months later. Long after the performance plan was complete, I remember the head of product, an engineering director, and the engineer responsible for the feature walked into my office with a floppy disc. I grabbed the disc, installed the root, and hammered on the latest bits. No automated testing, just me running an ad-hoc smoke test — from memory — to assess the quality of these close to final bits. Took five minutes, and halfway through, the director smiled and looked at the head of product, “Told you. He’s the guy.”

I finished, spun around in my chair, and said, “It’s good.” Each of these humans was here because of the relationships I formed when asking endless questions about the product for which I was accountable.

The hardest part of a performance plan isn’t stoicism, understanding, or doing the work. It’s recovering from the gut punch that comes with recognized failure. Exceeding expectations isn’t about doing extra work but building confidence in one’s capabilities.

90 Days and Signature

You’re reading a recap of a performance plan that occurred decades ago, told as an idyllic tale of success designed to educate. I did eventually succeed at Borland, but I’m confident that I said nothing when the paper slid over. I was ashamed. I was depressed that weekend. I didn’t jump into Monday with vim and vigor. I was confused and spiraled into self-pity.

I don’t remember how I turned it around, but it started when I signed this paper that defined a deadline. It started when I accepted the failure of my prior work. I’ve used this practice over and over again through the years because I fail quite a bit. It’s never fun and often embarrassing, but it’s always an opportunity to start a learning process.

I do vividly remember one moment from the following week. I was sitting in a conference room that had been converted into cubes. I was staring dumbly at my screen when my manager walked in, sat on the edge of my desk, and stared at me momentarily before asking, “How are you?”

I responded, “I’m good. Let’s do this.”

So we did.