Building a Dev Team From the Bottom Up

Problem

When I built our very small team into a large cohort of 60 developers, I didn't know all the things I do now. Building a dev team consists of many different facets that can go awry if not well thought out from the beginning.

Actions taken

• First, I had to define the dev process. Whether it would be scrum, agile, etc... I asked myself what communication tools, developer tools, and languages I would use.
• I got my solution architect on board as soon as possible to help define the technical things as well as a business analysis to figure out communication tools and documents.
• I defined our development culture, describing what was to be expected of everyone in terms of workload, time requirements, salary, if they can work from home, if there be a budget for team lunches, etc...
• From there, I started working on my devs.
• Once we started arriving at the point of customers using products, I had to ask myself who was going to take care of support escalations. I added a junior developer as a tier 4 channel. When issues were determined that they need to go to the dev team, the junior took on support escalations while remaining focused 60% of the time on dev work.
• I hired interns to write test automation for test plans.
• I repurposed a project manager from another team and stole half of his time to get the team up and running by migrating him from a project management role to more of a scrum master role.

Lessons learned

• Defining the dev process as a first step helped to determine the type of people I wanted to hire based on those required skill sets.
• You may want to bring on a scrum master or project manager as needed to define all processes.
• If you are organized as you bring more people onto the team, you will have a well-defined process as you look towards hiring new engineers.
• Developers require a specific culture and if you can pull everyone in a room and give them the 'why' of what you are doing, you will get better results. Establish these things before interviewing to make them more attractive against competitors.
• If your culture is not well-defined, and new employees start coming in, it will be hard to keep them engaged at the beginning.
• You do not need a dedicated dev operations person if the dev team can take care of it.
• By having a junior take over support escalations, senior resources aren't interrupted through context switching. It becomes expensive when they are head down coding and they have to stop what they are doing and then try to pick up where they left off.
• Hiring interns is a good way to build a pipeline of juniors as the team grows.