8 ms·

Tripling an Engineering Team in Six Months: Setting Up for Success

71 points by zacsky 9y ago

zacsky 9y ago
In 2016, after being acquired by private investors, we were given the green light to triple our engineering team as fast as possible. In this article (part 3 of a 5 part series) I focus on all the preparations required before starting to hire.
- faitswulff 9y ago
  I skipped ahead to the 5th installment - how do you know if a hire was successful past the first month of employment?
  - zacsky 9y ago
    A lot of the things I recommend doing in the first month are just repeatable for the length of their employment. But there is a greater question I think you are asking around how do you know when you made a good hire? That's a big curly question probably worthy of a follow-up post.
mooreds 9y ago
I enjoyed all 5 parts of this in depth series. Would be nice to have a 6th post about how the engineering team ended up being organized, but all in all a great overview of the goals, techniques and tactics needed to make a big hiring push.
- zacsky 9y ago
  Thanks for your comment. Glad you enjoyed the series. I did consider a 6th article looking at the longer term outcomes but decided at the time to cut it. Might have to reconsider as there seems to be good interest.
  - davidbanham 9y ago
    That's the bit I was interested in reading. The level of detail in the hiring process turned out to be really good. The thing that got my attention about the series, though, was "Ooh, I wonder how they handled communication and work distribution among the organisation."
pfarnsworth 9y ago
Hiring is the easy part. Rampant scaling of engineers is easy to do, if you're not paying careful attention to quality, or you're dumping cash and or options/RSUs with the promise of riches (case in point: Uber sounds like they overhired and then imploded). How successful was your hiring? What was the performance ratings of the people that you hired and how many met your expectations and how many didn't? What was the average tenure of those employees after this big hiring spurt? Those are the more interesting pieces of information.
- zacsky 9y ago
  Quality (for engineering skill AND attitude) was the top focus, salaries were market rate, and there are no options/RSUs involved. Thanks for the suggestions about the follow up to hiring and measuring success. It seems most of the comments want to know more about this so I will look at a follow-up post.
  - walshemj 9y ago
    Why no stock options did you increase the salary to account for this difference?
- usgroup 9y ago
  +1. I think rapid scale means you can't take advantage of many of the useful things about organic growth. I.e. assimilating gradually, not sabotaging the chemistry of the existing team, etc. It also means reliant on cross-cutting resources: "architects", "product managers", etc. More than anything, it also means a lot of firing and attrition. If you need 100 to stay > 3 years then hire 200 and expect to lose or fire half within a year. It may sounds ridiculous but it's the cost of scaling.
pbreit 9y ago
I can't think of (m)any situations where tripling the size of a dev team in 6 months makes sense. Did it here?
- ben_jones 9y ago
  I imagine many large projects start out as small experimental ones. Once they get validated you light a fire under them (with money) and expand the team. IIRC Docker started out as a 2 man team - I'd imagine they had a doubling or a tripling that was well justified after that.
- trhway 9y ago
  some companies seems to do it before IPO/acquisition. Of course sustaining such an inflated company post-event is another story. In the title story : >In 2016 we were acquired through a private investment consortium and given an injection of funding in order to 'go faster'. I'd not be surprised if the consortium would sell them for a nice profit soon. Would look like a typical private equity operation.
  - codingdave 9y ago
    ... on a 20 year old product. This was not a market-driven need, this was an investor-driven push for profit. It is their company, so their call to make, but it needs to be made clear that this was a calculated risk by the business owners to make money, not a launch strategy for a new product.
- jamesmishra 9y ago
  If you have absolutely runaway traction in a winner-take-all market, then tripling the size of your dev team in 6 months can make a lot of sense. Facebook, Google, and Uber have all had periods of growth that fast. For example, Uber's overall employee headcount went from ~2500 at the start of 2015 to ~13,000 at the end of 2016 -- although that includes non-engineering hires. But for companies that aren't Facebook/Google/Uber? A slower growth rate is almost always the better decision.
- zacsky 9y ago
scarface74 9y ago
If he was this successful at hiring, onboarding, and training new devs and getting them up to speed, I must really suck. It took me close to two months and around 14 interviews just to hire four people as contractors - for the right person, I had the budget to give them a top of the market rate. I didn't need the 10x developer just smart .Net developers. You would be surprised at the number of developers with 10 years of experience who couldn't do what was the equivalent of the FizzBuzz problem. (http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest) 60-70% of the people I interviewed had never done automated testing - I've been teaching them how.
- flukus 9y ago
  > 60-70% of the people I interviewed had never done automated testing - I've been teaching them how. That might be a good thing, many think they know and end up with the most obscure, complicated tests imaginable. Massive unit tests, integration tests that don't integrate components, single tests with 50+ asserts, tests with no asserts, tests with no indication what they are testing, I've seen them all.
- simonswords82 9y ago
  Ah don't put yourself down. Hiring is super hard and you're supposed to hire slow, fire fast, so perhaps you just did it the right way given your circumstances. A whole host of factors come in to play too. Timing - was the market just not that full of good devs at the time? Location - you might not have lots of good .Net devs nearby. There's also a healthy amount of luck involved. We hire .Net divs, and our theory test includes a FizzBuzz and we've seen some interesting results...
- djb_hackernews 9y ago
  > I had the budget to give them a top of the market rate. I didn't need the 10x developer just smart .Net developers. As "just a smart developer" how I read this line: "I don't need a Ferrari, a Porsche would do, and I'm willing to pay Honda Accord prices for one"
  - scarface74 9y ago
auserperson 9y ago
1st interview - culture fit. Is it a white male geek?
j_s 9y ago
Does tripling mean going from 1 to 3 or from 100 to 300? I even skimmed the article quickly but didn't see any reference to the scale here.
- phonon 9y ago
  "40-50 over a few months"

71 points by zacsky 9y ago

In 2016, after being acquired by private investors, we were given the green light to triple our engineering team as fast as possible. In this article (part 3 of a 5 part series) I focus on all the preparations required before starting to hire.

faitswulff 9y ago
I skipped ahead to the 5th installment - how do you know if a hire was successful past the first month of employment?
- zacsky 9y ago
  A lot of the things I recommend doing in the first month are just repeatable for the length of their employment. But there is a greater question I think you are asking around how do you know when you made a good hire? That's a big curly question probably worthy of a follow-up post.

mooreds 9y ago

I enjoyed all 5 parts of this in depth series. Would be nice to have a 6th post about how the engineering team ended up being organized, but all in all a great overview of the goals, techniques and tactics needed to make a big hiring push.

zacsky 9y ago
Thanks for your comment. Glad you enjoyed the series. I did consider a 6th article looking at the longer term outcomes but decided at the time to cut it. Might have to reconsider as there seems to be good interest.
- davidbanham 9y ago
  That's the bit I was interested in reading. The level of detail in the hiring process turned out to be really good. The thing that got my attention about the series, though, was "Ooh, I wonder how they handled communication and work distribution among the organisation."

pfarnsworth 9y ago

Hiring is the easy part. Rampant scaling of engineers is easy to do, if you're not paying careful attention to quality, or you're dumping cash and or options/RSUs with the promise of riches (case in point: Uber sounds like they overhired and then imploded). How successful was your hiring? What was the performance ratings of the people that you hired and how many met your expectations and how many didn't? What was the average tenure of those employees after this big hiring spurt? Those are the more interesting pieces of information.

zacsky 9y ago
Quality (for engineering skill AND attitude) was the top focus, salaries were market rate, and there are no options/RSUs involved. Thanks for the suggestions about the follow up to hiring and measuring success. It seems most of the comments want to know more about this so I will look at a follow-up post.
- walshemj 9y ago
  Why no stock options did you increase the salary to account for this difference?
usgroup 9y ago
+1. I think rapid scale means you can't take advantage of many of the useful things about organic growth. I.e. assimilating gradually, not sabotaging the chemistry of the existing team, etc. It also means reliant on cross-cutting resources: "architects", "product managers", etc. More than anything, it also means a lot of firing and attrition. If you need 100 to stay > 3 years then hire 200 and expect to lose or fire half within a year. It may sounds ridiculous but it's the cost of scaling.

pbreit 9y ago

I can't think of (m)any situations where tripling the size of a dev team in 6 months makes sense. Did it here?

ben_jones 9y ago
I imagine many large projects start out as small experimental ones. Once they get validated you light a fire under them (with money) and expand the team. IIRC Docker started out as a 2 man team - I'd imagine they had a doubling or a tripling that was well justified after that.
trhway 9y ago
some companies seems to do it before IPO/acquisition. Of course sustaining such an inflated company post-event is another story. In the title story : >In 2016 we were acquired through a private investment consortium and given an injection of funding in order to 'go faster'. I'd not be surprised if the consortium would sell them for a nice profit soon. Would look like a typical private equity operation.
- codingdave 9y ago
  ... on a 20 year old product. This was not a market-driven need, this was an investor-driven push for profit. It is their company, so their call to make, but it needs to be made clear that this was a calculated risk by the business owners to make money, not a launch strategy for a new product.
jamesmishra 9y ago
If you have absolutely runaway traction in a winner-take-all market, then tripling the size of your dev team in 6 months can make a lot of sense. Facebook, Google, and Uber have all had periods of growth that fast. For example, Uber's overall employee headcount went from ~2500 at the start of 2015 to ~13,000 at the end of 2016 -- although that includes non-engineering hires. But for companies that aren't Facebook/Google/Uber? A slower growth rate is almost always the better decision.
zacsky 9y ago

scarface74 9y ago

If he was this successful at hiring, onboarding, and training new devs and getting them up to speed, I must really suck. It took me close to two months and around 14 interviews just to hire four people as contractors - for the right person, I had the budget to give them a top of the market rate. I didn't need the 10x developer just smart .Net developers. You would be surprised at the number of developers with 10 years of experience who couldn't do what was the equivalent of the FizzBuzz problem. (http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest) 60-70% of the people I interviewed had never done automated testing - I've been teaching them how.

flukus 9y ago
> 60-70% of the people I interviewed had never done automated testing - I've been teaching them how. That might be a good thing, many think they know and end up with the most obscure, complicated tests imaginable. Massive unit tests, integration tests that don't integrate components, single tests with 50+ asserts, tests with no asserts, tests with no indication what they are testing, I've seen them all.
simonswords82 9y ago
Ah don't put yourself down. Hiring is super hard and you're supposed to hire slow, fire fast, so perhaps you just did it the right way given your circumstances. A whole host of factors come in to play too. Timing - was the market just not that full of good devs at the time? Location - you might not have lots of good .Net devs nearby. There's also a healthy amount of luck involved. We hire .Net divs, and our theory test includes a FizzBuzz and we've seen some interesting results...
djb_hackernews 9y ago
> I had the budget to give them a top of the market rate. I didn't need the 10x developer just smart .Net developers. As "just a smart developer" how I read this line: "I don't need a Ferrari, a Porsche would do, and I'm willing to pay Honda Accord prices for one"
- scarface74 9y ago

auserperson 9y ago

1st interview - culture fit. Is it a white male geek?

j_s 9y ago

Does tripling mean going from 1 to 3 or from 100 to 300? I even skimmed the article quickly but didn't see any reference to the scale here.

phonon 9y ago
"40-50 over a few months"