by Alan Willett
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.
&n
bsp; • 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.
