What does it take to be a front-end lead developer? An overview, personal experiences, tips, and tricks.
And then, all of a sudden, I was a lead developer.
The client I worked for a few years ago had several major features planned. A large codebase with significant technical debt and an urgent need for refactoring. From “higher up,” there was a desire for a single point of contact to oversee the progress and complexity of the project. The front-end team was a solid group of seven developers, with diverse knowledge and ideas.
There was a need for one captain at the helm, and that became me in the role of front-end lead developer.
In the past few years, I’ve been a front-end lead on multiple projects. In this blog post, I’ll outline the complete picture of that role so that you’re prepared if you ever step into the position of lead developer. These are areas you can focus on and develop yourself in with books, courses, or conferences.
What does it involve?
Partly, you deal with the (front-end) technical side of what you’re building. You support the entire team to make that happen. You keep an eye on the big picture of the infrastructure and set a clear goal on the horizon. Outside the team, you’re a point of contact for various people, such as product owners, partners, and business stakeholders.
The exact responsibilities vary depending on the company. Perhaps there are multiple front-end leads for different teams, or there’s a tech lead overseeing both the front-end and back-end.
In summary, the role consists of:
- Code
- Infrastructure
- People and Interactions
I’ll address these in reverse order.
People and Interactions
While front-end development already involves collaboration with other disciplines, stepping into a lead role adds more weight to the process. Before major new features are built, they are conceptualized, broken down, designed, reviewed, improved, and rethought. Even when things become more concrete, as a lead, you can influence how the team approaches these tasks.
Throughout these processes, you're constantly reasoning and persuading. Sometimes you're coaching or mentoring. Above all, you’ll spend a lot of time in meetings.
Coaching and Mentoring
How do you effectively support your team members in their work? In their development as developers? What’s holding them back from being productive in a team? How can they gain a fresh perspective on things? How can they get to know themselves better? What’s really going on with someone?
Not everyone is a natural-born coach. For me, deliberately seeking training in this area has been beneficial.
The world of coaching and mentoring can be quite broad when it comes to self-improvement. One of the most important lessons I’ve learned is to listen to understand, rather than to respond. After someone finishes speaking, resist the urge to immediately suggest something. Instead, ask clarifying questions.
Meetings and Agendas
More responsibility means more alignment, often with a larger group of people. More meetings. You may also feel the need to coordinate how/what/when certain technical tasks will be developed.
Sometimes this is necessary, but often less so. Without clear boundaries, your calendar can quickly fill up with meeting invites from others.
Keep a close eye on your schedule and deliberately set aside time for the tasks you want to complete daily. For example, block time for code reviews or even for taking breaks.
Of course, not everything needs to be a meeting. Asynchronous coordination, such as in a Slack thread, can be highly effective and accessible.
Collaborative Engagement
How do you work and collaborate effectively? Do the same discussions happen repeatedly, with the same people dominating the conversation? Is everyone truly heard, and is there openness to new ideas?
From the agile world, I was introduced to Liberating Structures, which include various methods to engage a group based on an invitation. For instance, inviting participants to brainstorm in smaller groups.
Liberating Structures help me quickly mobilize a group to tackle an issue, ensuring that everyone involved has a chance to contribute. This contrasts with traditional meetings where a few dominant voices often steer the discussion.
The Liberating Structures website contains a wealth of information, and I highly recommend experiencing it firsthand at a meetup, such as the Liberating Structures User group in the Netherlands.
Infrastructure
Someone needs to ensure technical reliability and chart a clear course. As a lead developer, it’s your responsibility to use your leadership and insight to keep the ship seaworthy.
This involves various areas, such as security, privacy, accessibility, and dependency management. Periodically, you’ll need to review (or delegate a review of) the codebase. Additionally, you’ll need to set goals in these areas that the team can work toward. Maintaining a broad knowledge of architecture, infrastructure, and technology is crucial, even if you’re not building everything yourself.
A great time to review documentation is just before a new developer joins the project. They need to understand how everything fits together. There should be documentation to introduce, set up, and develop the project. The onboarding process is an excellent opportunity to update and refine documentation. A fresh perspective can invigorate both the team and the codebase, often leading to meaningful improvements.
Another indicator of infrastructure health is how often team members point out problematic areas. Keeping track of this feedback gives you more leverage to implement improvements in a timely manner.
What could be better?
What must be better?
Code
At the end of the day, you’ll likely write much less code yourself.
Most of your time in the codebase will be spent sharing knowledge through pair programming and pull requests. For every interesting piece of code you could write, think about who on the team could do it instead. The best candidate might not be the fastest but rather the one who could learn the most from the task.
It’s important not to become a bottleneck for the rest of the team. Avoid taking on too much work yourself, as it could lead to long turnaround times. A common mistake is trying to do all the code reviews yourself, which can quickly create unnecessary pressure.
You might focus on smaller tasks, such as those that seem less urgent but have been lingering for a while.
In Conclusion
Maybe you prefer to stay anchored and keep your focus on code. Or perhaps you’re ready for the challenge of taking the helm. Either way, you’re never alone, and hopefully, the above offers a useful glimpse into the role of a lead developer.