The Challenges of Management
Want it or dread it, sometimes as developers we move from individual contributor to a team lead or management type of role. This is a drastic shift in skills needed and one frequently done without official training. How do we improve our chances of success when others are on the line?
Congratulations, you've become a manager (or are wanting to)! Your responsibilities no longer just include code and product stewardship. Now you're responsible for managing one or more developers, helping them grow, giving them a safety net to prevent failure from spreading into the product, representing the business to them, relaying their concerns to the business, monitoring their morale, and ensuring they remain productive contributors to the team.
Easy, right? Oh, and you can't rely on breakpoints and stack traces anymore to debug issues. Plus, unlike your programs, they remember prior interactions, so watch what you say.
It sounds intimidating, and it is a big responsibility, but it's also one of the most rewarding things I have ever taken on in my life. Management is not for everyone, but for those who care about developing both code and people, it's completely worth it.
I don't pretend to know everything. I spent 3 years at the junior or mid-level developer level, 8 years as a senior developer, 2 years as a lead developer, and I have only 1 year thus far as a manager, but those long years as a senior dev gave me time to get ready to manage and learn that I wanted to. As such, I want to share what I've learned early on in my management journey.
Getting Ready to Manage
If you have just become a manager or are preparing for the prospect of management, there are some things you can do to get ready.
Embrace any opportunity to mentor and train junior team members in an any capacity
Read books on managing software engineers. I recommend Managing Humans, The Manager's Path, Managing the Unmanageable, and Debugging Teams among others.
Sit down and think about every manager you have ever worked with. Write down what you liked about their approaches and what you didn't. As a manager you should become a customized version of yourself mixed with everything that worked and avoiding everything that didn't work that you've encountered. You will continue to grow as you find what does and does not work for you, but always strive to fail in different ways than your predecessors.
Talk with a mentor either inside of your company or outside of it. Let them know you're wanting to prepare to become a team lead or manager and ask for advice on getting ready.
Practice giving honest feedback. I'm not saying be a jerk, but you need to practice telling people what you think in as respectful and constructive way possible.
Seek out unofficial leadership opportunities such as leading a project from a technical perspective. This will get you practice and give you an opportunity to see if management is something that you would be good at or interested in without official management responsibilities.
Learn to embrace interruptions. As developers we often try to get into the zone in technical problems and architectures, but as a team lead or manager, you're going to be the person people come to with questions and ideas and you need to welcome this as a core aspect of your own job.
Practice reviewing code. You're going to see some... questionable stuff over the course of your career and you need to learn how to give feedback on design mistakes, find edge cases, and spot cases where business logic isn't correct. Giving constructive feedback that is well received is going to be a key aspect of your job as a technical manager and one of the best ways to grow your team's skills. See my article on code review for some more advice on this topic.
Round out your technical skills. People are going to go to you when they encounter roadblocks they can't overcome themselves. While you don't have to be the best developer on the team, you want to be confident in what you do and know where people can go to find answers. Additionally, I believe increasing your technical comfort level helps fight impostor syndrome that can commonly beset new managers.
These steps should help you get ready for management. But what do you do once you're managing?
How to Effectively Manage
Once you are managing, there are some things you can and should do to help your team succeed and to generally not suck as a manager.
Meet regularly with your team members one on one. I recommend anywhere from once every two weeks to once a month. This is a big deal as you want to keep a pulse on your team, continue to connect at an individual level, and listen to what concerns are on their mind. This is your employee's meeting and they should drive the agenda, but I always like to ask how someone is doing, if they have any concerns, and check-in on yearly goals every meeting.
Speaking of goals, help your team members craft meaningful yearly goals for themselves. This should be done even if your organization doesn't officially use an objective-based key results (OKRs) / SMART goals style of approach as it forces your team members to think strategically. I always like to encourage a goal related to building a team member's technical or soft skills as well as goals directly related to business and department goals.
Give regular feedback. Whether or not you are responsible for yearly reviews (some lead developers are not), you should regularly give people feedback on how they're doing - both good and bad. Be specific and be timely. Nobody likes to be told how they messed up on something that they did a month ago or more. A firm rule I strive for is that nobody should be surprised by something negative on an official review that was never brought up before.
Don't be surprised that part of your job is helping people learn how to function in a business environment, particularly with younger developers. You're going to have to have some awkward conversations sometimes on things anywhere from start times to hygiene to appropriate workplace conversation topics to use of company time and resources. Expect these conversations and handle them with tact and respect, but clearly set expectations.
Regularly evaluate where your team is from a skills perspective and look for ways to improve those skills. This could be anything from holding regular internal training meetings (I hold official training meetings once a month for my team) to recommending training videos on Pluralsight, YouTube, Insperity, or other services. You are responsible for both evaluating their skills and challenging them to grow more.
Give people assignments that will encourage their growth. While not all managers are responsible for assigning work (I manage in a matrix organization where the work assignments come from an individual's agile team, but I manage members of my technology group), you can advocate for your team members and work to give them opportunities to grow in areas they need to.
Allow your team members to fail. People only have an opportunity to succeed to the same extent that they can fail. If you keep a junior developer so tightly on a leash that they have no opportunities to significantly fail, they also will not have significant room to hit the metaphorical ball out of the park. People grow from failure and success and both are important.
Provide a safety net so that individual failures damage things as little as possible. This can be ensuring the QA department is aware of the full extent of the changes from a developer or limiting access to business critical areas of an application until team members prove themselves in less sensitive areas.
Care about these people. Really. Your work matters because the people matter. It's going to suck to write people up, see people leave, or even have to terminate someone, but you need to care about your team and strive for making them the best possible versions of themselves. Plus, people can tell if you don't really care.
Be honest with upper management. Your job is to represent the team to the organization and to represent the organization to the team. You don't do that by painting a picture that isn't completely accurate. You shouldn't enumerate every success and every failure, but you should be honest in everything you do and you should recognize the contributions that senior management provides to the organization as well as the challenges they deal with.
Act as a bridge between your team and upper management. That's not to say that you should prevent them from talking to upper management, but you need to help the team understand where the organization is coming from and help the organization understand what issues the team is dealing with and what concerns are on their mind.
Check in frequently with your team. Just walk by or send a slack message. Encourage people to stop in and bounce ideas off of you. It keeps people connected and it also helps catch people going down the wrong path early on.
Involve your boss. Continue to get mentored and training. Bounce difficult conversations or things that go poorly off of her and get feedback and advice. Your boss should be a mentor to you in this transition. If they can't, find someone in the organization who can - your team needs the best version of you available.
Ultimately, you're going to love management or you're not. It's not for everyone, but if it's for you, you can amplify the impact you have for the organization and give other humans a healthy and productive place to work.
One of my favorite recent memories involved a day where I was taking a metaphorical machete to our codebase, introducing mocking and inversion of control and generally improving the architecture and testability of the code. That wasn't the highlight of my day, however. The highlight of the day was 10 minutes with a junior team member who was upset about a miscommunication with human resources and working with both sides to smooth things over and ensure concerns were understood. While I made the code better that day, my work in keeping a team member happy and productive may have had a more lasting and profound impact.
Hopefully this article is helpful to you as a manager or potential manager. While this is not comprehensive, these are some of the ways you can succeed (or at least not fail) as a manager. Please let me know what ways you have found to "suck less" as a manager.
Top comments (2)
Do you miss being hands to keyboard? I think I would be frustrated not being able to go in and help pair program or directly make changes. Maybe that’s something you still have the freedom to do!
I’m in a senior software engineer position so my day to day is mostly hands to keyboard work with some mentoring and design, but my career path will always be hands to keyboard until I move into more software design / architectural positions. In other words, I’ll never have to sacrifice being away from the purely technical work for career progression - there will always be a path for me to code or architect systems without hitting a salary ceiling.
So, I'm part of what's effectively a matrix organization running 3 agile teams. I'm the technology group manager for .NET and JavaScript / TypeScript development so those devs report to me regardless of which agile team they're on. I'm also an individual contributor on one agile team and responsible directly for a series of services.
My allocation is balanced to roughly 40% coding, 25% meetings, and the rest for misc. strategic, team management, analysis, planning, etc. types of work. I get to wear a lot of hats as a line manager who also contributes directly, and frankly, I love them all.
I'm doing well in my role and at some point might move further away from coding, but at the moment I get to code plenty, and a lot of the tasks coming my way are more strategic and architecture-oriented, which is a sweet spot for me.
My thinking is that as my coding time decreases, the things that will shift into its place are very worthwhile and still interesting to me and I can always code in the evenings and weekends for fun and continual learning. I don't see a place where I don't code, but I see paths where I don't code as my core output at work. Already my yearly evaluation is not on my output, but on my team's output and performance, and that's what it should be.
Even if I no longer coded, I would still want to be involved in code review and regularly review the state of the codebase.
I'm glad you have that path available to go technical or management. I am a firm believer that organizations need to reward engineers not with promotion to people management, but with paths on the architecture and technical leadership level as many, many, many engineers are not wired to be good managers.
See archive.is/Jx5wn for an illustration of such a ladder, though I would advocate that that CTO should be a management-oriented role and the CTO box on that diagram should be replaced with something like "Chief Architect"