It’s no secret that every business stands on its people. This reliance is based not only on how dedicated and professional they are but also on how effectively they are managed.
Building a software engineering team for a new project may be a frustrating task, especially to those who have no experience in this area.
Being a large software development vendor whose success significantly depends on effective team management, Intersog offers a step-by-step guide on how to structure your IT department so it will deliver paramount results. The guide also answers a few frequently asked questions, such as:
- How big should my team be?
- What specialists do I need for a project?
- How do I assign the roles correctly?
All of the tips are time and experience proven. We hope they'll be helpful for your business and development goals. So... it's reading time!
Step 1: Decide on the size of your crew
Intuitively, it may seem that the rule “the more the better” suits every case perfectly, but the reality is not that straightforward. It is true that two developers will do the job faster than one, but ten developers will never outperform five.
Why? The reasons are as follows:
- Blurring of responsibility
- Too much communication
- Stress
All the factors above, being combined eminently, lead to the well-known Rigelmann effect. It shows the decrease of individual responsibility with the growth of the group. The effect is also called “Social loafing” which we believe describes it the best.
So, to prevent your business from turning into a wicked blend of torture and charity you might consider using the “two-pizza rule” introduced by Jeff Bezos. It says that if you can't feed your team with two pizzas it's too large. Taking into account people's varying appetites it's better to clarify that the optimal team size is 5-7 members.
But what do you do if your team is much, much bigger? This is what step 2 is all about!
Step 2: Split your team into smaller groups
Many technology powerhouses such as Uber, Facebook, or Google run teams of hundreds of people and still manage to make them work like a Swiss clock.
What they do is restructure this crowd into comfortable smaller teams.
That helps a lot, but you still need to consider that increasing the total number of teams also makes it more difficult to coordinate their cooperation. You may need to hire another specialist to streamline the communication. Otherwise, you're at risk of creating a situation where two teams are hammering at the same task.
Step 3: Select the optimal team structure
To reach the ultimate team performance, every team member should understand his duties and scope of work.
Generally, there are two ways to organize your team using methods adopted by most companies.
- One Universal Team
- Goal-Driven Squads
Here's a quick comparison of these two set-ups:
One Universal Team
Goal-Driven Squads
Company type
Startups and small businesses
Large companies
Project type
Small and rather simple projects
Complex projects that demand working on several tasks at the same time
Pros
Easy to manage
Plain structure
Straightforward communication
Each group understands its responsibilities
Ability to accomplish different tasks simultaneously
Cons
Sometimes the barrier between team member responsibilities is rather blurred
Harder to manage
Higher risk of communication issues
Yet, the team will never be independent and effective if you don’t build it and assign roles correctly. Our next tip is just about that!
Step 4: Choose the right specialists for your team
As we've said before, splitting your team into smaller groups may be the right choice... but only when done the right way. Putting 5-6 random people together may be good for team-building but not for building a good team.
Take care to keep your crews balanced. In other words, make sure they include all the experts needed for successful completion of the task.
Most commonly a team includes:
- 1 PM
- 1 UI/UX Designer
- 2-4 Software Developers (depending on your project these may be Front-End/Mobile or Back-End developers)
- 1 Tester
Step 5: Assign the roles
There is a huge difference between being called a “team” and actually being a team. To turn a group of people into a perpetual coding mobile you might think about assigning some special roles.
Here are a few of the most commonly used:
Team Lead
First of all, a Team Lead is not a Project Manager. While a PM usually cares about the overall process running smoothly, the Team Lead ensures that the team is cohesive and all the resources are available. The Team Lead is also not the best coder (he can be but it's not a must). It should be the person who is able to care about the team’s needs – a coach to some extent.
Chief Architect
This role is crucial for large teams with a branched structure. The Architect ensures that everyone has a common understanding of the product's vision and architecture as well as coordinates the communication between teams.
Product Owner
This person ensures that the team builds the right product. He's responsible for planning and prioritizing. In other words, he plays the role of a bridge between the team, stakeholders, and customers.
There are plenty of other roles that can help you bring your team to the next level. Describing all of them will require another article. In most cases, the roles stated above are more than enough.
Sum up: There's always room for step 6, 7 and so on...
An important thing to understand is that when all the teams are loaded, your work doesn't end. To ensure the perfect productivity you always need to stay involved in the process. Here are a few other factors you should pay attention to as a manager:
- Inner climate
- Ever-changing circumstances
- Individual goals and interests
About the Author:
Intersog.com delivers high-performance software engineering and agile team staffing solutions that help businesses be more successful tomorrow.