Coaching Your Software Development Team for Growth and Success

Coaching Your Software Team for Growth and Success

A Management Tale: Where has my Productivity Gone?

This was the model group, at least until recently; Andy, Tina, Brad, and Kelly. They were a software manager’s dream team. Widely regarded as the most talented software team in the company, they continually delivered on important strategic objectives.

They’d worked together for a significant period of time, and had subconsciously developed rules of operation that had optimized their productivity. Their previous manager Tom had been very skilled in recognizing strengths and interests of each of his team members. He had done everything possible to make sure tasks were aligned accordingly. While Tom was always willing to provide advice and guidance, he made sure not to micro-manage. Since each of his team members were working in their areas of strength, he empowered them with a significant amount of latitude to make decisions within those areas.

Andy was the longest tenured employee on the team. He was a developer with immense historical product and organizational knowledge. Architecturally brilliant, he was amazing at understanding strategic organizational objectives, and then crafting the technological architecture to support those needs.

Brad was the user-experience expert. While his development skills were decent, it was his ability to think like the end-user that really made him valuable. He took an iterative approach to improvement. He was constantly making small application tweaks that improved the user-experience. His contributions were often overlooked because there was never a big release associated with his work. He just continued to evolve and improve the user-experience over time. However, Brad’s value became apparent when comparing the usability of other team’s products with those produced by his team.

Tina was the master of the tasks. While not as experienced of a developer as the others, she was an amazing implementer. While Andy set the architectural direction, and coded up the architectural skeleton, it was Tina who completed the implementation. With a little guidance and direction from Andy, Tina was the one who fleshed out a majority of the implementation details.

Kelly was in charge of QA, and she approached automation with a fanatical zeal. If she wasn’t able to create a functional automation test, she worked with the developers to create automated unit and integration tests. While she was intimately familiar with the products that the team developed, her focus was on asserting that the product did what the team said it did. User-experience wasn’t her interest, and wasn’t her focus. Onerous user-experiences didn’t matter to her. Once she’d created an automation script, she often didn’t revisit that functionality unless it changed or one of the automated tests failed.

While the team wasn’t perfect, they had organized and divided work in such a way that accentuated the strengths of each team member, and compensated for each of their weaknesses. With a team aligned along its strengths, the group continuously delivered on key strategic organizational objectives. As a result, Tom was promoted to another area within the organization. To backfill the vacancy left by Tom’s promotion, the organization hired Jeff to manage the team. Jeff was a development manager with a number of years of experience, and had managed numerous teams of different sizes and configurations. He had originally been a developer, and his technical background was solid. The team had liked him during the interview process, and his experience made him seem like a good fit to lead the team. However, over the course of several months, they’d begun to have their doubts.

Initially, Jeff had let taken a hands-off approach. He let the team continue to operate as they had previously. But after a few months with the team, he had been making some changes. In an attempt to understand the product and product architecture, he’d started pulling Andy into numerous architecture meetings. He’d asked Andy to create extensive architectural documentation that was beginning to take significant amounts of Andy’s time. It appeared that Jeff was the only consumer of this extensive documentation. Apparently it helped him feel more in control of the situation, but it was really a drain on Andy’s time. Additionally, since Jeff also indirectly managed a maintenance team that handled customer support, he was beginning to pull Andy into various meetings related to customer issues. While Andy’s extensive product knowledge was valuable in this context, it began to significantly impact his role within the team.

When he addressed this issue with his manager, Jeff suggested that Tina should take on more architectural responsibilities. And since Tina would have less time for implementation, Brad would pick up the addition implementation responsibilities. While this would leave less time for Brad to work on user-experience tasks, Jeff wasn’t too concerned. He’d always felt that user-experience was a bit overrated. He felt the Kelly could provide adequate input regarding user-experience. Any other usability issues could be explained-away via extensive user documentation.

After a number of months operating in this fashion, problems began to emerge. Tina discovered that she didn’t particularly enjoy software architecture. She wasn’t particularly good at it either. She required extensive oversight from Andy as her architectural solutions were often sub-optimal.

While Brad was able implement solutions, it wasn’t his passion, and he wasn’t nearly as efficient as Tina. The product timelines began slipping. Since he no longer had time to focus on the user-experience, his first implementation was usually his last for any given feature. He no longer had time to iteratively improve and simplify the user-experience. The product began to take on a noticeably more cumbersome feel.

For Kelly, it was business-as-usual. She kept cranking out automation scripts. She continued to validate functionality according to the product specifications. The particular implementation didn’t matter to her. Cumbersome or simple, her scripts worked the same.

Overall, the impact to the team productivity was devastating. By shifting the team members away from their areas of strength, it caused lasting ripple effects that ultimately sabotaged the efficiency of the entire team. Team morale began to slip. Team member’s interest and job satisfaction began to wane. Something needed to change…


Coaching Rules for Team Efficiency

The job of a coach is to know and understand how to get the most out of each member of the team. A team is not just a collection of individuals. It is a group of people united around a common goal, with each member contributing in the way that is most beneficial to the team objectives. It is extremely important to keep the following in mind when looking to optimize your team’s performance.

  • Optimize for Strengths – One of the keys to being an effective coach is to have intimate knowledge of each of your team member’s strengths. Using this knowledge, you need to build an operational strategy that involves leveraging strengths. Too often, team leaders focus on improving weaknesses of individual team members. Instead they should focus on leveraging strengths as much as the team workload and product assignments will allow.
  • Compensate for Weaknesses – The flip-side of optimizing for strengths is compensating for weaknesses. You need to understand team member weakness like you understand their strengths. When you are crafting your operating plan around their strengths, you need to also account for each team member’s weaknesses, and make every attempt to compensate or mitigate them. This will help limit risk exposure and increase operating efficiency.
  • Foster Passion – In addition to understanding strengths and weaknesses, you need to understand what motivates and interests each of your team members. Assigning work that aligns with the interests, strengths, and the needs of the team will help maximize individual and team productivity. There may be times when you encounter team members whose passions are different than their strengths. In these situations, you may need to be creative in presenting work opportunities for them that are related to their passions, but still manage to leverage their areas of strength.
  • Set Reasonable Expectations – Part of maintaining positive momentum and energy in each of your team members requires that each member continually feels a sense of accomplishment. You need set reasonable expectations for your team members. The work and guidance you provide for them should challenge them to grow in their careers, but it should not overwhelm them.

Communicating Objectives and Providing Context

As the coach of your team, it is extremely important to make sure that your team understands the objectives that you set for them both personally, and as a team. A responsibility of the coach is to provide context to both your team and individual team members. Not every member of your team will always understand why certain tasks or objectives are important. It is your duty to make sure they know what value the objectives provide to the organization. This serves a number of purposes.

  • It unites your team around common goals or - People like to be part of something “big.” By providing them context, you allow them to participate in the big organizational objectives. Being part of a greater cause helps unleash the employee’s intrinsic motivation thru the feeling of cooperation and accomplishment.
  • Spur team member creativity - There may be things that could be done to support team and organizational objectives that haven’t occurred to you. Providing context for your team empowers them to take ownership of objectives, and will often inspire team members to dream up creative ways to support organizational goals.
  • It creates focus and direction – By providing appropriate context, you help your team members stay focused on what’s important. This will help keep them from being distracted by requests from other team members, other teams, or other leaders within different parts of the organization. This context will also help them prioritize random requests, as they can be analyzed in the context of how they align with the primary team and organizational objectives.

Summary

To effectively coach your team in a way that maximizes performance, you need to have a fundamental knowledge of each team member’s strengths and interests. You also need to understand and communicate the strategic objectives of both your team and your organization. Use this information to craft an operating plan for your team that places each team member in a role that aligns their strengths with the needs of the team and the organization while mitigating individual team member weaknesses.


Related Posts