Building My Very First Team

Problem

I joined a startup of only 20 people that was a subsidiary of a large car-sharing company. I was hired to help them create tools necessary to manage a fleet of vehicles run by this large company. I had some managerial experience but none with building a team of my own. Evidentially, I had to start from scratch.  As soon as I joined this startup I realized how disorganized it was, but it did work nevertheless. My first task was to build a team, clearly define its role and try to introduce the Agile methodology.

Actions taken

I had to start with recruiting the right people. I worked as a contractor before and was acquainted with many people who could help me recruit people quickly. I arranged for a contractor to do my first hires. I also discussed with my colleagues within the company what were the crucial issues that I should pay attention to during the hiring process. At that time we were aiming at 20 new hires and I decided to approach a hiring agency that helped us with creating effective hiring procedures. Soon after, not only me but a few more of my colleagues, became competent to make hiring decisions which allowed us to grow rapidly. 

Once I hired for all positions on my team I started to structure our internal procedures. I followed one of the key Agile pillars that prescribe to focus on people instead of processes and tools. I was curious to understand what it is that my team members wanted so that I can set up procedures that they will abide by. Therefore, we decided to go with a mix of Kanban and Scrum.

At that time, not only that our team was performing well, but I realized that other teams were still struggling with challenges that we managed to successfully overcome. I discussed our approach with my colleagues across the organization and they decided to replicate our method of hiring and organizational restructuring.

My own team continued to grow and it reached around 15 people. In the meantime, my efforts to make a positive change were praised and I was asked to do cross-company coaching with another colleague. My approach was even more applauded and I was eventually appointed a Director for Software Engineering.

Lessons learned

• Though I felt I was fairly familiar with most issues, I was never hesitant to consult and hire experts. My task was to ensure that things are running smoothly and to create an environment in which experts’ recommendations could be implemented. I highly value teamwork and always seek to act as a team player. 
• Every time when there is an activity that involves people, you should first and foremost be a careful listener. You should ask your team first what it is that they want. Even if you have created an ideal model it will have to be implemented by people. Once you talk to your team members and include their ideas and affinities, they will be able to apply it not only better but more eagerly. After all, it is their idea, their way of thinking and solving problems -- they own it!