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

The bigger the group is, the lesser is the personal responsibility; it becomes more difficult to assess the contribution of each team member. Feeling that their job is less likely to be rewarded employees feel less engaged and are more exposed to tempting ideas such as, “Eventually someone will have to do this job. Let it not be me!”

• Too much communication

Yeah, we all know those teams who spend more time conferencing than actually working. The major problem with large groups is not in the number of its members but in the connections they have to maintain, simply to prevent the process from becoming a disaster. The strength of the chain is in the weakest link. And when there are too many links it is only a matter of time before one of them fails, causing holdbacks and fierce arguments.

• Stress

A lot of distraction, accompanied by the feeling that the job is meaningless, is a highly combustible mixture. This volatile situation is bound to burn out your employees before they even get their first paycheck. Unhappy workers are not the best performers.

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

This team structure is rather popular among startups and small businesses that can afford only one team for a project. It usually includes all areas of expertise from engineers to designers and testers. This approach allows you to keep communication easy and avoid many issues associated with bigger teams. This structure also gives you more room to experiment with approaches. Agile, Lean Scrum, Waterfall, and Feature-driven development – all work well with small teams. As well, it becomes easier to shift between them when needed.

• Goal-Driven Squads

For bigger companies it's almost impossible to keep all processes up and running within one large team.  In that case, companies prefer to divide their team into smaller goal-focused squads, commonly called chapters. Each chapter includes all the specialists in a certain area (e.g. designers) while these specialists may be assigned to separate projects.

Here's a quick comparison of these two set-ups:

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
  
  

Of course, this list may vary depending on your needs and project specifics.

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

A psychological conformity of your team members is as important as their expertise. Pay attention to how your workers treat each other. Solve conflicts as soon as possible, encourage cooperation and do your best to inspire your staff to outperforming themselves.

•  Ever-changing circumstances

Every business poses its own requirements on the development process. For example, the situation may require you to shuffle your teams or change the management approach. Don't be afraid to implement such changes.

•  Individual goals and interests

Try to assign employees to the projects that match their interests. You'll be surprised at how productive, engaged, and proactive people may be.




About the Author:

Intersog.com delivers high-performance software engineering and agile team staffing solutions that help businesses be more successful tomorrow.