When to Hire Senior Engineers and Tech Leads

Problem

I moved from San Francisco to New York as a site lead tasked to start an engineering function. I had only a couple of engineers with me and had to develop a charter and build two more teams quickly. The imperative was to move quickly and hire fast. The mistake I made was to hire too many junior engineers at the very beginning. As a consequence, I had to oversee the work of three teams neither of which had a team lead. I was shifting my focus from one problem to another, unable to pay attention to everything that was going on. Things would often escalate to me too late or I would learn about some wrong decision belatedly.

Actions taken

When you are building a team from scratch, you should disregard the pressure from the business to start delivering as soon as possible and instead focus on building the team structure. In my particular situation, I learned too late that I should have brought in tech leads first and only then add mid and junior engineers. That would allow me to scale myself more smoothly without having to spread myself thin across three different teams.

I first-hand experienced that the problem would only get worse with time. As more junior engineers would join the team and delve into writing code, stakeholders’ expectations would increase because there would be more people on the team. But, the problem was that without a team lead, their hard work may not be going in the right direction.

I have no universally applicable answer to when is the right time to hire or promote your first team lead. Based on my experience, that would be once a team is comfortably staffed and translated into numbers that would be when there are five to six people on the team already. If, at the same time, you should start another team focused on a new problem area, a senior engineer should be placed with the first team.

Hiring senior engineers is never easy. There is a higher availability of talent in San Francisco; however, the demand there is also higher. Also, the NYC community is smaller and somewhat tight-knit. Site leads are in most cases people who lived in that particular area and I, contrary to the common approach, had never lived in NYC and had zero contacts there. So I had to build a team with no network. I tapped into a network of people in San Francisco who wanted to relocate to NYC and also reached out to friends of friends who happened to be in NYC. I was looking for people who w for various reasons a Silicon Valley startup but for various reasons decided to stay in NYC. I was selling them my current company as “a taste of Silicon Valley brought to NYC” and I was able to get my first 20 engineers by tapping into these two networks.

Lessons learned

• When you are building teams, get leads first and then build the team around them. A high-performing team should have a leader, a small layer of senior engineers, and many junior engineers.
• When a new project or problem area is assigned to you, it is tempting to start moving engineers around placing the most experienced ones on the team that will work on a new problem area. Instead of merely reshuffling people you should redefine charters or assign the problem to another team keeping the well-structured team intact.
• Opportunities shouldn’t be static or strongly molded. You should model the opportunities to attract candidates who would make a good fit in the long-term. Hiring engineers while sticking strictly to rigidly defined job descriptions is not how you should approach hiring. Both sides should be adaptable. If you find someone who is competent and wants to work with you, you should re-think those opportunities.