3 Important Things I Learned as I Transitioned to Software Development Management

Published in

Loopio Tech

10 min readJul 26, 2023

After three years as a Senior Software Developer, I recently moved into a Management role — and couldn’t be more excited to share my experience as a new manager. I prepared myself for this role ahead of my promotion but even then, in the short time that I’ve been a manager, I have come to appreciate some finer details of this role.

In this blog post, I’m going to highlight some of my biggest learnings and challenges of this transition to help guide anyone questioning whether they want to make the switch for themselves; perhaps you’ve already decided you want to become a manager and these learnings will help you prepare for what’s ahead of the transition.

Silhouette of a person at a crossroads — Image generated by Dall-E

But first, a little bit about me!

Learning by example

I have been working in the software development field for over 10 years now. I started as a web designer and after a quick 15-day PHP boot camp (PHP is a programming language that is very popular for web development), I landed my first freelance gig where I designed and implemented a website from scratch. “This is fun”, I thought! It was 2010, and we were still in love with the parallax effect. I found a jQuery plugin that made the background move in different directions as our mouse pointer navigated through different sections of the page. Now, that’s value! My client will definitely sell more because of this neat effect. Turns out nobody noticed the parallax effect except me, but it was still pretty awesome to see my first website come to life and be used by real people and help a business grow.

I had a ton of fun designing and implementing websites as a freelancer and eventually decided to join the market as a full time software developer. I applied to several jobs and landed one at a small SaaS company in Brazil. There, I learned about Agile software development, Test Driven Design (TDD), Model-View-Controller (MVC) Architecture, The SOLID principles, Unified Modeling Language (UML) and so many other concepts that are important to build high-quality software.

My first manager taught me a lot. He told me this nugget of wisdom: “Code is just a solution to a problem. We should carefully think about the problem we’re trying to solve, and the solution to this problem, before writing any code.”

Looking back on my career, I realize now that I took that advice to heart because it provides a powerful perspective and starting point. It just stuck and became part of how I work.

Code is the solution to a problem. Before writing code, have I carefully considered what exactly is the problem I’m trying to solve? Or am I just changing stuff and hoping for the best?

Now I realize that as a manager, you do really get to have that sort of impact on other people’s careers, even though it might initially go unnoticed. Though it changed how I worked, I didn’t recall where I got that idea — until I recently passed it along to another developer. 10 years later, I see the impact my first manager had on how I work.

Before we dive in, a big caveat to this post: I’m only 8 months in as a manager. I still feel I’m fairly new at this — nevertheless, I think my experience with the transition is worth sharing.

The first learning: motivations matter!

When contemplating a move into management, it’s important to understand your motivations. While some common reasons include increased pay, influence, or recognition, it’s essential to dig deeper.

Why I say this: while it may sound like moving into management is the one and only, the natural career progression for software developers — especially those that have strong soft skills — many high-growth companies (like Loopio 😎) offer ample opportunities to grow and reach high-paying levels comparable to C-level positions. Therefore a management position may not be the only option you have. You might be more fulfilled and get similar pay staying as an individual contributor (IC), and that is completely fine.

Here are some common motivations for seeking a promotion, including moving into management:

I want to get better pay
I want to level up my career (I want to see my growth acknowledged)
I want to have a greater impact on my team and organization
I want a change of pace and to learn new skills
I want to work more closely with people

After my short time as a manager, though, I can see that there were different motivations I should have considered. Splitting these into two separate buckets will help highlight an important point: software development management really is a different career track altogether.

If we split the motivations by “generic” promotion motivations and “specific” motivations and re-evaluate the motivations through these lenses, the generic ones will be checked for most promotions anyways:

Generic Motivations:

I want to get better pay
I want to level up my career (I want to see my growth acknowledged)
I want a change of pace and to learn new skills

Specific Motivations:

I want to have a greater impact on my team and organization
I want a change of pace and to learn new skills
I want to work closely with people
I want to help people grow
I want to help decide broader initiatives outside of the scope of my team

I considered my motivations for some time. Do I have enough impact on the organization in my current role? Can I have a greater impact if I move into management? I thought so! After reflecting for some time, I realized my greater motivation was to have a bigger impact in the organization by overseeing the team’s initiatives and practices as well as collaborating on initiatives outside the scope of my team.

So perhaps, if you’re looking into moving into management purely as a response to boredom or a desire for higher pay — be prepared that the road ahead will be tough, especially if you’re not interested in the more ambiguous tasks involved on the day-to-day of a manager.

The second learning: change happens fast; how you react and adapt to change is key to your success

I started managing one team with three reports (the team I have worked on previously), which seemed like it was going to be an easy enough transition. I thought I could take my time to learn and do great things with this team — enable them to ship important Search features out, solidify our process even more, etc.

Three months into my tenure as a newly minted manager, I was pulled in to be the manager of a second team, quadrupling the number of my direct reports. Though I knew it was going to be challenging, and trying to not show any signs of panic, I took the opportunity with an open heart.

The learning: the management position will come with the added benefit of having a lot more insight into the backstage company decisions, and you may not ever be fully ready for everything that happens. Adapting to new situations is going to be key to your success.

My new team also welcomed me with open minds — they were really open during our Transition 1:1 calls and shared their career goals, aspirations, strengths and areas they wanted to improve on.

In a growing company like Loopio, it is best to understand that things will change fast. Things happen and things will continue to happen that impact your team — talent leaving, acquisitions and mergers, strategy pivots — and you may have little say on that. The key to highlight: you do have an influence on the outcomes.

Managing a second team — a team that already exists — is a totally different thing than managing the team you worked on. You’re suddenly the manager of people you haven’t worked closely with before, you lack context on their initiatives and their process. You’ll have to evaluate their performances, salary increases, growth and career progression, and more, so finding the time to understand the context of the team is really important.

It has now been eight months into the transition and I still have a lot to learn about my second team. Acknowledging your weaknesses (even the lack of context you may have on your team’s work) is really important — you can only address problems after you identify them.

I started doing 1:1s regularly with all my reports and tried to create a solid relationship with them, aiming to understand from a high level what are their motivations, goals and aims and what are the biggest challenges they experience on their day-to-day.

The sooner you can create a strong relationship with your reports, the better — a relationship of trust and safety where they can share their likes, dislikes, struggles and challenges.

It takes courage, but only when you and your report feel comfortable talking about the tough problems they’re going through you can really help them find fulfillment and put in their best work.

The third learning: there’s a LOT more ambiguity than you’d expect

I used to think I was a good software developer; a great software developer at times. I often got positive feedback on my skills — both technical and soft skills. Looking back on my day-to-day as an individual contributor, I kind of miss the feeling of getting my pull requests (PRs) merged, moving tickets around, and finding and addressing bugs. It used to give me a very specific feeling that I’m getting s**t done.

Of course, there is ambiguity in the software development world as a non-manager — should I have implemented this in a different way? Faster? Should I have written simpler code? Added an abstraction layer? You will often get that feedback from your team as part of your day-to-day.

The reality of a manager’s day-to-day though, is that since you’re not on the front lines anymore, writing, reviewing and merging code, it will be harder to assess your impact.

Some of my day-to-day tasks involve:

Communicating with external stakeholders,
Managing cross-team projects
Ensuring the team is set up for success (which projects are we tackling, which skills does the team have, what are the timelines for delivery)
Ensuring people are set up for success: Are they happy? Does their work matter to them? Are they burning out or being under-challenged — perhaps both at the same time?
Helping the team see the big picture and how their work impacts company goals
Ensuring the team has healthy software development practices and can actually deliver value
Surfacing organization issues; ensure there’s a plan to tackle it
Communicating leadership decisions to your reports
A lot more planning, hiring, onboarding, off boarding, etc

There is a common element in the above: more ambiguity, especially when it comes to managing people. Like in real relationships, it may take months before you’re able to finally break the ice with that one person in your team, or really uncover what was bothering that one report, or even see the light at the end of the tunnel for a given project.

Truth be told, with experience comes maturity, and with maturity, you will be able to operate better in high ambiguity scenarios. So even though I was a pretty good software developer and was able to fix most of the issues that arrived at me, as a manager, I simply have to get exposed to more problems, more ambiguity, and different situations — and always pair those challenges with retrospectives of what were the learnings, what are the takeaways, how can I improve how I tackle these situations the next time they arrive.

On tackling ambiguity: Take the time to digest what are the problems you’re facing. Pay attention to your automatic reaction to these situations. Sometimes, when a challenging or ambiguous project comes in, the best response from a manager may be very different from an individual contributor (IC). While an IC may start problem solving; as a manager, I found that I had more success when I step back and start to create a plan on how to address the issue, versus trying to solve the issue on the spot.

And now, for the bonus learning:

Repeat it three times: It’s okay to not know everything

As a new manager, I think I made this mistake too often; especially when talking to my new reports on 1:1s. Eager to show that I am fit for the role, and perhaps, based on my own software developer imposter syndrome, I tried immediately answering questions that were sent my way. This could have led me to be confusing sometimes or offer unclear or incomplete answers. I don’t know everything after all, and that expectation was solely in my head. Coming clean on my 1:1s and saying “I don’t know” opened a brand new path, to “I don’t know — let’s figure it out together”, or “I don’t know — what do you think should be the next step to create a solution?”

Once I started to see things like that — my reports’ questions being purely questions they wanted to figure out, instead of questions I should have pre-emptively figured out, my 1:1s started to flow better.

When I moved to management, I learned the hard truth: a lot of the skills you relied on to be a great software developer do not transfer fully into management. While some skills such as time management and context switching are transferable, others require development. Quick context switching becomes crucial as you juggle multiple projects, teams, and stakeholders. Coaching becomes a core skill as you guide and empower your team members. Strategic thinking and decision-making take centre stage as you contribute to the overall direction of projects and initiatives. Self-management becomes vital as you balance your own workload and responsibilities. I still remember that as a new software developer, I used to crunch development tutorials. I used to take many courses, watch youtube videos, and read books — so why should it be different when moving into management? To summarize: Plan ahead and put the time and effort into learning these new skills. It gets better over time.

Though the transition may be tough, it can be very rewarding when you see your team deliver high impact features, mature and improve their processes, when you see a member flourish and collaborate on cross-team initiatives, and so much more!

Checking your motivations and skills is paramount, so be prepared for a challenge and put time into preparing and learning — by reading books, taking online courses, or perhaps finding a Mentor!

On studying: here are some resources I found helpful. I hope they’ll be as helpful to you as they were to me. All the best with your own journey!

Books

Newsletters/Articles

Courses

Educative.io (paid): Become an Effective Software Engineering Manager
LeadDev courses: Skills for new managers

If you’re interested in joining us, check out the career opportunities available across Loopio’s Engineering, Product, and Design teams.