software development

Enabling software engineering teams for success.

Ricardo Sanchez

May 15, 2020 — 4 min read

Software development is hard, and it isn’t always the programming language or the framework you use, it’s the people who work on it.

People are an essential part of a team; everything can be easily changed and fixed, but you need to make sure people work well together to achieve effective communication and a great culture. In my software development career of over 20 years, the critical difference between successful software projects and failed ones has been how engineering teams are created and how they are allowed to function over time.

Successful software projects result from great teams, and people in these teams always have a history of working together for some time. When people know each other, they understand each other’s weaknesses and strengths. So it’s easier to balance the work, the responsibilities, and the expectations.

Keep people together

When people in a team know each other well, the communication flows smoothly, and it’s often more sincere and competent than when people don’t know each other well. So communication is vital. It’s what makes a difference between successful and productive teams vs. teams that are not.

I believe people who have worked together for a while are more productive because they are more honest about their mistakes and deficiencies. As humans, we tend to fake our abilities when we meet new people and are often afraid of showing or openly communicating with others about our shortcomings and mistakes. Time is the cure for all of this; just let people work together, allow them to reconcile their differences, and after a while, you’ll have a team capable of doing their work effectively and be very productive.

The Company is growing, and employee count is increasing, now what?

Teams in large corporations often suffer from constant changes due to company growth and a steady increase in employee count. A common reaction to this is to split engineering teams and create new ones, with the idea that placing senior employees in separate teams will help support and grow new teams often filled with new hires.

While this idea isn’t bad, it’s also not optimal for the software development process, productivity, and, most importantly, employee and company culture. By doing this, you are essentially taking a well-functioning team filled with people who have spent months or years adjusting their personalities and experience to maximize their productivity and communication, split them up, and then start from scratch. Having people work with friends will keep them happy and thus be more productive and resilient. What’s better than that?

What about new employees? What about new teams?

When onboarding new software engineers, they should temporarily join experienced teams to get up-to-speed and acquire domain knowledge. After that, these new software engineers should be placed with a new cohort of employees to be the beginning of a long-lasting software development team.

Having an onboarding process like the one I described above can help minimize disruption on existing teams and increase the success rate for new employees, new teams, and, subsequently, the entire organization.

What about people who want to join other teams, or be in a new position?

Keeping people together in a team is all about keeping them happy and comfortable to do their best work. However, keeping them together does not mean that you should force people to stay in a team against their wishes or ignore their desire to move on to a new position or team

Any employee should have the freedom to move to another team or apply for a new position.

What about new projects or products? Who’s going to work on them?

You want teams with people who work well together, people who already know each other and can take advantage of each other’s skills and experience. Teams with people who have worked together for some time can communicate better. People in these teams know how to complement each other’s skills and experience, thus producing better work.

If you try to build a new product or work on any other challenging software project, doing so with a newly formed team will cause frustration, delays, and it’ll be more costly, possibly failing.

You can achieve a higher success rate by having your experienced teams with people who have worked together for a while, take on the new challenging projects, and develop new products. These experienced teams can hand over these projects to the less skilled teams created with newer cohorts.

Allowing teams to grow together will increase the speed, the quality, and the success rate of their projects., it will also keep employees in both existing and new teams happy and interested due to the variety of projects and the bonding formed with the people who are part of their team.

How do new software engineers acquire domain knowledge?

You can have the same people work in the same team for as long as they desire, they can work on different projects and challenges, but it’s a good idea to keep these teams working on projects within the same business unit. Enable people in teams to gain experience and domain knowledge by working on the same type of products within the same or similar business unit, but not the same product.

The ultimate goal

The ultimate goal is to have people in teams who can excel at the following skills to increase their chance of success:

Open, honest, and fluid communication
Common goals
Clear roles and responsibilities
Independence

Any team can achieve these things, but it takes time and effort for people in a new team to get to know each other to accomplish this. People in teams who have worked together for many months or years can achieve all of the above a lot easier; these skills are learned by working with the same people over time. Every time a team is created, especially when you split an existing team to create a new one, consider all of the above before proceeding.

People are what make companies successful, and for people to accomplish this, they need to learn to work well together, and this takes time. So think of people first, assign projects to teams, and not people to teams to work on projects.

Do you have any other recommendations, suggestions, or feedback? please leave it below in the comments.