Team Size: Small, Medium, Large? Any Benefit for these sizes?

[Hunter]

Quick question. Has anyone determined if larger teams are slower, or smaller teams faster, etc...? I've got effectiveness up to 390% on most teams, some of these teams are 10, 12, 15, 20 people strong... and they, for some reason, appear to be slower than teams that are smaller. The teams all have 170%+ compatability as well.

I'm thinking it might have something to do with me assigning multiple teams to a single project. For example, I have a Design A and Design B team, all of which are designers with specialties in various things: 2D, 3D, Network, Audio, System, etc... So I figured if I wanted to double the work getting done on a project/design task, I'd assign both Teams A & B... sometimes it seems like that slows it down.

Can anyone confirm if it does? I don't think its a game problem as much as me not realizing or understanding how to utilize my teams with the best effect.

Thanks!

[kotae]

This is a fairly complicated one (looking from the outside in). The base time a project takes is determined by the features chosen. This base time is then manipulated largely by team size (and further by employee role / skill - but that's another discussion).

There's far too many variables at play to post the full formula, but basically you want to keep the # of employees working on a project closest to the project's recommended team size. You can see the recommended team size in the Design Document's Details pane.

On the note of assigning multiple teams to one project: I think this does increase overall completion time, but only slightly, and (imo) fairly:

effectiveness *= SoftwareType.GetEmployeeCountEffect(Mathf.Max(1, this.Working.Count) + (this.DevTeams.Count - 1) * 2, this.DevTime, true);

The first parameter to the GetEmployeeCountEffect function is NumEmployees, so you're increasing this value by 1 for each team assigned (not a big increase).

Note that Working.Count is updated to include the employees from other assigned teams. So having multiple teams assigned will always result in (very) slightly lower project effectiveness than having one team with the recommended team size.

[Hunter]

Excellent, thanks for the help! Looks like smaller teams are the way to go for me then, or rather, teams of the "correct" or "recommended" size. Excellent.

[NeedHydra]

i do 12+lead for most things, 24+lead for the big stuff like OS or processor for the hardware mod and 10+lead for games and now im worse then ea buying anyone who can hold a candle to me by 1990

[Awesomely Oscillating Ocelot]

I tend to have teams of 4, 5, 6, and 8 (without counting leads). Mostly on the assumption that this would enable meeting recommended numbers easily.

But if multi-teaming is detrimental I might have to change that approach. I cannot maths at all (I LITERALLY CAN'T EVEN) but I'll take testing's word for it!

Looks like changing teams based on specific project needs might really need to be a thing but I honestly can't see how to design flexible offices for that so I probably won't at this time and I'll just have to accept inefficiency.

[kotae]

i made a mistake interpreting the logic. each team assigned beyond the first one holds the same value as one employee.
so let's say a product's recommended team size is 8. you assign team 1 and team 2 to the product. team 1 has 4 members and team 2 has 4 members. the overall value would then be 9 (4 + 4 + 1). to expand, (team1Size + team2Size) + (numTeams - 1).
the * 2 in the code snippet above is likely just padding.

so this doesn't have a dramatic effect on effectiveness, and makes more sense. having multiple teams working on a single project probably reduces effectiveness in real life as well, since you'd have to coordinate with each team.
you can look at this formula as adding an invisible employee to each team that goes to the other teams and does the coordination :)

tl;dr i made a mistake. don't rethink your strategies. multiple teams are not detrimental to effectiveness.

[Awesomely Oscillating Ocelot]

Ah, that's interesting.

I hadn't observed a huge detrimental effect but was assuming this was likely because I was ensuring that no more than two teams were ever combined.

Glad I don't have to rethink my office designs, though!

[Tenzek]

I just started playing this game a couple of days ago, and I have a few questions about the details of how you can be efficient in a project.

Suppose a project requires 12 people. Is it efficient to have a design team of 12 designers and then switch to a development team of 12 total programmers and artists?

1) Does the game penalize you for switching teams for different parts of production?

2) Does the team size number assume a ratio of jobs already? Does, for example, a project that recommends 12 members limit you to 4 or 5 designers, or will it let 12 people of any job work at max efficiency at one time?

3) How does a team lead affect this?

4) I saw a guide that said it's easiest to limit a room to 6 people to easily cover their needs. Is it always harmful to split a large team over several rooms? Can you make up for the separation by giving them a central meeting room for team meetings, for example?

[y35]

Originally posted by testing:

This is a fairly complicated one (looking from the outside in). The base time a project takes is determined by the features chosen. This base time is then manipulated largely by team size (and further by employee role / skill - but that's another discussion).

There's far too many variables at play to post the full formula, but basically you want to keep the # of employees working on a project closest to the project's recommended team size. You can see the recommended team size in the Design Document's Details pane.

On the note of assigning multiple teams to one project: I think this does increase overall completion time, but only slightly, and (imo) fairly:

effectiveness *= SoftwareType.GetEmployeeCountEffect(Mathf.Max(1, this.Working.Count) + (this.DevTeams.Count - 1) * 2, this.DevTime, true);

The first parameter to the GetEmployeeCountEffect function is NumEmployees, so you're increasing this value by 1 for each team assigned (not a big increase).

Note that Working.Count is updated to include the employees from other assigned teams. So having multiple teams assigned will always result in (very) slightly lower project effectiveness than having one team with the recommended team size.

Are you telling me that having 300 people in one team isn't very effective?
wot

[Hunter]

My biggest issue i believe was having say 18 team members for a project that recommended 12, thinking the extra team members would speed things up, but they really aren't.

[kotae]

Originally posted by Tenzek:

I just started playing this game a couple of days ago, and I have a few questions about the details of how you can be efficient in a project.

Suppose a project requires 12 people. Is it efficient to have a design team of 12 designers and then switch to a development team of 12 total programmers and artists?

1) Does the game penalize you for switching teams for different parts of production?

2) Does the team size number assume a ratio of jobs already? Does, for example, a project that recommends 12 members limit you to 4 or 5 designers, or will it let 12 people of any job work at max efficiency at one time?

3) How does a team lead affect this?

4) I saw a guide that said it's easiest to limit a room to 6 people to easily cover their needs. Is it always harmful to split a large team over several rooms? Can you make up for the separation by giving them a central meeting room for team meetings, for example?

1. no
2. it does not, but the pie chart breaks down what skills will be needed (2d, audio, etc)
3. can't find everything that the Leader effects, but it seems to be that Leader contributes as all roles (designer, programmer, artist) in all phases (design, alpha, beta) at ~25% effectiveness.

from my understanding it would technically be fastest to have 12 designers during the design phase and 12 total programmers / artists during the alpha and beta phase. however, this would require keeping a close eye on each project to make sure you're switching teams as soon as it reaches the next phase. when you get to late-game you will likely have several projects going at once. so that's something you should weigh in. personally, after my first big hit i'll start switching everything but OS development to project management so i don't have to worry about teams, phases, etc. each software type gets its own tailored, dedicated team with project management. this turns the game into an idler though, so might not be very fun unless you're like me and love idlers :p

[trevorhater2004]

if ur team isnt at least 250% compatible, then u have got an issue. also dont assign to many people on one project.