How to Build a Software Team from the Ground Up

Problem

Years ago, I was hired as the second full-time technical employee to join the software team. The company consisted of contractors who had a lack of trust and responsibility. Many of them weren't up for the challenge of taking on additional projects and creating engineering processes. When I entered the company, I knew it needed a change in structure, starting by changing the leadership team's mindset about the software team and the contractor-based model.The contractors had been in these positions for multiple years and had lots of experience regarding our company. However, there was a disparity between their fee and the responsibilities they could accept going forward. I was in a difficult position to either hire qualified contractors or let them go and fill that knowledge gap.

Actions taken

I worked closely with my manager to change the leadership mindset to establish that software is not a short-term problem solver but a long-term asset. Since our company works in renewable energy, this software would stay relevant as a decisive change in the world. I explained to the leadership that this system may be an expense now, but it will return a higher value later. This software would associate a lot of IP, and contractors couldn't be depended on to build it end to end. After establishing software as a long-term asset rather than an expense center, my leadership team was aligned with my mindset.

To simplify the transition, I used a 50/50 model. In this model, half our team was in-house senior employees, so that our team had that knowledge and direct control. We supplemented that by using off-shore vendors as the other half of our team. International vendors are cheaper than US contractors while producing high-quality work. The off-shore vendors gave my team much flexibility by covering many time zones and growing our availability. The 50/50 model maintained my company's budget while bringing more talent and flexibility to our team.

Once we developed the model, I identified valuable contractors within our organization and converted them to full-time members. To replace outgoing contractors, I had to hire an external recruiter who would bring talent to our company without an extreme commission rate. Once the external recruiter was established, the hiring process became more manageable for me, bringing in high-quality candidates. I had to verify that there was not a knowledge gap between previous contractors and new hires. When there was, I leveraged a senior engineer and my own experience to fill any gaps. We began this process before hiring new talent, as once employed, our contractors wouldn't be inclined to share their knowledge of our company.

Initially, there was no process around development, so I brought in agile. I established boundaries and had mandatory agile training. Lastly, I created a dev-ops team to automate all the deployments after the team understood our processes. After we had automation, I took away manual steps one by one, as they cost more to the team. After establishing these processes and enforcing agile, the team understood their responsibilities and workflow thoroughly.

Once these changes were made, the quality and value delivery increased. Our team was invested in what they were doing, rather than not being connected to our mission like before. I invested in team-building activities to bond our team and bring a sense of belonging into the workplace. We created a quarterly roadmap together as a team, and as a result, motivation and value increased.

Lessons learned

• In markets such as the Bay Area, hiring is complex and more time-consuming without a recruiter. To find quality talent, be prepared to work long hours and perform many interviews.
• Employees join a team based on initial offers; they stay based on their work and leadership. Motivations were working with clean energy, developing challenging software within an enterprise, and creating a healthy work/life balance.