linkedin Skip to Main Content
Just announced: CoderPad Play! Engage your team with fun technical challenges.
Back to blog

Making the Transition from Software Engineer to Software Engineering Manager

Engineering Management

Are you looking to move to a management role in a software engineering organization? For many engineers, it can seem like a daunting jump. But with the right preparation—and by knowing what to expect—you can make the transition as seamlessly as possible.

Naturally, there are many different reasons why senior developers or tech leads look to enter management roles.

Perhaps you’re more of a people person and feel ready to inspire others; maybe you have your eyes set on projects that can only be realized with the help of a larger team; it’s possible, too, that you’ve been in an environment with sub-par leadership and you’re ready to step up and do things the right way.

It’s also important to remember that, in the end, nothing is set in stone. Many of the best technical leaders oscillate between roles on the team and as a leader of the team in what has become known as the engineer/manager pendulum. By understanding the finer points of software development and being able to navigate the priorities of various decision-makers, a software manager can support teams to do their best work.

Get the facts straight and take an inside look at how you can make the move to become an engineering manager with this guide.

Traits of an effective manager

As you’ve probably seen over the course of your career as a software engineer or technical team member, management is itself a distinct skill. No matter your technical acumen, managing a software team takes a calculated approach—one centered on making sure developers can thrive.

It’s also key to note that the same skillset that made you successful as an individual contributor or senior engineer doesn’t always carry over to the management side. For instance, while autonomy and burning the midnight oil to take on last-minute fixes on a tight deadline might serve you well as an IC, a manager should be more focused on allocating resources and delegating efficiently. We’ll cover a few more of these differences later.

When gathering a base of knowledge on what it takes to lead the right way, it’s worth turning to the experts. Peter Drucker, one of the most influential management strategists of the twentieth century, summed up the habits of effective executives as such: “They get the right things done.” 

Seems simple enough, right? Not exactly. With constantly competing priorities, evolving requirements, and the minutiae of bugs holding up developers’ progress on your watch, the decision of what really needs to be done in a given moment isn’t always clear. 

In order to reach a point where decision-making becomes second nature, Drucker’s analysis points out other habits that include:

  • Building on peoples’ strengths
  • Choosing the correct priorities
  • Understanding the results you’re expected to deliver
  • Continuously improving how time is managed

What separates managers and individual contributors?

So, how exactly do your responsibilities differ as a manager compared to an individual contributor?

Perhaps the biggest (and most obvious) change will be the move from writing code yourself to empowering a team to do it instead. While some skills from your background as a developer will come in handy—for instance, attention to detail during a code review—you’ll need to deploy them in different ways. 

As a manager, it’s crucial to measure overall progress against a roadmap that could span a year, not just the next two sprints. You might also spend your time early on identifying delivery metrics for bottlenecks, such as code churn or time to merge. 

Because leading a team of coders requires a holistic view and a longer-term orientation, it also means spending more time managing schedules, sending emails, and making sure the relevant parties in the engineering and product organization are kept in sync. You will communicate with a variety of stakeholders across departments, from project managers and owners to marketing heads. That means you may also need to act as a chameleon, adjusting your tone depending on the audience.

Speaking of keeping things in sync, one of your primary responsibilities as a software development manager is establishing cadence. A team’s cadence is crucial because it operates as the framework for pacing out work and helps to set routines. With the right cadence, when bugs or unexpected events occur, developers can focus on individual fixes without losing track of the roadmap. 

A team’s cadence also encompasses the frequency of meetings and 1-on-1s, and it’s up to you to set the precedent for meaningful communication. It takes a great deal of planning to strike the balance between uninterrupted time ‘in the zone’ for developers and a cohesive team dynamic.

Another key distinction between ICs and managers involves the types of metrics used to evaluate progress. 

As a software development manager, you should assess performance using both quantitative and qualitative criteria. Though you may be more accustomed to quantitative metrics from your time as a developer, a team’s long-term success also hinges on things like worker satisfaction, cultivating a sense of belonging, and providing opportunities for upskilling.

Tools to measure quantitative performance and set new milestones, such as RACIs, are still needed, but getting qualitative results involves handling the intangibles. You should plan carefully, observe, and iterate in order to match the right personnel to the right projects. It’s also crucial to step in when a team member is struggling and pair them with more senior engineers who can provide support and aid in their growth.

Understanding how to spend your time as a manager

On any given day, there’s a surplus of possible tasks. How, then, can you best approach Drucker’s principle of getting the right things done? Here’s a breakdown of how your time as a manager is likely to be spent

  • Managing: conducting team meetings, 1-on-1s, and taking time to mentor (30%)
  • Monitoring: assessing the team’s delivery metrics as well as individual performance (15%)
  • Hiring: setting up best practices for interviews and interviewing candidates yourself. In terms of recruiting, your efforts might extend to attending conferences or drafting blog posts (15%) 
  • Planning and Communicating: serving as a point of contact and communicating up with senior managers and down to the team. You’ll also spend time gathering resources and conducting joint planning for long-term goals with the Product team (25%)
  • Developing: where technical work is concerned, the time you spend writing code or conducting code reviews will, of course, decline the more senior the role.  (15%)

Preparing to make the move

If you’re still deciding if moving from a senior engineering position to a managerial position is right for you, here’s the good news: You can find opportunities to test out the water beforehand.

There are numerous informal ways you can begin to understand the types of responsibilities a software director needs to take on while still acting as a senior engineer or tech lead yourself. A few preliminary steps might include:

  • Taking on more leadership responsibilities within your team and existing projects. This might mean stepping up to help onboard new developers or taking it upon yourself to define a team’s unique delivery metrics
  • Playing a more active role in the hiring process by participating in interviews and providing feedback that can refine best practices
  • Sitting in on meetings with cross-functional team and different stakeholders, such as product owners and managers or even customers. This can further help you to understand the soft skills it takes to operate between technical and non-technical environments

Remember, the job of a manager and developer are both about problem-solving (even if the problems themselves are different). Therefore, in addition to explicitly stating your intention to move toward management, you can become a force multiplier in your current position. 

Demonstrating your ability to craft software architecture that is scalable and reliable, providing prompt code reviews, and leading conversations that drive technical decisions are all useful litmus tests for what lies ahead in management. Lastly, you can always move up the ladder at your current company and take on a different leadership role before making a more drastic transition.

What to expect in your first 90 days as a manager

Like all other skills, managing effectively takes time. Unlike working as an individual contributor, though, the bulk of your learning as a leader comes through engaging with and understanding the people around you.

That’s why, from the outset, it’s essential that you build and inspire confidence. As mentioned, you need to establish a cadence before making progress; early on, that means collecting as much feedback as possible about work pace, how individuals understand requirements, and more. One-on-ones are crucial during this period to both familiarize yourself with the team and get a sense of each individual’s capabilities.

Among direct reports, you should strive for clear communication and open feedback channels. Fostering the trust this requires can be a process in and of itself, and it begins with transparency. In order for your ICs to get the clearest idea of your expectations, you should explain who you report results to, tell them about your past experiences and technical proficiency, and make sure they see that constraints and roadblocks are an accepted part of the process.

One of the most common mistakes of first-time managers is trying to take on too many tasks.  You’re surrounded by talented developers for a reason. Get comfortable delegating responsibility and do your best to cultivate a sense of shared accountability; this way, sustainable progress will be more attainable and you won’t be playing catch-up while learning the ropes yourself. Outside of the technical team, you also need to hit the ground running in terms of familiarizing yourself with a broad set of stakeholders to avoid chasms between your technical team and the rest of the organization.

Lastly, in what can be a whirlwind time during the early days of management, you should still dedicate time to learning. From reading up on what works and doesn’t from other leaders to connecting with mentors, being intentional about improvement can send positive ripples to direct reports and higher-ups alike. 

Are you ready to forge a new path from day one as a manager? Get ahead by reviewing ways to optimize technical interviews and get the perspective of industry veterans across our blog