Follow Through: A Bridge to Enduring Improvement

I have participated in various sports activities and follow through was a key to success in all of them. For example, in tennis, as in any racquet sport, the most powerful serve or return occurs when the whole body is properly prepared, moves, and follows through. If follow through is not done correctly, it jars the whole body, and also ruins the shot!

Note that you can have terrible form while serving a tennis ball. You might get an ace. However, without truly proper form and follow through, you will find the ace is just an accident.

Sometimes taking the actions prescribed in the previous chapter does work almost like magic. Things get better immediately and stay better. However, without follow through, you will find them to also be happy accidents.

Leaders must always be prepared for follow through. In many situations, the conversation is the start, and the leader’s next step is to help the person to build a bridge to successful improvement. To create a bridge for successful improvement you must start with the following three clear expectations.

The first expectation is to have the intention for successful improvement through collaboration. That intent of success should be one to energize and build trust not just with the individual, but also with the team of people around that individual.

The second expectation is that you as the leader are accountable for the success of the initiative you are undertaking. It is not right for a manager to abdicate responsibility to the Human Resources Department. If it is appropriate in your situation to engage HR officially, please do so because the department will be helpful to work with as a partner, but not when you abandon your authority and responsibility. The best success is achieved when you work directly with the individuals involved.

The third critical expectation is that you start with the belief that success is probable. Chapter 7 details how to make the decision to “remove or improve.” This chapter assumes you have chosen the course of action to improve. If that is the choice, start with the belief that improvement is not just possible, but likely.

The Case of the Expert Everyone Wanted to Run Away From

Alison was leading another significant software development project. Hank was a technical genius and responsible for the fundamental architecture and design of the software system. The project started strongly, but now that the team was well into software development, Alison was seeing problems emerging repeatedly. The other software developers were complaining that Hank was going into the system and rewriting their code without ever talking to them. He was also repeatedly sitting with people as they were writing code (without being asked) and telling them what to type.

Besides the other developers getting more upset and less engaged, this behavior was causing Hank to get further and further behind on the work he needed to do. When Alison talked to Hank about this he became agitated and told Alison that without him, these developers would destroy the system. Alison knew from experience that the developers on the project were excellent.

How could Alison get Hank to be a force for good?

The Key Points of Alison’s Preparation

Alison took some time to prepare. She talked to many of Hank’s teammates. She discussed and reviewed the designs before and after Hank’s intervention. It was clear to her that Hank’s intervention had led to minimal improvements to most of the designs. There were a couple of exceptions that were important, but they did not discount the trend. Further, she reviewed the project plans in detail. It was clear to Alison that Hank’s actions were negatively affecting team progress.

Alison knew that for Hank to improve, he needed much more than a “stop that.” He needed to have a compelling “do that” to help him actually remove the negative behavior and work toward a bigger goal. With this in mind, Alison prepared for the feedback session.

Feedback Session

After opening pleasantries, Alison started. “Hank, you are an excellent architect. I have a question. Do you want to be an architect of a few buildings or a thriving city?”

Hank asked, “What do you mean?”

Alison explained. “Hank, currently you are spending much of your time with a few software developers, helping them with their designs and code, sometimes even rewriting. There are two problems here. First, developers are getting very frustrated. The more significant problem is that this project is much bigger than those few buildings you are focused on. Most important, there are more projects that are ready to start. I really need you there. So again, do you want to be an architect of a few buildings or an architect of a thriving city?”

Alison waited while Hank sat pensively for a long moment. “Yes, I see what you mean.” Another pause. “But, I don’t think those developers are ready. Will those pieces of code, those buildings, be good enough without my guidance?”

Alison listened and thoughtfully responded, “Hank, we can discuss that, but first I want a clear answer. Which would you prefer to be? Take your time to answer. Which would you prefer and why? Convince me that you want that. What would it mean for you? For our projects? Which is more important to you? What would be most valuable for us? Once I know where your real motivation is, we will build a plan to help you achieve that goal.”

Hank answered immediately that he would prefer to be an architect of cities and went on to give many reasons why that would be exciting. He also saw opportunities to help improve the productivity of the organization because he saw how improved architecture could improve software reuse and lead more quickly to new product lines.

Alison stopped him after a few minutes with a big smile. “Okay, Hank, I am convinced. I want what you want. Let’s stop here and schedule a longer meeting. I would like you to bring to that meeting a few things: first, a summary of your goals and second, a list of the risks that you are worried about if you stop doing your current work on ensuring that these developers do things right. Then we can build a plan together for how to achieve those goals and address the risks.”

Alison and Hank agreed to a meeting time. They needed to create a plan for successful follow through.

The Fabric of Successful Follow Through

The properly conducted feedback session puts people on the road to success. Follow through is critical to ensure success. Here are three reasons why.

1. Habits are hard to break. Often, the taxonomies of troubles outlined earlier are habits. The perpetrators may not want to be exhibiting these habits, but because they are habits they often happen. This is especially true in times of stress.

2. Even if the problem is not a habit, there has been a disruption to a previous pattern in the individual and perhaps the group. The intention to improve is the necessary start, but that alone is often insufficient to solve the problem.

3. Success for the individual, the project, and the organization is important. The responsibility of the leader is to the group. Bringing the individual up to the level of expectations of being a positive contributor to the group is your obligation. Thus, follow through is as important as taking the initial action.

The following are some simple yet effective ways to follow up.

Make a Plan

Intentions rarely work without a detailed plan. For example, I have sometimes discovered that people lack competencies needed to do their jobs more effectively. We would then make detailed plans to get them the proper training that would fit their learning styles and objectives.

These troublesome situations have often disrupted the ability to deliver on commitments made by the organization. Plans may have to be refreshed to take into account any corrective actions. It is possible that you may need to have further discussions with other organizational stakeholders or even customers.

Publicly Commit

Have the person make a public commitment to do things differently.

When people expect a behavior and see that it isn’t present, they will seek to evoke that behavior. I worked with an executive who often would get upset about various issues to the point of explosive outbursts of anger in public meetings. He was working in secret to not have explosions of anger. People who attended his meetings were so used to these outbursts that they got anxious when they didn’t occur. Attendees would begin to bring up issues that in the past had caused outbursts. They would do this until he fulfilled their expectations with an angry response.

It was only after he made public his desire to eliminate those outbursts that he was able to make the improvement successful and permanent. His staff was very surprised and humbled to learn that the executive was more upset about his behavior than they were. People shared their own stories with the executive. They agreed to help him. The executive inspired his whole organization with his public commitment to transform this behavior from troublesome to tremendous.

Coach Others on How to Help

A critical factor of success often involves talking with a few of the key people who are involved on a daily or at least weekly basis with the person working on a new behavior pattern. I have coached them on how they can give feedback to the individual that helps lead to the positive difference.

With these things in mind, Alison set out to make a plan for success with Hank.

Plan for Success

A plan for follow through should always focus on a clear vision of where you, the individual, the team, and the organization want to end up.

In Alison’s session with Hank, they took less than 90 minutes to create an action plan that made them both confident of success.

Have a Vision of Success

Hank came in with what Alison requested. He had detailed the vision of what his job should be in two or three sentences. Alison and Hank spent fifteen minutes shaping it more until they were both satisfied they could show it to others. The vision statement of success they wrote was:

We envision a system architecture that enables high-quality products for our customers and boosts productivity across our division by enabling more product lines with less effort.

The system architect will provide the architectural foundation for our division’s software product line. This will be done through the following activities:

• Providing the overall architectural concept.

• Working with lead software designers for consensus on the best approaches that enable global gains without sacrificing specific product line needs.

• The system architect will make decisions where consensus cannot be reached in a timely way.

• The system architect will provide mentorship of lead software engineers.

Hank was anxious to talk about his risk list, and Alison listened. Hank did not trust the competency of the development teams to build the software the same way Hank would do it. Alison delayed that discussion. She simply said “I understand the risks you are talking about. I need to think about those. We will come up with actions to address your list. First, let’s cover the benefits and indicators of success.” Hank agreed.

Benefits of Success

Alison and Hank made a list of the benefits of success, which included the following.

ORGANIZATIONAL BENEFITS

• Remove technical barriers between product lines.

• Enable reuse of software across product lines.

• Enable more developers to understand how each product line works such that people can move between products more easily and be productive in each product line much faster.

• Get products to the marketplace faster.

• Enable significantly more revenue for the organization because of increased productivity of the software teams.

• Enable more revenue streams based on innovations possible from this.

TEAM BENEFITS

• The more people who understand the architecture and the premise behind it, the more autonomy developers will have.

• The developers will feel more ownership of the products and get more gratification from their work.

• It is likely to decrease attrition.

• It is likely to attract more top talent.

PERSONAL BENEFITS FOR HANK

• “I will be an architect of thriving cities.”

• “People will not cringe when they see me coming.” (Alison did not know that Hank knew this. He did know and he did care.)

• “It will be very good for my career.”

• “I will get great satisfaction from seeing others grow in their skill sets.” (And he added when he wrote this, “I really need to do less. I shouldn’t write the code for them!”)

Indicators of Success

Alison then said they needed to answer this question: “What are some things we would see to know if we were both successful?” Hank, being a software engineer, loved this. He started talking about how, for any successful software development project, there must be testable success criteria. He loved this idea.

Their success indicators were the following four ideas.

1. People smile more often than they cringe when they see Hank coming. (Note: This was Hank’s idea.)

2. When Hank inspects people’s code, most of the time it needs no changes from an architectural perspective. This would indicate that people understood the patterns and accepted them as best practice. Alison actually pushed for a number here and they agreed that 70 percent or more was a good starting number.

3. Hank’s design meetings were well attended.

4. Hank and Alison also agreed to do an anonymous meeting survey every six to eight weeks to check on the usefulness and energy-producing levels from the meetings. They want to make sure this was working well.

Follow-Up Actions

Alison and Hank were both excited and tired. It was over seventy-five minutes into the meeting. They quickly wrote down the actions they were going to take.

Hank agreed to talk to the developers and tell them his new plan. Alison agreed to write down all their agreements from the meeting and send them to Hank.

Alison later realized that she made two significant mistakes in the meeting. She should have set up the meeting for longer, or just set up another meeting for later that day so they could finish. They were both so happy they missed two significant things.

First, they did not come back to the risks that Hank was worried about. He was so happy by the end of the meeting he forgot about his concerns, but only for the moment. He was still worried about the competency of his fellow developers and that would be a problem later.

The second problem was interrelated. They did not have a plan to get Hank the support he would need to change his long-time habit.

Neither of these mistakes was an ultimate barrier to success, but it did slow down the success path.

Alison also told me that she realized this was the job she always thought Hank should be doing. However, she had never clearly articulated it in her own mind. She had just let the generic job description be the guide. She had not taken ownership of making her expectations clear. She realized that she should have had this very discussion with Hank long ago. She also realized she had a list of other people she was now going to have this discussion with before there was trouble.

Do Periodic Check-ins

One manager I worked with did a very good job setting expectations with a troublesome employee. In that next week, the employee showed improvement. The manager found himself distracted with other things and did not check in with the employee or the situation until about sixteen weeks later. The situation had decayed to a worse place then it was before. This should not be surprising, as there was absolutely no planning or follow through.

It is important to do periodic checks. These do not have to be long. The most important thing to do in these cases is to focus your check-ins on the new behaviors you are expecting to see. It is important to ask direct questions. If you get an answer of “Things are going well,” you must ask for examples that provide evidence of behavior change or lack thereof. The details will provide you with the real information you need.

Alison was very good at doing check-ins. Within two weeks after the Hank planning session, she was checking in with developers who she knew previously had issues with Hank. They were at first not open about the problem. They did not want to disappoint her. When she asked for details of interactions, however, it became clear that Hank had not changed his behavior.

When Alison asked more questions she found that Hank did not really set out his intentions very clearly to other people. He had told them that he was going to be doing more high-level architecture but no more details than that. Much later, Hank confessed that he was so embarrassed about his previous behavior he didn’t ask for the help he really needed. He told Alison this when he was thanking her for the next action she took.

Alison talked to Hank and said that she was setting up a meeting with the key developers, Hank, and herself. She wanted to make sure that expectations were set in a way to help achieve the vision they agreed to. The intention was to make sure that the developers Hank had been micromanaging would push back if he fell into previous habitual behaviors. Hank agreed, albeit a bit reluctantly.

Surround People with Support

Alison prepared well for the meeting. It did not take her long. She simply had her questions ready. She was going to follow a pattern similar to the planning session she had with Hank. Alison wanted to make sure that the people in the room were not just listening to what she had to say. Active involvement was required!

Alison could have walked in with some nice visuals and projected them on the wall screen. Or she could have had handouts that represented the vision, the benefits, and the indicators.

It would have been efficient. However, it would not have been effective.

Here are the key steps Alison took with the team.

First, she engaged the team to improve the vision they had drafted. Hank wrote down the elements of his vision on the whiteboard. Alison gave the people in the room three minutes to write down other ideas or questions they had. When Alison went around the room she found a great discussion about the vision. There was excitement about what it could mean for all of them. They naturally started to talk about benefits.

So Alison stopped them and asked them to each take five minutes to write down the key benefits they saw for themselves and for the company. She also asked the team members to write down what they thought the key benefits for Hank were. Alison encouraged people to write things down so they would have the time to really think about things. Also, writing engages a different part of the brain. The resulting conversation was amazing to Alison and even more so to Hank.

The group had a long discussion about the frustrations they were having and how removing them would enable them to grow and learn as developers. It would also remove fear for them of having their work reviewed by Hank.

These feelings could have been perceived negatively by Hank. However, everything was said respectfully with Hank and his goals in mind. And even more important, Alison started on the foundation of benefits for Hank. People wanted to see Hank happier, and they said that he didn’t seem happy doing work the way he was currently doing it. They really enjoyed Hank when he was in his space of designing architecture and introducing it to others. This would free him to be where he was most happy. Hank realized they were right. He told me later that he didn’t realize how much people actually cared about him.

Hank told the group about his worries and how it is so important that the architecture be implemented correctly. He gave examples where it was not. They had a discussion about that and Hank realized that most of the time it was correct. And when it wasn’t correct, the team either asked for help or fixed it themselves.

Hank asked the group to help him know when he was getting too deep into the technical areas that they should own. With much laughter, the group came up with a “warning word” to let Hank know when he was doing the work in a way they didn’t want him to be. The safe word was micromanager, and that word was actually Hank’s suggestion.

Provide Space for Learning New Behaviors

In writing condensed versions of these case studies, it is too easy to make them sound like things were easy. It is too easy to make them sound like there were instant changes.

As noted, this can happen, but change is hard. It is more likely there is an apparent instant change in aspiration. People want to do well. And sometimes they have a remarkably good start.

However, good starts are often followed by stumbles into the previous behavior. These stumbles can be caused by stressful situations, when people often revert to whichever habits were their strongest behavior patterns. Sometimes, people are so used to behavior patterns that the strange new behaviors will make people “poke” them and try to change them in ways that bring back the familiar behavior. Occasionally, someone who had a great focus on the new pattern will go on vacation and somehow get reset and come back to work in the old pattern again.

Hank had a combination of a vacation and coming back to a code review, where he discovered that an engineer had not followed the architectural rules. Hank immediately started to rewrite the design and code for the engineer. He was actually typing the code on the engineer’s personal computer! The engineer sat there quietly resenting it but let Hank do it. It was a familiar pattern, and Hank truly thought the engineer was thankful for his intervention.

Later that day, Alison was following up with that engineer and Hank in a meeting on a new feature request. She learned about what had just happened that morning. She called for a ten-minute meeting with just her and the two of them.

The meeting was as short as Alison promised. Alison said she wasn’t worried about Hank’s mistake. She was worried that he was not going to get the support he needed to achieve his big goals. She knew that people need the space to make mistakes—and also the space to recover. She was focused on ensuring that there was rapid learning and correction. In ten minutes they came up with three actions.

Alison and Hank decided to have a ten-minute check-in with each other at the start of each week for the next four weeks so that they both stayed on track with the new expectations.

Hank said simply, “I made a mistake and I actually noticed! About halfway through I sensed I was off track, but I pushed on. I should have stopped and checked in. I will make sure I do that when I feel things are off.”

The engineer apologized. He said “I really should have said the micromanager warning word. It just seemed rude.” Hank said, “It wouldn’t have been. I might have been startled and maybe even initially angry. However, it would not have been about you. I would have been angry at my mistake.” The engineer said he would tell his teammates about his mistake of not letting Hank know and about their agreement to not let it happen again.

Over the next four weeks, there were some similar mistakes. But they happened significantly less often and were caught when they were occurring. Hank also found himself involved in the start of other projects that truly made him responsible for architecture across connected product lines. He was very gratified that he could now handle the work. In the past, the current project would have consumed him and prevented him from doing the higher-level work required.

Set the Bar High

It is important to set the bar of excellence high. It is a leadership mistake to recognize just effort. It is more important to recognize when success is achieved.

The key to the success of Alison’s leadership is that she didn’t dwell on the past but kept a positive view on learning with a future focus. In her ten-minute meetings with Hank on Mondays she would ask Hank which of the benefits they agreed to were being realized.

She didn’t focus on mistakes. She kept Hank focused on his high bar. This bar of success was mutually created and agreed upon by Alison and Hank. Hank found this extremely motivating, obviously more motivating than hearing every week “Well, you did it wrong, again!”

Also, Alison encouraged Hank to recognize his own success and progress. She reinforced his observations with her own observations and suggestions. She did appreciate his effort, but her main focus was on recognizing not the effort but the achievement.

When her check-ins with engineers revealed that Hank had a flawless week with them as well as being successful with the new engineering projects, she knew it was time for public recognition. She suggested to Hank that they arrange a thank-you lunch with the key developers who helped Hank achieve his success.

It was a powerful recognition of the effort and the journey, but even more important, Hank and Alison had created a bridge to successful improvement.