How to Build a Software Team

In late 2022 I hit five years of experience as a team lead in the software industry and roughly ten years of experience as a software engineer. In that time, I’ve worked with dozens of engineers, skimmed countless resumes, interviewed tens of candidates, and seen a lot of successes and even more failures. Lately I’ve been thinking a lot about those challenges and the things I’ve learned along the way from the teams I’ve worked with.

As engineers, our approach to things tends to be guess and check; that is, try something out, measure the result of the attempt in some meaningful way, and then adjust the approach based on those measurements. So, after a lot of trial and error, I thought it might be useful to break down what has worked for my teams and what hasn’t.

I’m not sure any of these ideas are new, but, when combined, they seem to create a much more radical change in the way a team functions than you might expect.

You Need People with the Right Attitude

Attitude is what separates mediocre engineers from the greats. It makes a bigger difference than any credential, be it experience or degree. On a team you need people who are willing to be wrong, because being wrong is always the first step in creating something new. The discipline itself is primarily one of learning, so I always look for people who are curious and love to learn.

If someone on the team has an arrogant attitude, their priority is their own pride and making sure they never look bad. From what I’ve seen, this isn’t the type of behavior that can be solved with feedback or training, and so someone like that just shouldn’t have a place on the team. With any luck, the experience of being fired will be just the right piece of humble pie they needed to grow and be successful in the future.

Help the Team Understand Their Role

The next piece of the puzzle seems to be clarifying what it means to be a part of the team. This applies to the engineering roles as well as product, DevOps, QA, scrum masters, and anyone else who contributes. Each team has different needs, and those roles, while sharing the same titles, can have very different responsibilities.

Thankfully, each team has the same end goal from which we can derive the roles on the team and the value they bring. The goal is to deliver as much value to the customer as you can as often as possible. This requires you to know who your customers are and what it means to provide them with value. In software the definition of value is simple; a valuable software product makes people’s lives easier. It adds convenience and makes it faster and more efficient for people to accomplish their goals.

Each team member’s role is then simply the way in which they can use their skills to best contribute to that overall goal. Sorting through the details requires you to take the time to explore those responsibilities and provide feedback (often) on which actions contribute to the goal, and which take away from it.

It’s important to note here that not everyone will agree on the details or the priorities of those details. The part that matters is that each person understands where they can add value, and, perhaps most importantly, where they can’t.

Ask for Forgiveness, Not Permission

Getting people to contribute their best requires freedom and flexibility. Some of the worst, most inefficient teams I’ve worked on were filled with people who were afraid to act. This didn’t stem from not understanding who held which responsibilities, instead it was often out of worry about the consequences of taking the wrong action. In a dysfunctional team, everyone is walking on eggshells and worried about upsetting that one jerk at the office or getting fired.

You need an environment that allows people to take actions in pursuit of the team goal without mountains of red tape in their way or approval from someone who doesn’t understand the subject-matter. If your team knows how best to add value for the customer, you can trust that will be goal of their efforts.

Furthermore, it needs to be an environment that doesn’t punish people for honest mistakes. Remember, you hired people for their humility and willingness to learn. These types of people tend to take responsibility for their actions and do everything they can to make it right. They’re also unlikely to make the same mistake again. Engineering is a discipline of getting it wrong before you get it right.

Tell Them Why to do Things, Not What to Do

When you give a team the freedom to act, it helps when they know the reason behind as many things as possible. When mentoring, the most important thing to do is take the time to explain why certain things are done and why they work the way they do. Knowing the reason behind the process goes a long way in preventing mistakes. You’d be surprised how often I see leads skip this part.

If someone knows the reason behind the decision, it also becomes a discussion from which both parties have a chance to learn. You never know when that junior knows something you don’t and will have a great idea of how to solve the core problem.

Let Them Fail

It’s usually not enough to just know why things are done the way they are. People often need to experience why in order to fully understand it. This is why it helps to give people the room to act and take on things they may not be ready for.

The instinct I’ve had in the past is to just do things myself, because other people hadn’t done it yet, and I wasn’t sure it would get done right. This approach is neither helpful nor productive. A much better approach is to give the task to someone who isn’t ready and let them try to solve it. Then, take the time to follow up and work with them to refine the solution. This gives people the chance to grow and will make for a much stronger team in the end.

Fight for Them

At this point you’ve built a great learning environment with a motivated team that’s always pushing the envelope, but one that sometimes makes mistakes because of that. This type of team can make some people within an organization very nervous – I can’t count the number of times I’ve heard the phrase “going rogue” muttered among my less understanding colleagues. Because of this, these teams won’t last unless you fight for them. A lot.

The team needs people who actively advocate for them. They need to know they have people on their side, or they’ll start being afraid to act. Sure, then they won’t make any mistakes, but they won’t make any progress either and won’t learn a thing.

Conclusion

Obviously, there are a lot of other fundamental ideas and processes in the software industry that make up the day to day running of the team (like agile), but, once the above ideas are put into practice, my experience is the other pieces of the puzzle will naturally fall into place.