Iyfjky

Question

A management question was asked to me in a largely technical interview. If you lead a team size of 5 and we need to grow to 40 in 6 months, how would you go about it?

I replied that I would map the required roles for the team and hire externally/internally, taking each interview myself.

Was there anything else I could have added here, as I felt this answer was a bit weak.

Could we get some more details about what the specific problem is? This is a bit hard to answer at the moment as it's very broad. Are you concerned about how to interview potential new hires for how well they'll fit into the team or what? — Aug 2 '12 at 11:44
My first question would be is this a real challenge of the position or just a hypothetical... if they say real challenge I walk away. Bringing in someone new and tasking them to build a team like this is setting them up for failure. — Aug 2 '12 at 12:58
@Rarity: I was the interviewee in this case - and I didnt know what is expected to "build the team" — Aug 2 '12 at 13:02
@Chad: Thanks for your tip - the question was hypothetical for the role I'm offered. But it is possible this was an assessment of future management capabilities - which I probably don't fit. — Aug 3 '12 at 5:27
I think your answer "taking each interview yourself" would put you on the fast track to no offer. Managers need to know how to manage, not all the low level technical details on what it takes to be able to do a job. You should have said "I'd assign respective experts for the positions we are hiring and delegate hiring recommendations to them". That shows that you can delegate and recognize that you can't be an expert at everything. — Aug 7 '12 at 15:06

score 35 · Accepted Answer · 2012-08-26 10:45:29Z

Actually, one could write a book on the subject. And the book would start with "well, that's not a very good idea, you know."

One thing you can assume is that growing the 8 times in 6 months ends with a team that is so different that you could discuss building 40-person team from scratch either way.

Besides of this, here are a few possible caveats that you might focus on dealing with such challenge:

With 40 people it is very, very difficult to run a team with no hierarchy whatsoever. Google made an attempt to have 50+ direct reports per manager although I'm not sure whether this model has proven to be sustainable. Anyway, most obvious case is to spread 40 people among a few teams. Which means that...

You need leaders. A few of them. The idea how to get them is likely the biggest challenge of the whole puzzle. It is unlikely that 5 original team members would make good candidates for leaders. Heck, odds are that none of them would. So the question is how to hire the leaders? Internally from the company you work for, on the job market, drawing attention to the company, head hunting, or what have you. There are plenty of options here, although neither of them is a sure shot. Actually...

None of your hiring decisions would be a sure shot. Building the team so rapidly means that there's no time for them to adopt current organizational culture. If you make bad hires it will strongly affect how the team works. The original team lineup will be watered down -- don't count on them to sustain the culture. Result of paying so much attention to quality of hires means that...

Your recruitment process is another tricky thing. I would consider getting the whole team involved in hiring process a must -- after all you want to sustain the culture and who are you to assume that you know it all? On the other hand such rapid recruitment is a challenge by itself considering you don't want just a random bunch of blokes working for you half a year later. It likely means that the team will be paying as much attention as possible to recruitment process, which also means that team's productivity will nosedive. It shouldn't be that much of a problem since...

Building a new team from scratch means that they need time before they get to full speed. Tuckman's model of group development points that every group needs time before they start performing. It obviously applies to described case although some argue (like Mark Levinson in this podcast) that it happens when any new member joins the team. This means that you likely want to pay much attention to how the teams organize themselves and how much it is aligned with the goals of the whole 40-people group.

Having that all in mind 6 months to do the task is crazy little time, so I'd start with discussing what are the reasons for such a radical change. Of course it might be beyond discussion which would be fair enough for me. The question is still worth asking though.

Enough good stuff here that it's better to just add a comment. At 6 people teams are still somewhat generalized. At 40 it can become more useful to have some specialists too. This changes how you recruit and manage because you want to find and lead people much better than you in certain niches. — Aug 2 '12 at 11:31
@MathAttack - Actually it depends how you build teams. With 40 people you still can have 7 teams that operate similarly to the original one, e.g. you have more generalists than specialist. For me this part is very context-dependent. — Aug 2 '12 at 12:09
@MathAttack multiple specialists are a big hint that your team should be split into departments/grounds/something. You shouldn't have 5 design specialists in your software development team, you should have a 5 person design team. — Aug 2 '12 at 13:11

Communityâ™¦ 1 · Answer 2 · 2017-04-13 12:48:42Z

Pawel's answer is excellent, but I think it important to emphasise one thing:

You don't build a successful team, you grow it.

That's probably why your interviewer phrased the question in that way.

You can't just pick a bunch of technically excellent people, stick them in the same group and expect excellent things to happen, especially not a group as large as 40, created in such a short period of time.

Tom DeMarco and Timothy Lister said it best in their excellent Peopleware: Productive Projects and Teams. For example:

The major problems of our work are not so much technological as sociological in nature

Teams by their very nature are formed around goals.

The purpose of a team is not goal attainment but goal alignment.

The manager's function is not to make people work, it is to make it possible for people to work.

If you haven't read Peopleware, I would highly recommend it. In my opinion it is an essential read for people who manage any kind of knowledge worker.

Similarly, if you will be managing software engineers, I would suggest that Fred Brooks' excellent The Mythical Man-Month: Essays on Software Engineering should be considered essential reading for any software engineer, or those managing software engineers. It's 20th anniversary edition was published in 1995, yet it's still as relevant today as it was in 1975!

+1 Great book references! Although Brooks' Mythical Man-Month is a bit outdated when it comes to the ideas how to organize big teams. — Aug 2 '12 at 14:15
@PawelBrodzinski - No...No its no. The basic concepts that were true in 1975 building the very first unix release applies to the current release of Windows, OS X, and HP Unix. — Aug 2 '12 at 15:55
@PawelBrodzinski - It may read as outdated, but far too many organisation are still making the same mistakes that organisations were making in the 60's. I make a point of re-reading it every decade to remind myself how far we still have to go in the field of software engineering management. — Aug 6 '12 at 11:01
@Mark - True. At the same time I don't really see Chief Architect concept as defined by Brooks implemented these days. The landscape of building software has changed. So should the ideas how software development teams look like. — Aug 6 '12 at 12:03

pap 5,2561524 · Answer 3 · 2012-08-07 11:17:35Z

One of the primary challenges in this scenario is the sheer amount of people you need to hire. 35 ppl in 6 months, that's more than one person a week. Ask a recruiter (who does this full time) at any company and they'll say they'd be extremely happy if they could accomplish half of that.

So, unless you're willing to hire just anyone off the street (and spend the next 12-18 months training and getting them working as a functional team), you need to address this. The first 3-5 people you hire needs to be very senior with large networks and management capabilities. They should come on board with the understanding that they are expected to build up their own teams with people they know and can attract. They should also be given large freedoms in doing so.

These first hires are going to cost top dollars, but that's the price you pay to grow at that rate and still have a chance at maintaining positive output.

HLGEM 133k25227489 · Answer 4 · 2012-08-02 15:24:27Z

Excellent answers so far, but I have been involved in this type of growth before and one thing that really needs to happen before you start hiring is setting up the processes you will use.

Small teams tend to be far less formal about their processes but it iis harder to be informal as you get larger as you end up with 12 differnt ways of doing the same thing and people get confused about what should be where or what the overall architecture is.

More people doing things more ways and with less communciation than a small team has makes the product less maintainable if you don't formalize some processes and designs and source control structures, etc, first. Having a process in place that the orginal team designs and documents makes it easier to train the new people as you hire them and makes it easier to keep your product maintainable.

So if you don't have it, you might want to set up a continuous build process and you might want to think about how you are going to organize your source control and how often you expect people to commit and how you are going to deploy to prod and who should have rights on prod (typically in a small team, everyone may have those rights and in a larger team, you may change that to managers or key seniors only). You might want to decide how and when to do code review and if you need to start having a formal QA team and a whole host of issues as you get larger. Thinking about these issues and setting up processes before you start getting a lot of new people can really help.

This question is about how do you answer the interview question not how do you actually grow it. — Aug 2 '12 at 16:40
And describing that you need to do these things is part of what the answer in the interview question should be. — Aug 2 '12 at 19:01

mhoran_psprep 40.3k463144 · Answer 5 · 2012-08-05 19:23:55Z

The first question that needs to be asked is: why is there a need to grow the team?

If they just won a contract:

The first step is to review the award, and start mapping out how you will fill those technical, non-technical, and leadership roles.

You will need to know if the positions will be filled from inside the company, new hires, or from the previous contractor. I have worked with organizations where the the approach to filling the position varied by award. They might have bid on the contract because they had too many people on overhead and wanted to get them onto contracts that were billable. Some needed to grow the number of employees because they needed to generate enough G&A to pay for their central office. In other cases they needed to grab some key skills from the previous company in order to gain experience.

Bringing on employees from the current contractor can be a good or a bad thing. Only the employees they don't want might be willing to switch, or employees that are too expensive.

If they don't have a new contract:
- Then it is a marketing/business development question. You need to know what area they can comfortably bid based on their current skill set, and the skill sets they are interested in growing.
- As you bid these contracts you will have to start identify some potential employees before submitting the bids, that way you know how you fill key positions if you win. This is very important if you don't have current employees with those skills, sometimes you need to provide resumes of current employees or potential employees with the bid.

No matter why they need to grow you should also discuss how you will form a team, and the types of people you would be looking for.

user8365 · Answer 6 · 2012-08-26 13:47:00Z

Why do they need to grow so fast? You didn't ask this question. Most of the answers operate under the assumption that they expect to add 35 individuals and have everything work smoothly. What if the answer to the question is, "We want to have a large staff to attract investors."? I heard a story where programmers used two and three computers because the company used Number of Desktop Installations to indicate the size of the company. You can't make this stuff up.

Things to address/mention if they are still convinced they want to do it:

Leader or "Yes Man" - They want to see how you push-back on management requests. Can you confidently show them the error of their ways without offending them? Offer valid alternatives.

Existing Staff Retention - Make sure your existing staff is going to be comfortable working with a larger team. You may have people who chose this company because of the small size.

Nobody's Perfect - be prepared to hire more than 35 new people. It could get closer to 40 with loses and those that aren't going to cut it. Yes, you have hired and will continue to hire people that don't fit, but show you can identify poor choices early and make corrections.

Referrals - Everyone you hire needs to bring in two other people. It works for multi-level marketing. Wouldn't it be great if you could hire 5 people, who bring in 10 people, who bring in 20? Boom - 35 more people. Now, back to reality.

Better Jobs - Will the company be able to offer: flex-time, remote workers, competitive salaries, meaningful work, and all that other fun stuff you'll learn from existing and future candidates?

"Poaching" - there's only so much talent to go around and many qualified candidates will already have a job. This company is going to develop a reputation of going after other people's employees; they may not want that stigma.

Feeder System - Having a relationship with local universities with CS programs can help in the short-term if you can develop an internship program and some part-time positions. A 6 month time-frame makes it difficult to only go after graduates.

Cash - This is not a bootstrap situation. This demand can be met, but the costs need to be realistic. You want a lot of resources in a short amount of time means you'll spend a lot of money. Much of the money will be wasted. You may be hiring temp staff to go through all the resumes, schedule interviews and manage the line of candidates going out the door. You're company is going to look like the hottest day-time geek club on the planet.

Current Projects on Hold - The current programmers may be spending all of their time building a website to manage hiring. The rest of their time is going to involve interviewing and evaluating new candidates.

We look at this hypothetical task and immediately identify how obsurd and impractical it is, but we should always focus more on what the customer's definition of "working" is. Look past that. Maybe money is no object.

David M 716410 · Answer 7 · 2012-09-03 09:41:15Z

I think that there is one aspect of this question as an interview question that hasn't been tackled yet. You are describing this as cropping up in a technical interview, prefaced with something like "if you lead a team of 5 people". So I assume you are being interviewed for a relatively senior development position with the possibility to grow into a team leader role.

If you are a team leader of 5 people, and the company wants to grow this to 40 developers, then just as the 5 people may not be the natural team lead you may not be the natural manager of 40. And if I'm looking to hire you as a senior developer, I don't necessarily want to hear you assuming you'd be the right person to manage 40. If you have immediate aspirations to be working at that level, why would I want you in a developer role - you'd have itchy feet before you'd even settled in.

If you were the team lead, though (as predicated in the question), then I'd expect you to be a very important part of the process that selects that ultimate manager (which may or may not be you). I'd want you to discuss this in the context of the different attributes you think would be required of the two roles (lead of 5, manager of 40), and how you would go about recruiting someone (again, possibly you, possibly not) into that role while keeping the right culture for the company and the existing staff.

score 35 · Accepted Answer · 2012-08-26 10:45:29Z

Actually, one could write a book on the subject. And the book would start with "well, that's not a very good idea, you know."

One thing you can assume is that growing the 8 times in 6 months ends with a team that is so different that you could discuss building 40-person team from scratch either way.

Besides of this, here are a few possible caveats that you might focus on dealing with such challenge:

With 40 people it is very, very difficult to run a team with no hierarchy whatsoever. Google made an attempt to have 50+ direct reports per manager although I'm not sure whether this model has proven to be sustainable. Anyway, most obvious case is to spread 40 people among a few teams. Which means that...

You need leaders. A few of them. The idea how to get them is likely the biggest challenge of the whole puzzle. It is unlikely that 5 original team members would make good candidates for leaders. Heck, odds are that none of them would. So the question is how to hire the leaders? Internally from the company you work for, on the job market, drawing attention to the company, head hunting, or what have you. There are plenty of options here, although neither of them is a sure shot. Actually...

None of your hiring decisions would be a sure shot. Building the team so rapidly means that there's no time for them to adopt current organizational culture. If you make bad hires it will strongly affect how the team works. The original team lineup will be watered down -- don't count on them to sustain the culture. Result of paying so much attention to quality of hires means that...

Your recruitment process is another tricky thing. I would consider getting the whole team involved in hiring process a must -- after all you want to sustain the culture and who are you to assume that you know it all? On the other hand such rapid recruitment is a challenge by itself considering you don't want just a random bunch of blokes working for you half a year later. It likely means that the team will be paying as much attention as possible to recruitment process, which also means that team's productivity will nosedive. It shouldn't be that much of a problem since...

Building a new team from scratch means that they need time before they get to full speed. Tuckman's model of group development points that every group needs time before they start performing. It obviously applies to described case although some argue (like Mark Levinson in this podcast) that it happens when any new member joins the team. This means that you likely want to pay much attention to how the teams organize themselves and how much it is aligned with the goals of the whole 40-people group.

Having that all in mind 6 months to do the task is crazy little time, so I'd start with discussing what are the reasons for such a radical change. Of course it might be beyond discussion which would be fair enough for me. The question is still worth asking though.

Enough good stuff here that it's better to just add a comment. At 6 people teams are still somewhat generalized. At 40 it can become more useful to have some specialists too. This changes how you recruit and manage because you want to find and lead people much better than you in certain niches. — Aug 2 '12 at 11:31
@MathAttack - Actually it depends how you build teams. With 40 people you still can have 7 teams that operate similarly to the original one, e.g. you have more generalists than specialist. For me this part is very context-dependent. — Aug 2 '12 at 12:09
@MathAttack multiple specialists are a big hint that your team should be split into departments/grounds/something. You shouldn't have 5 design specialists in your software development team, you should have a 5 person design team. — Aug 2 '12 at 13:11

Communityâ™¦ 1 · Answer 9 · 2017-04-13 12:48:42Z

Pawel's answer is excellent, but I think it important to emphasise one thing:

You don't build a successful team, you grow it.

That's probably why your interviewer phrased the question in that way.

You can't just pick a bunch of technically excellent people, stick them in the same group and expect excellent things to happen, especially not a group as large as 40, created in such a short period of time.

Tom DeMarco and Timothy Lister said it best in their excellent Peopleware: Productive Projects and Teams. For example:

The major problems of our work are not so much technological as sociological in nature

Teams by their very nature are formed around goals.

The purpose of a team is not goal attainment but goal alignment.

The manager's function is not to make people work, it is to make it possible for people to work.

If you haven't read Peopleware, I would highly recommend it. In my opinion it is an essential read for people who manage any kind of knowledge worker.

Similarly, if you will be managing software engineers, I would suggest that Fred Brooks' excellent The Mythical Man-Month: Essays on Software Engineering should be considered essential reading for any software engineer, or those managing software engineers. It's 20th anniversary edition was published in 1995, yet it's still as relevant today as it was in 1975!

+1 Great book references! Although Brooks' Mythical Man-Month is a bit outdated when it comes to the ideas how to organize big teams. — Aug 2 '12 at 14:15
@PawelBrodzinski - No...No its no. The basic concepts that were true in 1975 building the very first unix release applies to the current release of Windows, OS X, and HP Unix. — Aug 2 '12 at 15:55
@PawelBrodzinski - It may read as outdated, but far too many organisation are still making the same mistakes that organisations were making in the 60's. I make a point of re-reading it every decade to remind myself how far we still have to go in the field of software engineering management. — Aug 6 '12 at 11:01
@Mark - True. At the same time I don't really see Chief Architect concept as defined by Brooks implemented these days. The landscape of building software has changed. So should the ideas how software development teams look like. — Aug 6 '12 at 12:03

pap 5,2561524 · Answer 10 · 2012-08-07 11:17:35Z

One of the primary challenges in this scenario is the sheer amount of people you need to hire. 35 ppl in 6 months, that's more than one person a week. Ask a recruiter (who does this full time) at any company and they'll say they'd be extremely happy if they could accomplish half of that.

So, unless you're willing to hire just anyone off the street (and spend the next 12-18 months training and getting them working as a functional team), you need to address this. The first 3-5 people you hire needs to be very senior with large networks and management capabilities. They should come on board with the understanding that they are expected to build up their own teams with people they know and can attract. They should also be given large freedoms in doing so.

These first hires are going to cost top dollars, but that's the price you pay to grow at that rate and still have a chance at maintaining positive output.

HLGEM 133k25227489 · Answer 11 · 2012-08-02 15:24:27Z

Excellent answers so far, but I have been involved in this type of growth before and one thing that really needs to happen before you start hiring is setting up the processes you will use.

Small teams tend to be far less formal about their processes but it iis harder to be informal as you get larger as you end up with 12 differnt ways of doing the same thing and people get confused about what should be where or what the overall architecture is.

More people doing things more ways and with less communciation than a small team has makes the product less maintainable if you don't formalize some processes and designs and source control structures, etc, first. Having a process in place that the orginal team designs and documents makes it easier to train the new people as you hire them and makes it easier to keep your product maintainable.

So if you don't have it, you might want to set up a continuous build process and you might want to think about how you are going to organize your source control and how often you expect people to commit and how you are going to deploy to prod and who should have rights on prod (typically in a small team, everyone may have those rights and in a larger team, you may change that to managers or key seniors only). You might want to decide how and when to do code review and if you need to start having a formal QA team and a whole host of issues as you get larger. Thinking about these issues and setting up processes before you start getting a lot of new people can really help.

This question is about how do you answer the interview question not how do you actually grow it. — Aug 2 '12 at 16:40
And describing that you need to do these things is part of what the answer in the interview question should be. — Aug 2 '12 at 19:01

mhoran_psprep 40.3k463144 · Answer 12 · 2012-08-05 19:23:55Z

The first question that needs to be asked is: why is there a need to grow the team?

If they just won a contract:

The first step is to review the award, and start mapping out how you will fill those technical, non-technical, and leadership roles.

You will need to know if the positions will be filled from inside the company, new hires, or from the previous contractor. I have worked with organizations where the the approach to filling the position varied by award. They might have bid on the contract because they had too many people on overhead and wanted to get them onto contracts that were billable. Some needed to grow the number of employees because they needed to generate enough G&A to pay for their central office. In other cases they needed to grab some key skills from the previous company in order to gain experience.

Bringing on employees from the current contractor can be a good or a bad thing. Only the employees they don't want might be willing to switch, or employees that are too expensive.

If they don't have a new contract:
- Then it is a marketing/business development question. You need to know what area they can comfortably bid based on their current skill set, and the skill sets they are interested in growing.
- As you bid these contracts you will have to start identify some potential employees before submitting the bids, that way you know how you fill key positions if you win. This is very important if you don't have current employees with those skills, sometimes you need to provide resumes of current employees or potential employees with the bid.

No matter why they need to grow you should also discuss how you will form a team, and the types of people you would be looking for.

user8365 · Answer 13 · 2012-08-26 13:47:00Z