Depending on your definition of an amazing Dev team will make this challenge much harder or much easier. That doesn’t really help anybody, though. To put one thing into perspective, though, I will give you my definition of an amazing Dev team.
A team of developers who are competent enough to solve any problems that comes their way – whether individually or as a team – by whatever means necessary and within the development guidelines. An amazing Dev team does not require constant supervision and can operate fairly autonomously on development tasks, can work methodically and within whatever manner the business requires (waterfall, scrum, Kanban, etc.) while following processes, procedures and knowing when to ask for help. The team should work as a team and will adopt whatever methods are required for completing the task, withing a reasonable timeframe.
OK, so this isn’t completely straightforward, but it also isn’t what I have heard touted by others who want to build teams, who pride their teams upon being the best developers in the industry, yadda, yadda…
Why should this not be the case? Well, if it isn’t obvious: there are thousands of Dev teams around the world. Not all of them can have the best developers in the industry, instead you want to make the best team possible with the developers that you have. Anyway, if your interview skills are up-to-scratch then you will have some good developers, anyway.
Building teams is a two-way street: you – as the manager – must give them every opportunity to learn and progress their skills; they should try their best to resolve problems, raise issues that they are facing with management in order to allow you to create opportunity and training, while being a team player.
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, paying for online training or just allowing your team members to spend some time off of the project, learning by themselves via online tutorials, YouTube, downloading sample code, etc.
If training is required, it is the duty of the company to ensure their developers are able to keep pace with technology (where appropriate: you aren’t paying for them to be at the top of their game in technology that is irrelevant to you). Smaller companies will have restrictions on how much they can afford, but you should offer whatever opportunities to learn that you can. Even if that ends up being giving task X 5 days instead of what you would otherwise expect to only take 1 day, to give time for the developer to do the job properly rather than just getting it working.
Do your developers enjoy their job? Do they enjoy working with the team? Do they actively participate, be it in a social setting, in the general office environment or in meetings. Developers who do not participate may either not be happy (maybe they don’t care enough to participate, or they are reluctant due to the culture) or they don’t understand so they are staying quiet. Either way, it has to be tackled to find out the problem. If it is the latter, see my point about training, otherwise you will have to look deeper.
Even if a developer gets to the point of being unhappy that they leave, it is important to understand the cause of this so that other developers do not go the same way.
Motivating a team can be quite simple. It is having an enjoyable office environment where no one is singled out, the team isn’t being whipped into working harder and faster than they actually can as this will actually make progress slower, and ensure that the team gets along outside of the office.
Throw out invites for Friday lunchtime and have a team lunch down the pub or local bistro. Not all employees are keen on the evening social down at the bar because they may have family commitments, long commutes or just have got to the end of the day an don’t want to stay out. This shouldn’t be frowned upon, but switched to lunchtime instead. Those who want to go out for after-work drinks can still do so.
Mutual respect is one of the greatest bonds of a team. If you can respect each other for their views, way of life, decisions and ideas, then you’ve gone a long way to making a happy and motivated developer. I have know developers who do not participate much in social events (they weren’t big on drinking alcohol and they were desperately saving their cash for buying a house and an upcoming birth) but they loved being part of the team because they got one well with everyone and enjoyed working alongside them.
Developers are great when they are given responsibilities. Yes, some an fall short but some can also excel in their jobs (that’s life, isn’t it?). When a developer has ownership and responsibility for a particular area of your product, or a specific function, they will make it their mission to ensure it is running smoothly, works as well as it can do and will actively look for improvements.
Don’t think that a developer writes code, then DevOps creates the AWS servers and then deploys said code and that is the end of it. If a developer has interests in DevOps and AWS (for example) then why not get him working with the DevOps team? Why not allow him to be involved with the architecture of the AWS VMs and services? Then you can make that developer responsible to liaising between the Dev team and the DevOps team for future changes.
If you have a Git repository, maybe you have Jira and Confluence, then why not allow one of your developers to take ownership of the respositories who can review and make suggestions to improve the way Git is used in the team, and another could be given ownership of the Confluence space that relates to the Dev team.
These are just some examples, but helps make your team actively engage with processes. Some may actually want to get more involved and have better ideas on how to improve them further. But there are so many other ways that you can get your team engaged (and not just with processes).
If you are building a new Dev team, you will have the luxury of hiring developers. Do this well and you’re potentially half way to building a great team.
If, however, you already have a team and you want to make it amazing then you may have a little more work cut out for you; if only in the fact that when you put together a new team, developers already have a mindset for a change in how they usually work. After all, every team is slightly different. But with an existing team, things have usually settled and it can be difficult to get people to change their ways.
They just need a little bit of convincing.
What do you do with your team when they don’t want to change? Give them a reason to. Book a meeting room, throw some snacks on the table (is this bribery?) and make it quite a relaxed atmosphere. Remember, we want to make changes to have the team operates, not having a deep discussion on system architecture (unless that is what you want to discuss). Explain, even demo, the change you want to make and allow them to ask questions, even challenge your change.
These are intelligent people, so allow them to be part of the discussion rather than just imposing change upon them. If they are involved, maybe you come to an agreement that your original change wasn’t suitable but have now altered it and are going forward with a slightly different approach. They have been an integral part of that change and therefore are now behind it (or at least more than they were before).
Do not, however, put forward suggestions that do not reflect your true intentions. Firstly, everyone may agree and your plan has backfired by suggesting an incorrect version of your change with the intention of getting everyone to alter it to what you actually wanted. Secondly, if you’re always coming up with changes that don’t start out as a well thought-out idea, they may realise this and lose trust in your ability. This will likely increase resistance to future changes.
Maybe your team is only two or three developers; this is quite a nice size to have a close-knit team. Maybe your team is 15+ developers; much harder to have the close-knit, but not impossible, just unlikely. But no matter how well your team get on with each other, they should understand and respect the hierarchy: junior > developer > senior > lead > Dev manager (or however you name your positions).
This is important as this maintains the escalation paths. It doesn’t mean that a junior developer could only speak to a mid-level developer, but that seniors should have a senior role and be able to offer assistance and some direction to lower-level Devs, whereas the lead should be doing the same but ensuring everyone under their purview understands the goals, the project and their assigned work, and being the first port of call for any issues. This doesn’t mean that the development manager should be able to kick back until the lead raises issues with him, he should be actively involved and understand at each stage when there is an issue, concern or delay and be proactive in getting any issues resolved.
However, management of a team should not be overbearing. That means that you shouldn’t constantly ask for updates (that’s what the sprint meetings are for), nor should you be actively monitoring each developer to ensure that they are working hard. Again, you will know that when the sprint is delivered as well as reports from the daily standup, if you have them. You should also 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 (maybe rightly so, but consider if the issue is big enough or detrimental enough to deserve this) but rarely offer praise for when things go well or really well.
But, on the praise front, don’t be patronising. Be genuine and only praise what needs to be and to a level that is sufficient; don’t dish it out too strongly.
The Amazing Team
Now, this doesn’t tell you how to build your team. At the end of the day you will need to figure out what works for you and your team, but these are some things to keep in mind when building that team up.
The teams that I have built so far, I had applied these principles and we’ve had some great work, great progress and a really close team who enjoyed working together. It also made leaving that team harder to do, but I knew they would continue without me as before.
Now, I am with an existing team and trying to bring them together. I know this will be a slow process and don’t expect to see the results that I want from the team for a few months yet. That, however, doesn’t make it any less enjoyable or more frustrating; in fact, this is my greatest challenge for building a team yet, but I am confident that we will get them all working together, following new procedures and be an amazing team in time.