building our developer team
Over the past few years I have worked with many developers on my team and sculpting and refining a good engineering team is always an ongoing process.
What is it that actually constitutes an amazing development team? What determines the difference between good or great?
There are tons of different ideas and opinions on this topic, but from experience, what works for one team doesn’t necessarily work for another. I also believe that building teams can be made easier or harder, depending on the leadership’s vision and how we work with our people.
First let’s try and define the perfect development team:
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 organisation. An amazing development team does not require constant supervision and can operate fairly autonomously, can work methodically and within whatever manner the business requires 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 we strive to achieve in our company.
Most executives tend to look for “the best developers in the industry.” Is this the right way to build teams? For some, sure. But for most… no. Some of our developers are certainly not the best in the industry but they are irreplaceable and incredibly valuable due to the role they play in the team environment.
Why should managers 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. It took us a very long time to put together the quality team we have today.
It is our responsibility as leaders 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 our duty to ensure our 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. There are thousands of learning resources out there that don’t cost anything. Even if it means a task takes longer because the developer is learning as they go, we give the developer the time required to do their job properly, rather than just getting a task working. They will learn more along the way.
Affording the time to figure out new and better ways of solving problems brings huge benefits to our team; the product could be better, more effective, or resilient. And the team would have learned how to apply those new skills to other areas of the product. It also helps to have an open and transparant relationship with our client so we can ask for time delays in order to do things better. We pay for the school fees of course.
Do our developers enjoy their job? Do they enjoy working with our team? Do they actively participate in meetings, in the general office environment, in social situations? These are questions we ask regularly to make sure we have a healthy space.
When a developer does not participate, it 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 – whether it is work or personal. We often get involved in personal matters when our team needs it. That is the difference between being a mentor more than just a leader. The professional as well as personal development of my people is very dear to my heart. Almost every developer that have passed through our business left with more than what they came in with.
Some of this could be about a lack of training or understanding which could mean developers lose confidence, become withdrawn, and eventually, lose motivation. It is up to us to make sure they are engaged and get the training they need when they start falling behind.
Obviously we do lose developers, it’s 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 — our management team needs to change something so we don’t lose all of them. Ultimately, it’s our responsibility to stay on top of our team’s motivation.
Motivating a team can be quite simple. One core element is creating an enjoyable office environment. For example, we could extend invites for Friday night beverages or a team lunch down at a local pub. Honestly this does not happen often enough and is something every team can improve on , being mindful that 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-together 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 in many teams is how 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. We tackle failure together as a team and do whatever it takes to get it done.
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 should, and actively look for improvements.
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 do you 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, managing a team should not be overbearing. Don’t constantly seek 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. I also make a point of making myself available at any given time to provide input, feedback or support in any way possible. When I go around my team’s desks I don’t check up on whether they are working, I am offering assistance, ideas or simply there to answer questions.
The Amazing Team
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 managers, scrum masters, and anyone else involved on a regular basis on projects, from the technical side to admin. 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 team can increase their productivity, progress, and form close bonds between people who enjoy working together.