12 Tips to Successfully Lead a Team of Developers
A few months ago I completed a project that was able to teach me a lot about mentoring, leadership and even myself. This project gave me a chance to lead a group of 5 developers (including myself), and since this was my first time leading something like this, I thought it would be nice to share the 12 key takeaways I received from the experience.
1) It all begins with the requirements
You can’t start building if you don’t know what it is you’re going to build. To take care of this, the first thing you should do is talk to the stakeholders. Let them describe what their need is and try to understand each detail of the requirements.
While it’s necessary to understand the requirements, you also need to keep a critical mindset towards them. It’s easy to get carried away with all of the “nice-to-have” features, but try to question what value each requirement really brings. Are they really necessary or can they be dropped? Try to be a supportive, but critical partner to your stakeholders.
2) Plan out the technical parts
Some people prefer to start building things right away, but from trying that myself and failing multiple times, I believe it’s necessary to first plan out and research what you will be doing.
After gathering the requirements for the project, you’ll want to come up with an initial architecture and tech stack. Compare different solutions to try to find the pros and cons for each, and don’t forget to talk to your colleagues.
If there are any unknowns in the stack, validate them by building an MVP as it will save you from tons of headaches in the future.
Remember, with quality research and planning you bring down the likelihood of having problems in the future.
3) What’s prepared isn’t set in stone
I’m a fan of agile development and one of the best things about agile is that it’s open to changes. With the idea of agility in mind, I advise you to use all your research and planning as your guideline, but not as something that has to be followed. The truth is, problems may still occur and in these cases you will need to come up with a new plan — and that is ok.
For example, in my latest project, I planned to use Kafka for sharing data between various data-centers. During the project, we decided that for the first version, there was no need to complicate things by having information stored in different data-centers. This was a big decision that had a huge impact on the architecture, but I think it was ultimately the right one.
4) Make sure everyone understands the plan
It’s important to take time, especially in the beginning, to make sure each member of the team knows what you’re going to build, how you’re going to build it, and why you’re building it the way you are.
This is important for a number of reasons such as:
- Team members understand why each task is necessary
- They can provide ideas for improvements
- If you’re away, people will still know how to move forward
- Most importantly, during the project, everyone can see the progress and what’s waiting ahead for the project
5) Minimize dependencies on others
In order to save time and have a nice workflow, try to minimize the reliance on others or at least focus on the dependencies at the start of the project.
For example, if you need a design for a project, let the designers provide you with their work before you begin work on the project and make sure to check if everything’s clear to you as a developer and project lead.
During the project, you’ll want to move fast and waiting for others is just a source of unnecessary stress.
6) Make an extra effort to break apart tasks
When creating tasks, try to unpack them into small chunks and ideally provide a how-to or some suggestions for solutions. This not only makes it easier to build, test and review the tasks, but also provides a great sense of accomplishment.
Don’t think that you need to create the tasks alone. Having a weekly planning meeting, where various assignments are discussed and broken into tasks, helps people to sync up and ask questions about what’s coming up next.
7) Always be at least one step ahead
As a project lead, you must always keep the big picture in front of you. When team members or stakeholders want to know what’s coming next, you should be the one ready with an answer.
Tech-wise, you must know how various parts connect together so that when someone asks you about the connection between various tasks, you are able to fully explain them.
My advice here is to start the week with an early morning and go over the upcoming week and the project as a whole.
8) Keep meetings succinct
Meetings.
I’m not a fan of them simply because it takes valuable time away from all the participants, but they can be necessary. That’s why it’s vital to make them as efficient as possible.
My advice? Make sure every meeting has an agenda and a list of expected results. Share them with participants beforehand so they can prepare. If the discussions get off-topic, bring people back to the main topic and don’t forget to pay attention to the clock.
9) Team culture is important and you have a role in it
One thing I didn’t think about before, but learned during the project, is the importance of creating a team culture. It’s easy to take it for granted when you are building projects with people you’ve known for a while and already get along with. With this particular project, most people in the team didn’t know each other before joining. To fix this, one of my teammates pushed us to do various team events and lunches.
Another thing, during breaks, try not to talk just about only work. That can always be done during work. When you’re having a lunch, try to get to know the people, how they’re doing, etc. This extra step can lead to a lot of great initiatives and overall makes working together so much better.
10) Have one-on-ones
I’m a huge fan of one-on-ones. Team members will have their own thoughts and ideas for improvements and one-on-ones are a great way to hear them out.
This is the time to discuss various technical and non-technical topics and find solutions to problems. It’s also the place where you, as a project lead, can hear them on topics that aren’t meant to be discussed publicly.
By having 1:1s with all of your team-mates, you’ll gain a whole picture of how everyone is doing and what their ambitions are while also being able to provide advice and guidance.
11) Delegate and trust others
One person isn’t able to know everything or do everything. This is why I advise you to delegate as much as you can.
When there are business related questions and you have a separate product manager, let him or her handle all of these types of questions.
Tech-wise, I found it useful to distribute the focus. I set myself as the lead of back-end development and my colleague as the lead of front-end development. It turned out to be a great initiative as I could put more effort into guaranteeing the functionality of back-end, but also take care of the management side of things.
Based on that experience, I must say that sharing your responsibilities with others makes your life a lot easier and less stressful.
12) Be the one who clears the road
During my last project it would often happen that there would be environment issues or minor bugs that stopped others from continuing to work.
Since I wanted the team to continue building features and functionality, I took it upon myself to fix any blockers. This way the team can focus on what’s important — delivering the project.
Some other good examples of such situations are tasks related to creating repositories, creating databases or setting up linters.
It may not always be fun, but it does make others’ lives easier.
12.1) Don’t try to be a hero
There were times during the project where I’d forgot that I’m the project lead and just let the developer in me take over.
When I felt the pressure of time and we had some bigger obstacles, I found that explaining everything to everyone would just lose us time, so I would decide to solve them by myself.
In the end, I got things done, but building the solution in most cases took longer than expected and it was hard for others to provide help when needed. Even more importantly — as I got more involved into coding solutions, my quality of preparation for meetings and creating tasks went down, which made other teammates also suffer.
This is why I advise you to always let the team know what’s going on and break your challenges into smaller pieces when you can.
