This article is targeted for those individuals that are transitioning from software engineer positions into dev manager (people manager) positions or a role that may be a hybrid of the two, such as some “tech lead” positions.
A software developer has the primary responsibility of developing new software features and maintaining existing software. The day-to-day activities involve: software requirements, design, and test reviews (see SDLC); writing code; and collaborating on technical solutions. This person has a maker’s schedule.
A manager, including “people manager” or “engineering manager”, has the primary responsibility of making sure that a team of individuals operates efficiently and achieves the company objectives. The day-to-day activities involve: determining team objectives, delegating work from the product team to the appropriate development engineers, design and code reviews, and aiding team member growth. This person has a manager’s schedule.
|Software Design (SDLC) & Architecture||Helping team members grow|
|Collaborating with other technical individuals (e.g., QA reviews)||Achieve team and company goals/objectives|
|Writing Code||design and code reviews|
The transition from a software developer to a manager is not a directly vertical career movement. Being a good software developer does not make you a good manager, and similarly being a good manager does not make you a good software developer. They are different skill sets, and to effectively manage, you will exercise new skills.
Let’s look at one way to prioritize being an engineering manager/tech lead.
1) Help People Grow
As a company, your greatest asset is high quality people. As a manager, your greatest responsibility is helping the individuals on your team to grow. Helping people to learn more, work together better, and operate more efficiently helps support the team and company objectives.
Some managers attempt to review or sometimes redo what individual team members create, but in helping them to learn how to develop the best, you can accomplish significantly more. By helping 3 people to perform their best on their own, you accomplish way more than you can if you have 3 people do most of the work and then 1 manager making changes.
Some ways to help your team grow and improve as individuals and thus improve the quality of their work product would be through individual or team trainings on the following:
- Technical trainings, i.e., learning new things about a programming language or technology
- Soft skills trying, i.e., improving how to communicate or to handle project management.
- Project or organizational skills training, i.e., how to communicate to other teams on the status of a project
For example, imagine a developer that is technically very proficient but does not communicate well with the Product or QA teams. You may often end up in situations where the developer understands a feature, but may not have implemented to product specification or the rest of the organization may not fully understand the implementation. Helping that person improve their communication or even project-management skills would help that person’s individual growth and the organization overall.
2) Team Prioritization
At multiple companies that I’ve worked at, we have used Atlassian Jira for software development project management. Jira is a great tool if customized appropriately, but it may not be best directly out of the box.
Who Should Do What
As a manager, you want to work with the product team to understand which work to prioritize and figure out who on your team should do that work. You need to have some dashboard view to see the current workload across your team and understand which developers are working on which features. Some developers may have better understanding for certain features (e.g. the product’s authentication scheme) or technologies (e.g. regular expression). To complement that though, some developers may happen to have more availability than others at a given moment in time. It’s your job as a manager to figure out who can (1) take on the work, or (2) who can learn the skills from others to handle a certain piece of work. It’s also important to not delegate work that may be significantly above a certain individual’s skillset.
There are multiple ways to measure (and estimate) productivity. Agile methodology using story points is one of the more common methods. Regardless of method, you need some way to track (1) your team’s current progress individually, and (2) a way to forecast future progress. You should know the team’s productivity overall and also per-person. While it can be good to have public visibility across the team into every person’s productivity, such as through a team dashboard, the goal should always be some kind of positive feedback and never negative criticism.
We’ll talk about this further below, but for now, just know that technical reviews such as code reviews often fall into the process after measuring productivity and before forecasting.
Analyze & Forecast
Once you have a system for tracking the productivity of your team, you should know week-over-week or sprint-over-sprint what the average productivity will be per team member and for the team overall. You may know that one person handles on average so many story points per sprint. You can work with the product team to estimate out the upcoming sprints based on forecasting these productivity numbers.
3) Communicate Expectations
No matter what you decide to prioritize and how you expect work to be done, you need to clearly and in writing communicate expectations to your team members. You want the people on your team to know what you expect them to accomplish and how quickly you expect them to accomplish things. Less is also more, so if you can clearly identify goals with 3 to 5 objectives, it is easier to remember and reinforce objectives.
You need to regularly review progress on things currently in flight and things that have been accomplished in the past. Accountability is important, and tracking progress is about holding the individual accountable for previous goals.
Praise publicly, and criticize privately. For any praise on successful accomplishments, let the individual as well as the team celebrate the accomplishment. Any criticism should be constructive in nature and should be delivered privately.
Here are some examples of potential methods for these sections. You can mix and match between columns or use all.
|Identify Goals||Track Progress||Give Feedback|
|Dev tickets in a sprint or release||Jira dashboard for individual and team burndown||Slack post or email for team or individuals celebrating release accomplishment|
|Quarterly objectives–communicated on a shared document||Dev retrospective meeting or weekly team meetings (review team dashboard)||Weekly team meetings (celebrate wins)|
|Daily expectations (e.g., work hours, remote work) communicated over email||Daily standups over Slack or phone||Manager-direct report 1:1 sync meetings|
There are many resources on becoming a good manager, but there’s a lot to consider for software developers specifically. The transition from software developer to manager is not solely a vertical career move but really involves a career transition from maker to manager. The skills required to be a good manager are different than those required to be a good developer, and the transition process requires learning and honing new skills. If you have to keep just one thing in mind, remember that as a developer you develop code, but as a manager you develop people.