Responsibilities of a lead developer

Over the years I've been a lead developer on different types of teams for different types of companies and environments.  The past few years, I've been lucky enough to be able to manage and mentor some great developers to become leads themselves.  At first, I had assumed that everyone would know what being a lead is about, and what their responsibilities are since they had been on teams with leads their whole career.  However, this was definitely not the case.  Every developer came in to the lead role with different ideas of what their responsibilities should be. Despite me discussing the responsibilities with them, they were really surprised at just how many things a lead is responsible for. In order to help set the expectations with developers over what I think a lead's responsibilities are, I put some effort in to documenting what I view as the responsibilities of a lead developer and I'd like to share that with everyone.

This list is based on my experiences of what I've seen work and not work on teams.  It also reflects the types of companies I've worked for - growing companies with frequent new hires, many less experienced developers (including many right out of school), frequently changing projects and priorities, and in general a decent amount of chaos.  If you're at a stable company on a team of very good and experienced developers working on a long running project, and not a lot of chaos, a lead developer shouldn't have as many requirements as I describe here.  But, I don't think that is the norm in our industry.  In the types of companies I've been at, a strong lead developer that takes responsibility of the output of the team is critical for the success of a team.  I have yet to see a team in this type of environment excel if the team tries to distribute most leadership responsibility to all team members and doesn't have a strong lead.

Also, to clarify, "lead" by my definition is not a manager.  For this post, a lead is not the one that is handling performance reviews, administrative issues, and overall career development for the software developers. Many times it can make sense to have the lead developer also be the manager of the developers on the team, but that just means that the person has some additional responsibilities.  They still have the full lead responsibilities too.  And a lead by my definition does not typically handle overall project planning and coordination between teams on multi team projects. The lead should have input here, but, taking those responsibilities on is a little too much for a lead in my opinion. The lead should be focusing on their individual team.

My list is NOT comprehensive, the responsibilities as a lead developer are going to vary and change all of the time, but all come back to being the leader of the team more so than anyone else on the team.  With being the leader comes accountability for the team.  A good lead developer must be an accountable leader. Read http://www.brandonhall.com/blogs/the-buck-stops-here-a-culture-of-accountability-drives-effective-leadership/ for a really quick summary of what that means. The lead (along with the manager) should be held accountable for the output/results of your team - both the good things coming out of the team and the bad things.  "The team" means the entire team - devs, testers, product managers, scrum masters - not just developers.

So here is my list of lead developer responsibilities. For each responsibility I will give some examples of how you can do this.

Ensure high quality work is coming out of team

High quality means that the work that is being produced follows all best practices, and has minimal to no bugs. There is a lot that you can do to ensure this:

• Full and good code reviews are being done by you - you are the one who needs to be approving code on the team and enforcing this. If your team does not do code reviews, start!  Others on the team should help in the code reviews but you are the point of responsibility. Many code review comments by you should lead to changes by the developer, but, be sure to allow the developer space to reply if he/she disagrees with your suggestions, and be open yourself to backing down on suggestions for change. Hopefully you will learn some from the developers in code reviews as well.  This should occupy a good portion of your time. Don't just look for styling/syntax.  You should be able to fully explain to someone else what the code is doing, how it's doing it, and why it's doing it that way.
  Ensure proper test code is being added while functionality is being developed, not as follow on work after the functionality is delivered. 
• Ensure developers are doing the proper amount of local testing - sit with them (meaning actually sit by them and have them go through the local testing with you, or if remote, do a video call with screen sharing) and work with them to see this. When you see bugs introduced by developers, sit with them and discuss it to see how the developer can improve to reduce bugs in the future.
• If a developer continually produces code that does not follow best practices, sit with them and work with them to identify why this is, and what can be done to help them to produce better code in the future.

Ensure developers are at maximum productivity and that the organization is getting maximum value out of them

Most of us work for businesses, and businesses main objective is to make money.  You as a lead play a key part in this so you must be doing what you can to ensure the developers are realizing their potential and are getting as much done as they can (WITHOUT working long hours). Many leads struggle with this because they do not want to have difficult conversations and do not want to ever say anything negative to people, but this is important as a lead.  Managers should be helping with the difficult conversations, but all responsibility for this cannot be deferred to the manager.

• Make sure each developer is producing enough - if you feel they are not you need to work with them to ensure they realize the expectations, and see if there are blockers/issues that you can help with. Take their experience/background in to consideration for this.
• Make sure work is planned out well enough to reduce conflict/overlap with others on the team and outside teams. This can be really hard to do, but will have a huge impact on output of the team.
• Make sure that there is always work lined up for each developer - my guidance is every developer should have at least a full week's worth of concrete work lined up for them and that they need to know what this work is. This will increase their priority on getting work done - if they do not have anything lined up beyond their current work, they will take longer on their current work (I wish this wasn't true but in my experience it is true for most developers). Be explicit on this and don't assume developers will pick up random unassigned work. Anticipate when they are going to run out of work and get ahead of it.  Depending on the environment they can be the ones to pick the specific work, but you must ensure that what they are working on next is figured out. If you have good developers, this is going to be a real challenge, keeping up with them should be difficult!
• If there are things the developer continually does that slows them down, sit down with them to understand their process, see if you can suggest a better way of doing it, or plan out tooling/framework changes to help make things more efficient

Mentoring and coaching developers to grow

You work with them more than their manager (unless you are their manager), so you are in more of a position to mentor developers than their manager is.  Any way you have of suggesting different/better ways for them of doing their work, sit down individually with them and discuss it. Here are some ways you can accomplish this:

• Ensure communication is open and that the developer understands what you mean in your communication.  If you frequently get head nods, and "yeah"'s, this might mean people don't understand what you mean and you need to find another way to phrase what you are trying to say.
• Ensure that every developer has challenging work, depending on their skill level and experience. Watch over time to ensure that they are not continually given non-challenging work.
• Ensure that developers don't get pigeon holed in to always being the one to do a specific type of work. If one developer always takes a specific type of work, get this work spread out to others on the team. This might mean you have to jump in to a conversation and say something like "Joe, I appreciate you wanting to take this on, but I'd like to get more knowledge of this spread out among the team. Sarah, can you work on this instead?"
• Make developers uncomfortable. Get them outside of their comfort zone on occasion.

Help developers - unblock them when they encounter difficult circumstances

Don't wait for a developer to reach out to you - if a developer has not made progress on a task for a few days, it might be best to talk to them individually to see why and what can be done.  In general you cannot rely on developers, or for that matter anyone, to ask for help themselves. Most people don't like to ask for help and like to try to figure out things themselves, but in a team setting, people always days figuring things out on their own is not always best for the team.  Granted, the opposite is not good either - if developers are immediately asking for help for others, you'll need to sit down and talk to them and get them to spend some time trying to figure things out on their own first.

If you don't know how to help a developer that is stuck or in a difficult spot, reach out to others, or get the developer to reach out. First share on the team. Then escalate it up - reach out to other leads, other developers in the company, etc.

Ensure work has had the proper amount of design done, and that the design supports long term usability, scalability, future maintenance

When teams don't have a system to share out to do technical designs on work and share them with each other, I've seen two things can happen.  First, if the developer doing the work is good with designs, they'll do decent designs but deprive the rest of the team an opportunity to suggest better ways, and deprive others on the team a chance to learn.  Or, the design just doesn't happen. This leads to systems and code being produced that are not optimal, and will definitely lead to rework.  And will definitely deprive the team of chances to learn.

As the lead developer, you don't have to be the one to do all of the designs yourself, but, you have to ensure that the designs are being done and shared with the team, and need to ensure that the designs are good. Work being done should be designed to properly meet future needs, be able to scale to meet the expected usage needs (and a little more), and not require high amounts of maintenance in the future.  That can be really hard to do in many organizations, because this will typically mean things will need a little more time to develop right now. But that additional time will pay off very quickly.

I feel that the lead should be doing the most difficult designs on a team. If you don't have the technical skills to do this, and you are not brand new to the team/organization, then, maybe you shouldn't be a lead.  When the design decisions are left to the loudest one on the team, or deferred to architects who aren't part of the day to day of the team, the results will not be good. So you as the lead are responsible for this.

Having the technical skills to do good designs also allows you to help better shape designs that others on the team do.  Much of technical designs are opinions and there is no clear right or wrong answer.  So when disagreements arise of how things should be designed, someone has to make the call over which path to take.  This should be you making this call.  Depending on how your company is structured you may also have architects that will do this, but, I have not worked for organizations that have enough architects to go around to do this for every team.  Now, you don't want to come across as a dictator, so if there are design decisions that others take that you disagree with but you don't feel will lead to poor systems being implemented, you may want to back down and let the designer go with what they feel is the right path.

Some process I recommend to follow to achieve this is to create a standard design template, with questions to be answered for every task/user story done.  Some examples of types of question for the template are any data structure changes (like new database columns, data types, etc), if APIs are used describe any interface additions/changes, and high level description of automated testing that will be written. Having this template is not enough though. You need to ensure that it's followed and this will require persistence, because not every developer wants to be bothered with this type of activity. A key part of this design is not just having developers do it, but share it with everyone on the team.  This will lead to better designs, the more people think about a problem, the more potential solutions will be discussed.  This is also a great way for less experienced developers to learn from the senior developers.

Part of this process can be to require the design be done and reviewed with the team before coding starts on every task.  Many leads do not like issuing mandates like this, and in some environments it's not necessary, but if you feel this will help, by all means institute these processes.

Don't let the design reviews stop at just the team! Reach out to other leads, managers, architects outside the team, etc to get more input for sufficiently complex designs. You as the lead will need to be the one to initiate these conversations.

Ensure future work is properly lined up

This means getting ahead of requirements. If product managers are not ready with upcoming requirements for the team, continually try to work with them to get requirements ready. Offer to help. If they are not willing to let you help, or cannot get things lined up, escalate to your manager and/or their manager.  I don't want to prescribe a specific process, but you as the lead need to help to ensure the work is lined up.  Dropping a ton of requirements on a team doesn't mean the team should start working on these right away - work needs time to be thought through, planned, and designed.

Work with product management to ensure that requirements coming in to the team are structured for maximum efficiency in accomplishing high level project objectives

You should be working with PMs prior to planning meetings on this. Always think of better/more efficient ways to accomplish the end goal and suggest this to PMs (and designers if it's a UI heavy thing). Suggest ways to get to an MVP sooner.  Challenge yourself to always do this even if the idea seems weird/unusual.  Product management working on their own to come up with the path to get to the end goal usually does not lead to the best path.  The more input on this, the better.  Feel free to involve others on the team in the discussions too!

Work with product management to ensure that work coming in to the team is sensible and is a valuable use of the team’s development time

If you don't think the work makes sense for the team to do, that it does not seem like it's worth sinking the time in to, talk to the product manager.  You probably aren't the only one thinking of this.  Push them to come up with the business value and explain it to the team.  Organizational politics can come in to play here, but don't shy away from questions because of this  Getting a project that won't provide much value put on the shelf provides huge value for the organization!

Work with product and project management to ensure project objectives are understood by the team

The more the whole team understands the objectives and feels a sense of ownership, the better ideas will be proposed, and the more motivated the whole team will be (more motivation = happier team members = more output).  This isn't just the responsibility of the project manager or product manager. As lead you need to ensure the whole team understands project objectives.

Ensure builds and releases are stable and go smoothly

This can vary a lot based on how the company is structured with devops, SRE, and development teams.  But you as a lead should ensure there is some sort of  continuous integration/continuous deployment system, and that these are kept stable.  If there is no easy/central build and deployment pipeline and system, you've got some work on your hands!

Keeping this stable is crucial.  When it's time to get a developers code pushed out, whether for internal testing, or to production, it must be easy to do.  I've seen builds fall in to disrepair and unstable automated tests cause people to bypass all automated tests.  If you're lucky you'll have someone on your team that really cares about this and will help others when things start to fail.  But, if you don't, you'll need to take this up yourself.  But I don't want to prescribe any specific solutions, different organizations take very different stances on this.

Ensure proper communication and collaboration is happening between different groups (development, QA, product management, project management, managers) on the team, and that relationships are positive

Some ways that you can ensure this is:

• Work to get more communication to happen between individuals on the team - you'll probably need to continually push developers to go talk to others on the team and not rely on chat rooms too much.  
• Make sure that all stakeholders who could have an interest are in relevant discussions/meetings. This is not just the job of the scrum master.
• Interject yourself in communications that appear to be turning negative to keep them positive and focused

Ownership over services/functionality that your team owns

In most organizations, teams "own" different areas of functionality of the applications that are being used in production.  The team isn't necessarily actively working on all of these areas but should be considered the owner.  What ownership means can vary wildly but typically involves investigating and fixing bugs found, monitoring for functionality degrading/breaking, addressing performance/scalability, and planning future major enhancements.

This can be difficult when code is long lived and teams frequently change.  As the lead, you should be the primary point of contact for these areas. So when inquires come in, you need to be able to answer them yourself or point to someone who would know.  If you don't know where to start, that's a good sign that there needs to be knowledge sharing and more documented.  As the lead, it's your responsibility to ensure that there is knowledge spread so there isn't one single person with all of the knowledge of something. For anything that your team owns, if a high priority bug comes in, your team should be able to quickly diagnose and fix, regardless of who is on vacation. If this is not the case, work to make it true.

Taking care of cross team requests

Lots of random things come up from people outside of the team. Ensure that these are given the appropriate priority and are not ignored. Many times, teams view these as distractions, and scrum masters sometimes view it as their job to shield teams from anyone outside of the team. While this may be best for short term project gains, it's not the best for the overall organization. As the lead you can help here by being a primary point of contact to ensure that others outside the team are getting the necessary support from your team, without distracting the individual contributors from their current priorities any time there is any external request.

Ensure team, and individual team members, are continually striving to improve productivity and deliver more

Never settle on a "good" velocity. Always try to push the team to deliver more, and be smarter about how they do their work.

If you feel individuals on the team can do more, push them to do more. Give them more assignments.

Manage upwards to ensure that management above the team is in the loop and able to help

Some ways you can do this are:

• Escalate team issues to your manager and seek out their guidance/advice. You should not try to always paint a positive picture of everything to management, this will shield issues that they can help with and make it look like you are not doing enough to get the team to improve.
• Ensure your manager, and any other relevant stakeholders, knows as early as possible when there are risks to missing commitments that the team has made.  The earlier risk is identified, the better action can be taken (maybe no action is taken but people won't be surprised/taken off guard when commitments are missed)
• Ensure that the manager of every developer on the team knows of that developers progress.  You should be able to give this manager a frank assessment of the developer. Don't try to shield them from their manager, if they are struggling their manager should be involved to try to help. 

Coding

You're probably not going to get a ton of dedicated time to write code. But still try to set aside time to write code and deliver functionality that the team is working on. If you go too long without writing much code you'll lose touch with what the developers on the team are going through. I recommend  that every lead take on at least one development task per work increment (like sprints).

However, it's probably best to not commit to delivering things that are extremely time sensitive, or could put things at risk if it slips a few days. Try to work on relatively independent pieces so if you are not able to get much time for several days it will not impact the team much.

Conclusion

Well, that's a lot to discuss. I hope you found this valuable, whether you are considering being a lead, you are a lead, or you are managing/leading leads yourself like me.  Writing this up and sharing it with my leads has really helped them to grow in to the role and become great leaders of their teams.  If you have any different ideas, or other types of lead responsibilities that you can think of, I'd love to hear it in comments!