What constitutes an amazing development team? There are tons of different ideas out there. What works for one team doesn’t necessarily work for another and building teams can be made easier or harder, depending on management’s vision. So, this article explores the baseline needs that will prepare any team to be amazing.
I’m defining an amazing development team as follows:
A team of developers who are competent enough to solve the problems and challenges that your business faces (technically) — whether as individuals or as a team — by whatever means necessary and within the development guidelines of your organization. An amazing development team does not require constant supervision and can operate fairly autonomously, can work methodically and within whatever manner the business requires (waterfall, scrum, kanban, etc.) while following processes and knowing when to ask for help. The team should work as a team and will adopt methods that are necessary to complete the task at hand, within a reasonable time frame.
This is the essence of what managers, VPs, and CTOs strive to achieve.
Most of these kinds of executives tend to say they are looking for “the best developers in the industry.” Is this the right way to build teams? For some, sure. But for everyone else… no.
Why should a manager not strive for the best developers? If a team can attract the best and secure them, then great. But there is a very big problem with this: There are thousands of development teams around the world and not all of them can have the “best developers in the industry.” Developers are a finite resource, and the best are a rarer breed, still.
Instead, managers can make the best team possible with the developers that are already there or can be hired. If a manager’s interview skills are up to scratch, then the team will already have good developers. And unless a team’s working on low-level, sub-millisecond, transactional software, the best developers may not even be necessary.
Hire the developers that you can get that are good enough for your business, have a willingness to learn, a desire to improve, and are ambitious.
Ultimately, building an amazing team is a two-way street: the manager must give the team every opportunity to learn and progress their skills; the team should try their best to resolve problems, raise issues, get training, and be a team player.
Putting the developers of natural genius aside, all of the other best developers are so because they have been afforded opportunity, nurturing, and leadership from the beginning of their careers, allowing them to flourish where others haven’t. It is more complex than this, but this is the essence.
Bottom line: Hire the developers that you can get that are good enough for your business, have a willingness to learn, a desire to improve, and are ambitious. That will create an amazing team.
Let’s break this down further.
It is the responsibility of every development manager to offer training, where possible. This can be paying for courses or online training, or allowing your team members to spend some time learning by themselves using online tutorials, YouTube, or downloading sample code.
If training is required, it is the duty of the company to ensure their developers are able to keep pace with current advances in technology. Smaller companies will have restrictions on how much they can afford, but should offer opportunities to learn. Even if means a task takes longer because the developer is learning as they go, give time for the developer to do their job properly, rather than just getting a task working, and they will learn more along the way.
Affording the time to figure out new and better ways of solving problems can bring huge benefits; the product could be better, more effective, or resilient. And the developer will have learned how to apply those new skills to other areas of the product.
Do developers enjoy their job? Do they enjoy working with the team? Do they actively participate in meetings, in the general office environment, in social situations? These are questions managers should be asking.
Because when a developer does not participate, this can be a warning sign. Maybe they are not motivated, they could be unhappy, or it could simply be that they do not understand an issue and are staying quiet rather than speaking up. Either way, this has to be tackled and managers need to find out the source of the problem.
Some of this could be about a dearth of training. A lack of understanding could mean your developers lose confidence, become withdrawn, and eventually, lose motivation.
Managers will, of course, lose developers. This is inevitable. Even the biggest and best companies cannot and do not retain every single developer. However, when a developer does leave, it is important to understand the reason why. If it is due to a lack of something — especially motivation — then managers do not want to let all of the talent feel this way and leave. Ultimately, it’s the manager’s responsibility to stay on top of workers’ motivation.
Motivating a team can be quite simple. One core element is creating an enjoyable office environment. For example, managers can extend invites for Friday night beverages. Or offer a team lunch down at a local bistro. Keep in mind: not all employees are keen on evening social events as they may have family commitments, long commutes, or just don’t want to stay out. This shouldn’t be frowned upon, but switched to lunchtime team get-togethers instead. There are developers who do not participate much in social events but they love being part of the team because they get on well with everyone and enjoy working alongside them.
Mutual respect is one of the greatest bonds of a team. Respect for each team member, regardless of differing outlooks, political views or ways of life will go a long way to making a happy and motivated developer.
One key motivation-killer is how a managers deal with failure. All teams will experience failure from time to time, some more than others. How a manager approaches this fact will have an impact on motivation. This is possibly one of the biggest factors that can break a teams’ motivation.
Developers are great when they are given responsibilities. Yes, some can fall short but some can also excel. When a developer has ownership and responsibility for a particular area of a product, maybe a specific feature, they will make it their mission to ensure it is running smoothly, works as well as it can, and will actively look for improvements.
For example, a developer doesn’t simply need to write code. If a developer has interests in development and operations (DevOps) or Amazon Web Services (AWS) — for example — then have them work with the DevOps team, get involved with the architecture of AWS; be responsible to liaising between the dev team and the DevOps team for future changes. Let developers have some ownership in what they are developing and this can keep your team engaged and it also helps for team building and motivation.
If you can attract “the best” and secure them, then great, but there is a very big problem with this: There are thousands of development teams around the world and not all of them can have the “best developers in the industry.”
When building a new development team, there’s the luxury of hiring new developers. Do this well and the team is halfway to greatness. If, however, the team already exists then there may be a little more work to do; with an existing team, things have usually settled in and it can be difficult to get people to change their ways. But they can and they just need a little bit of convincing.
What to do with a team that doesn’t want to change?
Give them a reason to.
Book a meeting room, throw some snacks on the table, and make it a relaxed atmosphere. Remember, this is about making changes to how the team operates, not having a deep discussion on system architecture. Explain, even demonstrate, the changes to be implemented and allow the team to ask questions, even challenge these new ideas.
Developers are intelligent people, so allow them to be part of the discussion rather than just imposing change upon them.
Regardless of the size of any team, members should understand and respect the hierarchy; for example, junior > mid > senior > lead > manager. That doesn’t mean that a lead can or should look down on those at a lower rank, nor does it mean that the junior developer should feel any less in the team than a senior or lead. Everyone should be equal. However, it is important to maintain the escalation paths.
Additionally, management of a team should not be overbearing. Don’t constantly ask for updates, nor actively monitor each developer to ensure that they are working hard. Allow your team to know when they have done a good job, not just when they have gone wrong. Too many managers scold when things don’t go right but rarely offer praise when things go really well.
On the praise front: be genuine and be specific.
The Amazing Team
Remember that a team is a team, not just a bunch of bodies there to complete tasks. A team can also extend beyond the developers to include technical project managers, business analysts, scrum masters, and anyone else who is involved on a regular basis in the project, from the technical side. Without these critical roles, a team may lack direction and focus and no matter how well the team gels together a team cannot be amazing if they’re not delivering what the business needs.
Applying these general principles to your teams can mean that they produce some great work, have great progress, and form a really close bond of people who enjoy working together.
Remember: search for the right mix of responsibilities, training, and structure and be confident that your team can succeed.
These are some things to keep in mind when building a team of developers.