What did we learn?
#1: Set the Ground: My first step was learning the technological domain and the skill-set required from the team. I invested my time in two areas: The technological domain and the project milestones. In order to achieve this I partnered with the software architect of the company and we did paired research. Within a few weeks we came up with a mutual understanding of the required technology and an understanding of the process and milestones needed to complete the project.
#2: Incremental Team Building: We estimated we would need a team of three for this mission. The debate was whether to recruit the team at once, or do it gradually. On one hand, this project was urgent and we wanted to build a team fast. On the other hand, recruiting the entire team at once would reduce our chances to get to a team that operates in harmony, as it is hard to forecast how team dynamics will be. Eventually, I decided to build the team gradually. My first move was finding a team leader. Fortunately, I knew of a great person for the mission. That person wasn’t a perfect match from a technology perspective, but I knew that her leadership skills and her learning curve were remarkable. My intuition didn’t fail me. She took over the technological domain and the project milestones within two weeks. We were ready to onboard our second team member.
#3: The Power of Diversity: When we looked for our second team member, we looked for diversity, someone that could extend the skillset and complete the team. After talking with some of my colleagues, I got a green light to recruit someone from within the organization, someone that already knows the company products, the internal technology and the internal development process. I initiated an internal recruitment announcement, sent an email explaining what we were looking for, and welcomed employees to approach me for a non-official discussion. Quite a few employees asked to learn more about the new position. I empowered the team leader to take the final decision on who she wanted to recruit. A week later, we had our second team member in place. After a couple of weeks, it was time to recruit the third member. We looked for someone who had a lot experience in the specific technology of the product, someone that could deep dive into details and cover long specification documents. More than anything, we looked for someone who would have great interaction with the existing team. I believe that the team’s power is much greater than the sum of its individuals. I fully delegated the recruitment mission to the team leader. Shortly after, she found someone who she believed would be a great fit for the team. That person introduced further diversity to the team, it was exactly what we were looking for.
#4: Use Agility for Speed: One of the main metrics that the business has set for this team was speed. We had to reach a major milestone fast. To achieve that, we used agile practices throughout our product delivery. We decided to work in iterations of one week, while performing short experiments and re-adjusting our plan at the end of each iteration. Using that approach, the team’s learning curve was fast. We had small failures along the road which helped us adjust our project plan. After 14 iterations the team achieved the first milestone. According to the external vendor we were working with, this was one of the fastest teams to hit such a milestone. That was objective proof for the speed of the team. As a side note, we didn’t compromise speed for quality (although we had a few discussions along the way about the tradeoffs).
#5: Partner for Success: As the team was mostly new (except for the internal employee that joined), we knew that a partnership that was technology savvy within the organization would have great value. The team established a partnership with the software development architect of the organization. Although escorting this team wasn’t an official part of the architect role, he kindly agreed to escort the team throughout the development cycle. This was a win-win partnership. The team earned great value from his feedback and inputs, while the architect had the chance to apply advanced architectural techniques within the new product. This partnership was crucial to the fast progress of the team and to solid software design foundations.
#6: Lesson Learned: As a new manager in this organization, I must confess that I had doubts about how to build this team. Whether I gave too much emphasis to the human factor over the technological aspect, whether intuition about people was more important than what was written in their resume file, and whether diversity would have crucial impact on success. Looking back, I got strong evidence that:
- The human aspect is stronger than the technological one
- A team’s power is greater than the sum of its individuals
- Partnership with people can happen outside of the official organizational structure
- Diversity is a key factor for success
Replies to This Discussion