What I learned from building a team from scratch
I remember the day my boss told me about a new opportunity to build a team from scratch, one of the biggest opportunities at the company, At that time, I was a software developer and loved what I did. This offer took me by surprise, and I had very quickly learn to grab this opportunity, to identify the skillset that I needed to improve and to manage a team of the size I supposed to build from scratch.
During the five years I worked with this team, I consider the most valuable thing I learned is:
You don’t have to hire the perfect match for the position if your candidate has other valuable hard-to-find skills.
“Hire for character, train for skills.” — Michael Josephson
The first task I had to manage was to find 18 good engineers. During this process, the company gave me a list of positions they believed I needed to hire to have a good team. They gave the profiles of each position, and I started to work with Human Resources to interview people for each position. This wasn’t easy for me because each position looked like a unicorn, hard to find.
After a few weeks, I understood I wasn’t going to find the perfect match, and I needed to change my approach. I talked with my boss to tell him I was going to look for people who had the motivation and learning skills who could grow into the position. From then, I started to hire people with some key soft skills like the ability to compromise and quality of work. With this approach, I found the 18 people in just three weeks, and I started to work with each one to try to find where they’d fit best.
Manage your internal and external clients’ expectations
“One of the biggest obstacles to high performance in organizations comes from unclear expectations and accountability.” — Ken Blanchard
From the very beginning, the company created an internal client who was responsible for managing all the external client’s expectations. Of course, this team interacts with my team to plan the following releases we had to deliver in key milestones. A release plan was difficult because there was a lot of uncertainty, which complicated the communication between the two teams. The expectations for each were just not clear. I immediately started to work with my client to improve the communication between the two teams. The key was to get to the point where the two teams didn’t need to assume anything.
Define my position in the team
“To build a strong team you must see someone else’s strength as a complement to your weakness not a threat to your position or authority” — Christine Caine
My boss told me I didn’t need to be the principal developer. I didn’t really understand that until one day we had to deliver a new version of the plan to our internal client. Late one night, the QA engineer and I were testing the application and found an error I believed was easy to fix. Well, I tried to fix this issue and deliver on time to our internal client, and that was a very bad idea. I went home very happy because we delivered a release with all the major features fixed, but I returned to the office to learn our client was not happy because he found new issues in the application that the previous version didn’t have. At that moment, I realized I’m not a developer, and I had to learn to help my team. The role I decided to play was to be the person who focuses on helping all the team members to grow and supporting the ideas of the principal leaders of the team.
This process helped me a lot to identify the skills I should learn to help this team succeed at the challenges we’d face in the next few years. And the first is to trust your team.
Learn to identify the situation where your opinion is just one of many
“Never miss a good chance to shut up.” — Will Rogers
As a leader, I had to face many situations when I had another point of view. This happens in any part of the process, defining requirements, designing architecture, implementing, testing and, of course, budgeting. I had a lot of discussions with almost all the stakeholders that help the complex process of delivering a hardware plus software solution in a world where deadlines are the law. At the beginning, I just tried to justify my point of view, but with time and experience I learned to identify when my opinion didn’t help to accomplish the goal. And in some cases, it complicated the situation so much it just added a layer complexity to the whole situation.
I started to evaluate all the tradeoffs of each situation to help make the decision that fit better in the situation. With this approach, the team began to make the best decisions just by improving the workflow, and I learned to evaluate whether the decision helped to reach any of the goals for the product. To my surprise, the team’s maturity and cooperative spirit started to grow. As the team grew so did I, and I began to help to make the best decisions for everyone.
Adding more members to the team is not always the solution
“No matter how great the talent or efforts, some things just take time. you can’t produce a baby in one month by getting nine women pregnant.” — Warren Buffett
After some weeks on the project, our client called for a meeting to discuss the main idea and whether there was a way to add more resources to shorten the time to deliver software with a lot more features. That looked possible if we could add very good developers to the team. Then, we decided to source parts of the plan to India, and that posed a problem. We found a lot of companies to help us, and I started to build the team in India, and at the same time, I added the last members of the team in Panama. We were now in different time zones with two teams, a very complicated situation for a new project.
After a few weeks, I realized the team in India needed a leader in India because I was spending so much time traveling between India and Panama the teams’ productivity slowed a lot.
So, we had to change the strategy for the team in India; it would work more on long-term features, and the team in Panama would work on architecture, in some way, to include the features the Indian team was developing into our base code. After that experience, I learned that if you have the opportunity to add more developers to a team, you have to be sure your software has to reach a maturity that can use a very good architectural pattern.
Identifying each team member’s best skill is a key to success
“ The strength of the team is each individual member. The strength of each member is the team.” — Phil Jackson
When each member’s best skill is identified, give that person leadership of that skill and emphasize the need for compromising with others. Together, these two approaches cement a unified whole.
If you work hard to help your team to grow as professionals and acknowledge their worth, you’ll win friends for the rest of your life.
Once the team was in place, each time we faced a difficult situation, a key milestone, a demo, or other very difficult compromises with a stakeholder, we could move people from one responsibility to another because they were working so cooperatively and I understood what each member did. I had to reorganize the team in a different way, just to make sure each member, including myself, contributed to a very critical task with his or her best skill.
I used to think that to manage a team and produce quality results was something anybody could do, that it didn’t require hard work. I was so wrong. This experience was really difficult, really challenging, and gratifying.
After five years with this team now, I’m ready to move to another opportunity, but I have to say thank you to all the members of this team that worked really hard to deliver all the successful projects we did. Thanks for your qualities as professionals and as people. I wish you all the best of luck and success.
