Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
What structure of a team should one keep in mind when making a team at the starting of the project ? Like what should be the ratio of Senior Software Engg. to Software Engg. or how many freshers should be attached to the team etc. and many other points.
Please share any point that has an importance when deciding the structure of a team.
Who you have is much more important than their seniority level. Select the right people for the job based on their skills and ability to work together, not on some set of buckets labeled ‘senior’ and ‘junior’. Make sure you understand what it is you are trying to build, how design improvements/alterations will be ratified by the group, and how disagreements will be unwound and resolved.
You need a boss, usually, unless people are okay with being very open about decisions. The boss’s job is also to act as a conduit to the rest of the organization. Go read all of Rands In Repose.
Start the team as small as possible. Lots of great software, and many great sites, are the result of a 1-3 person team who really work well together, understand their market, and understand the architecture. (“Never doubt that a small group of thoughtful, committed people can change the world. Indeed, it is the only thing that ever has.” — Margaret Mead) Be loathe to add more people. Beware the n^2 law of communication: for n people, there are O(n^2) channels of communication and relations to manage. While group meetings help this a bit, there is always a need for 1-1s.
And beware the Mythical Man Month and Brook’s Law: adding more people won’t accelerate a project go as much as you think it will, and can in fact slow things down. The cost of overhead rapidly overtakes the cost of development. Definitely read that book before doing this sort of planning!
Gender has complex interactions, but again, it is more important to look at the specific people in place rather than seeing them as simply an example of their gender. The Liskov Substitution Principle does NOT apply to humans.
Good luck!