Scaling an Engineering Team Effectively

When should I hire more resources?

I’ve started diving deeper into mentorship, both within Coffee Meets Bagel, and in the engineering community . At Coffee Meets Bagel, this is natural, as I have a team of around 20 engineers reporting up to me. All the engineers who report directly to me are leads or managers, so most of my mentorship within Coffee Meets Bagel is about how to effectively lead engineering teams, manage chaos, form relationships, provide mentorship, foster career growth, and operate efficiently.

Outside of my day job, I’ve started mentoring more high-level engineering leaders as well, and one of the common themes that has come up is, “How do I scale my engineering team effectively?” In this post, we’re going to specifically cover the topic of when to hire more resources, when to promote ICs to managers, and when to bring in a manager from outside.

It’s an important question at a startup especially because you want to move fast, but resources are limited. You should never hire more resources just because your company has plenty of resources or because your CEO wants to grow. There should always be some rationale behind it, and it should ideally always be a metric-based, analytical decision.

The most important types of questions you should be asking are:

  • Is the engineering team able to meet the product roadmap?
  • Are they able to meet the product roadmap with an acceptable level of quality?
  • Are they able to meet all demands of the marketing team and other key stakeholders in the business?

Clearly, if the engineering team can’t meet these demands, then there’s obviously a need to hire more resources and you should prioritize hiring where there’s the biggest bottleneck.┬áIn addition, I think you need to be constantly asking yourself:

“Are we able to meet the demands of all of our internal stakeholders while still maintaining a stable, performant system, AND not accumulating technical debt?”

In fact, I think the most important sign that an engineering team is healthy and adequately staffed is when they are making progress in paying off any technical debt that does already exist.

“How can I be analytical about this?”

If you’re not already, you should be working towards some system where you’re tracking velocity of each engineering team per sprint over time. I could write an entire post on best practices here, but the merits are undeniable, I think. By tracking velocity over time, you can get a pretty accurate view of how your engineering team is performing and it can give you early and hard evidence of warning-signs of potential under-performance. Also, by tracking velocity over time, you’ll start to get a very good idea of what your team’s capacity is per sprint. Then, based on that capacity, you should be able to give your product and marketing teams better estimates on when and if you can meet their roadmaps with your current resources. You also will have hard evidence you can take to your CEO if you have to ask for more resources.

I recommend defining some split percentage-wise between non-engineering work (like new feature development or feature updates) vs. engineering work (like re-factors, re-architectures, or just bug fixing / cleaning up tech debt). And this split should be dynamic. It should be an ongoing conversation between the engineering lead and the product lead. If engineering is in a decent state and there’s a large product backlog, we can devote more points in a given sprint to product features. On the other hand, if there are a lot of bugs or stability issues, maybe we need to devote more resources to engineering.

 

When do you need a manager?

Hopefully this will be obvious to you, but you can only have so many ICs reporting to you whilst be an effective manager and mentor for them AND be effective in all other facets of your job, whatever that may be. Managing people is hard. It requires frequent one on ones, ensuring there are career paths for your people, ensuring you have interesting and challenging work for your people, keeping them motivated and engaged at work, and getting buy in for your vision. For every additional person that reports to you, you’ll need to devote at least a couple of hours of your week to that person.

I think many of us are stubborn and have a false sense of hubris in believing that we’re such good managers that we can juggle the challenges of managing a dozen people AND still be able to think at a strategical level about the company’s priorities. We also find it hard to believe that somebody else could come in (or be promoted) and be more effective at managing all these people than ourselves.

You have to examine yourself closely. When you start to feel like the work of managing so many people is taking away from your ability to think big-picture, then it’s probably time to hire (or promote) a manager. Another indicator could be that if you just don’t feel like there are enough hours in the day to execute on big initiatives while paying attention to the necessary finer details, maybe it’s time to hire a manager to pay attention to some smaller details so that you don’t burn yourself out.

 

When to promote a manager from within

It’s a tough thing to do when deciding whether to promote one of your ICs into a managerial position or to bring in someone experienced from the outside. There are benefits and risks to both.

The benefit to promoting from within is that you are fostering career growth at your company, which is going to help your long-term retention of employees. Employees in all positions want to feel like there is some upward career-mobility for them. In addition, the person you’re promoting already knows your company’s domain and you know they fit into your company culture already. The risk of promoting from within is of course that the person may not be ready or mature enough for a leadership role and they haven’t yet developed the mastery of their domain that will be necessary to take your company to the next level.

The benefit to bringing in a manager from outside is that you can make sure you’re bringing in somebody with a track-record of success doing the thing you’re hiring them to do. If you have a good interview process, you can be reasonably sure they will come in and do a good job. The risk, of course, is that they don’t fit in well to your existing company culture.

Look for initiative, desire, mentorship, and respect

Initiative is the number one quality that I look for when making the decision on whether to promote somebody into a management position. I think it’s a huge indicator that the person will continuously improve their team’s processes and continually push the business forward, and I probably won’t have to micro-manage this person at all. I can trust they will do the right things for the success of their team and the company without me even asking. So, if you’re thinking about promoting someone from within, I’d want to see a demonstrated history of taking initiative.

Desire should go without saying. The person in question should have expressed some desire at some point to take on more leadership, to take on more ownership, and mentor their teams.

And they should be already exhibiting mentorship qualities to the other members of their teams. They should be going out of their way to aid their teammates. Their teammates should look to them as a valuable resource and subject matter expertise in their discipline.

And finally, respect. I’d never promote someone from within unless they already had the respect of all the other members on the team.

I think if you’ve got these four qualities (initiative, desire, mentorship, and respect), you’ve got a winning formula for your next successful manager or team lead.

 

When to bring in a manager from outside

I believe there are only a few good reasons to bring in a manager from outside:

  1. There’s nobody good internally
    If you have nobody on your team already who meets the above criteria, I wouldn’t risk it; just hire somebody from outside.
  2. It’s an area you’re weak in
    This takes an honest assessment of your skills. If you’re weak an area, and especially if either #1 or #3 applies, I’d take a good look at the benefits of bringing in a master.
  3. The team is young and/or inexperienced
    Even if you have somebody internally who demonstrates all the characteristics of someone you should promote into a leadership role, if that person and the entire team is just very inexperienced, it may be worth it to bring in someone with experience who can guide the team through the inevitable challenges.

Chief Technology Officer (CTO) or Individual Contributor (IC)?

Which path should you target in your career???

So LinkedIn just released a mentorship feature where they pair mentors with mentees through the app. I signed up as a mentor and got flooded with requests from young software engineers and surprisingly many young data scientists. The most common thing these young engineers want advice on is which direction to take their career.

Here’s a request from one such data scientist, let’s call him Ralph:
“I’ve been a data scientist for less than 2 years and would love to hear your advice on focusing as an individual contributor or growing as a leader towards the CTO path.”

I would love to help Ralph on a one-to-one basis, but unfortunately don’t have time in my life right now to meet and mentor with every young engineer and scientist that comes my way looking for mentorship, so I will point them here, and to this response:
“Hi [Ralph], unfortunately I can’t make time anytime soon to meet you, but I get this question a lot so let me give my advice here.

There is a lot of leadership you can explore without explicitly going down the managerial track. You can own projects, you can be the tech lead, you can volunteer more at work, you can start projects on the side, and you can mentor people. All of these things will help you figure out if you actually like dealing with people as part of your job, because the fact of the matter is that the higher up in the managerial chain you go, the more it is about managing people.

The other thing that I’d like to point out is there are a lot of great end games out there besides just IC or CTO. A lot of companies, including Coffee Meets Bagel, have an architect track for people who know they’re not interested in managing people and just want to immerse themselves deeper in code and architecture. End game for this track would be Chief Architect.

We also have our data science organization as a completely separate, high-level, organization from engineering which reports directly to the CEO. So, at some point, we will have a Chief Data Officer or a Chief Algorithm Officer. Now, those positions would still be very heavy on people management, but probably a little more specialized and more hands on than a CTO role.

I hope that helps. Happy to answer any other questions or dive deeper!”

And I hope some other young engineers stumble across this as well and get some value out of it!