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…
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.
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.
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.