How to build a great software engineering team

This article was originally published on .cult by Chameera Dulanga. .cult is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries, and share heaps of other untold developer stories from around the world.

Software development is teamwork and having a good team structure is vital for its success. But, even a tiny misalignment could adversely affect our teams’ output. That’s why we should be extra careful when putting a team together.

In this article, I’ll discuss some important factors you need to consider when building a software engineering team for your company.

Why is team structure important?

When you build a software engineering team, look at various things that affect the productivity and effectiveness of the team.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

In modern agile teams, we hardly measure effectiveness by the lines of code produced. Instead, we give more prominence to quality and continuous improvements. And the team should be capable of producing the “desired outcome.”

So we need to address the following questions:

1. Do we have the right skillset in place?

• Technical skills
• Experience
• Soft skills

2. Do we have the right environment for them to collaborate?

• Clear roles and responsibilities
• Communication tools are in place

3. Does the team know their goals?

• Clear communication top down so that the team knows the expectation
• Precise requirements that reduce rework

4. Is the team empowered to produce better quality outcomes?

• Processes in place
• Leadership providing the proper guidance
• Correct pay
• A culture that appreciates and celebrates wins

5. Can the team produce a better outcome than each individual?

• Team synergy
• Continuous improvement
• Self-managing and self-healing teams

We also need to take the budget into account. You should always have an upper limit to find the right balance for an optimum team structure.

But the question is, “How should we decide the perfect team structure?”

Deciding the best team structure

As you can see, there are many factors we need to consider when assembling a team. And some of them you’ll only identify after the team starts performing.

However, finding individuals with a proven track record, especially for the leadership level, is going to help you reduce the risks.

Let’s concentrate on the key factors we have control over when choosing the individuals for a team;

1. The number of team members

2. Experience level of the engineers

3. Cost of running the team (remuneration and other expenses)

1. Number of team members

We usually decide the number of individuals in a team based on the project estimates and delivery milestones. One thing you shouldn’t do is run the project with less developers than required, even if they’re very talented. You’ll run the risk of sacrificing quality and cause more problems in the long run.

However, things get complicated when you need to decide the structure of the team. Since not all individuals play the same role, we have to start thinking about the team’s composition by identifying different roles.

• Who is leading the team and managing the project?
• Do we need to break into sub-teams? (which might mean more leaders…)
• Who is taking ownership of the architecture?
• What are the other roles required, e.g., Quality Assurance, UI/UX, Project Management, Business Analyst?

2. Experience level

The experience level of the engineers directly affects the quality and productivity. But that doesn’t mean we need a team full of highly experienced people. Remember, we talked about team synergy.

We have to think about the different experience levels available in the team. Since people work together, they can learn from each other and produce the desired outcome.

Why experience levels affect quality and productivity

Quality cannot be built over a day or two. It comes with experience.

For example, suppose you’re starting a new Java project and looking for a developer. If you use developers who are new to the technology, they’ll need time to learn — meaning the project will be slower.

Also, they won’t have the necessary experience on best practices, resulting in higher rework effort. So in this case go with a developer who’s skilled with Java. Easy!

However, if you need more than one developer to work on a project you can re-consider different experience levels. You can have the experienced developer(s) guide the team towards the goal without your productivity suffering. It also means, from a hiring perspective, you can consider a wider pool of developers who can join your team.

Having a team full of experienced people becomes challenging

First of all, it affects your budget, more experienced developers are obviously going to demand higher pay!

On top of that, they’ll expect better opportunities like playing leadership roles, and that’s not always going to be available. All this experience can create a bottleneck if the teams’ goals and ambitions aren’t aligned.

Having a balance between junior and senior members is going to be better and also increases developer retention because expectations and growth can be better managed.

3. Cost of running the team

Software engineering teams are significantly different from teams in other professions. They can work from remote locations, have flexible working hours, and sharpen their knowledge with continuous learning.

So, if we can utilize these factors, we can look at optimizing the costs involved.

Experience comes with a cost

As we discussed earlier, finding experienced individuals on a particular technology or domain comes with a cost. And since it’s not a binary decision to have all experienced or none, we can balance the experience levels also considering the cost structure.

Multiple workplaces

This is also another dimension to think about when managing the costs of software development teams.

However, having multiple workplaces can either increase or reduce the cost of your project.

If you have more than one workplace, you’ll have to pay bills, maintenance for each workplace, and without a doubt, it will increase the utility costs.

But, on the bright side, we can look for locations to attract more talent or have tax benefits. Besides, if you can arrange a workplace in a country where the living expenses are low, you can effectively reduce the costs.

Remote workers and outsourcing

So, if you look at the other options available, you can outsource your work either to a remote worker or a company where the costs are low.

However, there are few other challenges you should address when making your distributed team effective.

1. Increase the overlap

If your team is working in different time zones, it’s good to have reasonable overlap whenever possible. This could be achieved by either shifting working hours or having designated time for collaboration.

2. Balancing expertise and dividing the work

Also, it’s necessary to balance the experience of individuals and partition the work, reducing the dependencies across time zones.

3. Streamlined processors

A proper set of processors is needed when working with remote teams or outsourcing (e.g., agile processors such as Scrum, Kanban). It will help to align all the team members towards the end goal.

As you can see, there are various ways of reducing the costs by maximizing the outcome.

Summary

This article has discussed several factors you need to consider when deciding the team structure for effective software engineering teams.

Some of these decisions you’ll need to make upfront, so you won’t know what needs to be adjusted until the team gets rolling. After some time, it’ll be easier to identify where changes need to be made, whether it’s costs or collaboration.