Engineer to Engineering Manager

Being a Software Engineer is a well-documented experience.

There are many videos and guides on how to learn, implement, apply and succeed in this field but one area that isn’t covered so well is the transitional stage from Senior/Lead Engineer to Engineering Manager.

Because of this, many people either don’t want to do it, see it as something forced upon them, or they outright fail at the task.

I believe I am and was a good Engineering Manager so I believe that It’s important that I share my thoughts as well as the framework I developed to help me deal with cross-collaboration and the all-important buy-in.

---

The Transitional Landscape

Without teaching you to suck eggs it’s important to establish the difference between an Individual Contributor (IC) and an Engineering Manager (EM).

Role Breakdown

An IC will typically operate in an individual capacity and pre-defined tasks set for them by the EM, team leads, tech lead etc (this varies significantly depending on where you operate).

The exact role of an EM can vary drastically so I’ll just cover my experience. My role as an EM was defined by 2 main elements:

• People Management

Now this can cover everything from hiring, onboarding, performance reviews and the overall care and wellbeing of team members.

• Product Management

We of course have Product Owners and Product Managers who handle the higher-level pieces of the product puzzle, but in my cases, I have been the one in charge of taking those lofty goals and working with my leads to break them down into digestible chunks and spreading them logically amongst sprints or other forms of deliverable timelines.

New Skills

Taking these two drastically different sets of responsibilities, the potential upskilling can be a shock for people new to the role.

• Daily Responsibilities

An obvious yet jarring change when it happens to you. You’ve now gone from having a nice board with tickets to pick up or be assigned for you to being the one who knocks, which is freeing for some and destructive for others. There is a well-known concept of “Maker Time vs Manager Time” which is what you, as a manager, should be striving for.

The majority of your efforts day to day should be spent ensuring that your team can stay as uninterrupted and focused as possible, something we will touch on more in the Aggressive Collaboration topic.

• New Skill Requirements

A very unspoken skill that I fear most people won’t learn or understand until they fail publically is the awareness that you can calculate all communication.

What do I mean by this?

Let’s say, as an IC, someone in the team Slack asks a question about an upcoming on-call requirements meeting, would you think twice about posting a response? probably not.

However, this can go very wrong when you’re in a position of authority. If you post a knee-jerk response such as “Oh don’t worry about it, it’s nothing” but then it turns out to be something, there will be some resentment towards you. If you post back “I heard we’re all getting put on-call over Christmas” that’s going to make them stressed and on edge until the on-call meeting of over.

I learnt this after I was made to look foolish by a more senior manager who would always delay their response until they had an accurate and information-backed answer to whatever was asked, an answer which 50% of the time was far better and even far more accurate than my rapid-fire response.

Context shifting is also something you will do consistently, regardless of how well time-boxed your day is. You can time-box and pre-plan all you want but you cannot influence the behaviour of others, your team will need you and the CTO will invite you to a last-minute call to discuss sprint deliverables.

Mindset Changes

When you become an Engineering Manager, ego simply has no place, and this is something that I failed very hard at.

1. The team can operate without you

This is something that 90% of new managers simply won’t be able to comprehend. This will come in two forms:

“My team won’t know what’s going on if I’m not there to tell them”

Or equally as bad

“If my team operate just fine without me, then why do I even exist? Am I redundant?”

Both are horrifically toxic mindsets to have with the latter one being something I was deathly afraid of when my daughter was born. I had just hired a new team, I had a very capable and mature 3-person team and was hiring for more, as soon as the third team member started my beautiful daughter was born and I was on Paternity for 2 months.

I attended every daily standup for the first 1.5 months.

Yes, you read that right.

I was so afraid that I would be seen as redundant that I attended standups on paternity leave, when as a matter of fact, I had hired such a competent and autonomous team, and I had already put the groundwork in with product and design, that we already had a full roadmap of work to complete and the team had the systems in place to carry this out.

You’re not redundant because your team can operate without you, you’re a good manager, and a manager is a force multiplier.

2. Your failure, their success

This mindset is not a requirement but I believe you are the captain of your ship and you should go down with it when something goes wrong.

An important trait of a good manager is someone who tirelessly advocates for their team and this can come very simply in the form of what words you use when explaining successes and failures.

Instead of “We completed X” use “They completed X”.

Instead of “They didn’t deliver all the sprint tasks” try “I didn’t plan effectively enough and over-scoped the sprint”.

It’s not about you anymore, it’s about your engineers, it’s about advocating for them, it’s about retaining them and promoting them and making them into the best possible versions of themselves, and sometimes that can mean you have to take the brunt of the failures and pass off all the success to them.

---

Preparing for the Shift

I believe it’s almost impossible to move from being an Engineer at Company A to being an Engineering Manager at Company B. The risk is far too high for a company to hire a first-time external manager.

This means the best chance of being an Engineering Manager (and the way I did it) is via an internal pivot.

But this means that you need to put the work in to prove that you can make the transition, and there are a few small changes that you can make that will demonstrate that you’re capable of taking on a management role.

• Leadership and People Management

Leadership and Management are not the same, but a manager ultimately needs to be both, fortunately, both of these are something that a Senior/Lead Engineer can do and provide evidence of doing well.

• Project and Time Management

As an EM, I would rotate and delegate responsibilities to my engineers every sprint, and I did this with intent.

Every sprint a different Engineer would take an hour or two out of their week to sit with me and go through the next sprint’s requirements, breaking them down and estimating time and resources. Being able to do this effectively is a must and I’m very confident that if you asked your manager if you could assist with the scoping down of tasks, they would say yes.

• Communication and Conflict Resolution.

When I think about my best engineers, and constant amongst them all was their ability to communicate effectively across varying departments and seniority levels.

In a similar vein to the scoping down of sprints, I would also rotate through Engineers to join me on end-of-sprint demos to the CTO and CEO. This would not only get the Engineers used to talking in front of the top of the company but would also put them on the CTO and CEO’s radar, something that is important when it comes to fighting for their promotion or pay rise (remember team advocacy).

---

Aggressive Collaboration Framework (ACF)

For those that don’t know, and apologies to those who do, I served 12 years in the Army, which is something that deserves its own article as it is, however, during those 12 years one very important yet unfortunate truth sticks to my brain.

The loudest, and most confident voice is the one that is heard.

You don’t have to believe me, but just think about it. Look around you. Look at those you follow on X.

Not everyone is capable of becoming that, and nor should you want to. To combat this, I wrote the ACF, which is applied correctly should cut through the noise with pure data and unquestionable ideas.

When dealing with Founders, Heads of departments and Directors, it’s extremely easy for them to just say “no.” to any ideas that take them more than 5 minutes to understand. This is where ACF comes in.

1. Thorough Research

Dig deep.

In an earlier section, I spoke about calculated communication, and this first step is exactly that. Spend some time researching what you’re proposing, discover and potential drawbacks or counterpoints that can be made, you’re going to need them.

2. Clear Value Proposition

“Ok, so what problem does this solve?”

“Urm, it looks…good?”

Get out. Not good enough. Try again.

You have to understand what drives the people you’re communicating with. Is it the North Star (the ultimate goal of the company i.e. be the best social media app on the market)? Is it increasing user retention? Active Users?

What is it?

Once you know what it is you have to pitch your proposal with that in mind. As soon as you start to link your ideas to their goals you’re in the door. “I believe that feature X can greatly increase our active user count, and potentially even hit all-time highs due to XYZ”

3. Build Relationships

A very important saying in the Army was “there are no friends in crypto”, i.e. dealing with cryptographic material, or more importantly, not being charged for the loss of cryptographic material far outweighed any loyalty to friends.

The same goes for business relationships to a degree.

Let’s do a small exercise. I want you to think about which department in your company causes you the most issues, is it HR? Is it Design? Product? I’m sure you can think of someone specific.

Well, guess what, being a manager is a game heavily coated in politics and corporate bureaucracy so it’s time for you to go and make some friends! As an EM I also made a conscious effort to get into the good side of the Design team as I would typically find myself at the mercy of designs being complete before I could assign features to the team. Another benefit to this relationship is if the feature was not too complex, I would advocate (there it is again) for the team to be allowed to design it themselves.

4. Preemptive Problem Solving

Remember that deep dive you did earlier into the problem that your feature will solve? Time to prove it.

This is by far the most important stage of ACF as this is when the CTO or whoever will be very much on the fence and can be swayed by what you say next.

Trust me, if they can catch you out with a potential issue you didn’t think about, it’s over, however, if they hit you with 4 problems that you’ve already thought of then you’re likely on the home straight.

5. Visual Aids and Prototypes

This is an important point that can be extracted from the ACF and used all the time, in most situations.

At a company all hands a few years ago, I was tasked with demonstrating a large feature that my team had implemented in the past few sprints. I was going to be demonstrating on a non-prod environment and something about it didn’t sit right with me.

I had a feeling that something would go wrong when using this environment, so I did a dry run of the feature and took screenshots of everything working, from every possible angle and I put it into a slide deck.

Funnily enough, the demo environment failed before I had a chance to demonstrate anything. So I stood in front of over 200 people on a Google Meet call, all staring at me and waiting awkwardly.

I dragged my slide deck into view with a title slide saying “If you’re reading this, the environment has failed me”.

Crushed it.

Always have visuals to back up your pitch.

6. Confident Communication

You’ve done all the work, you’ve done a deep dive, you have a deck prepared, nothing and no one can question your judgement, but now you have to communicate your ideas effectively.

Show passion, take your time, and keep the language simple and to the point. An incredible pitch can be ruined by a lacklustre-luster delivery but a poorly written pitch can be salvaged by a confident speaker. So aim for the best of both.

7. Collaboration and Adaptation

Regardless of the result, our systems are forever in a state of iteration and improvement.

Take feedback, implement it, and hit back stronger.

Collaboration paves the road for alignment.

---

If this article can help at least one person then I’ll be happy.