From Code to Command

Navigating the Transition from an Engineer to a Manager

Functionally different but perhaps fundamentally the same?

As an engineer, you've spent years developing your technical skills and becoming an expert in your craft. But what happens when you're ready for the next step and technology alone can no longer satisfy your desire to make an impact?

Generally, technology companies offer two career paths: becoming a Staff Engineer, deeply involved in coding to the point where you talk in C# in your sleep or becoming a Manager.

However, what tech companies fail to articulate is "how do you even become a manager?" and "what does management even do?". The inner cynic in a lot of developers will say something along the lines of "change their minds, fail, then pat themselves on the back" and honestly that's not too far from the truth.

My goal is to provide insight and share the lessons I learned on my journey from a lead developer to a manager and what makes a good leader.

Why do some engineers struggle to transition?

To explore this question, let's analyze typical developer characteristics using the classic engineering decision-making tool: a pros & cons table:

Pro's	Con's
Fast learners	Overconfidence
Makes data-driven decisions	Focused on hard skills
Problem focused	Under-communicative
Linear thinking	Perfectionist
Bias for action	Matrix-focused
Strong sense of ownership

I've listed more pros than cons, and that was an intentional decision. Why? Because that leads to my first insight.

Your greatest strengths are often your greatest weaknesses

Introspection is the key to growth

This pearl of wisdom was given to me by my Group Technical Director when I was leveling up my leadership qualities. I consistently received positive feedback about my bias for action and strong sense of ownership, however, these were also my greatest flaws. My bias for action caused me to leap before I look, which resulted in general ignorance of failure flags for projects because I was so linearly focused. And my strong sense of ownership led me to be reluctant to relinquish control and delegate.

However, some of Amazon's Leadership Principles are Bias for Action and Ownership. But just because it's a large tech company does that make them correct? Amazon is well known for its cut-throat culture and high employee burnout. Don't get me wrong, these are still positive traits for leaders, but I think there's more to this puzzle. The answer is simple.

Balanced leaders are successful ones

Too much of a good thing

Ignorance of the problems associated with personality traits causes people managers to become unqualified in how to manage the issues that arise from them. A leader who is heavily biased for action is likely to be narrow-minded and lacks the vision and awareness to make effective decisions. A leader that is heavily driven by ownership impedes growth in their teams as they drive a culture of high-alignment but low autonomy "Here is the problem and here is how we are going to fix it".

A culture with low autonomy and awareness often suffers from low morale and trust, the opposite environment of what a good leader should strive to build.

This is why a good leader must practice introspection, recognize their strengths and weaknesses, and constantly devise strategies to improve both. A well-rounded leader inspires through transparency, actively promotes self-improvement and fosters trust within their teams.

Practice transparency

Create clarity and reduce chaos

So what exactly is "inspiring through transparency" and why is that a characteristic of a well-rounded leader? Well, I will be exploring leadership transparency in a future blog post - but a short snippet is "transparency builds trust and trust fosters respect". By doing so, we can create a more diverse and inclusive work environment that promotes learning and personal growth, leading to happier, more productive, creative, and engaged team members.

Some ways you might practice transparency are:

• Explain and document your decisions. Invite and listen to feedback and engage insights from your Team Members.

• Build retrospections and post-mortems. Focus on what did we learn and what will we change?

• Share knowledge. The act of teaching others inspires others and improves your ability to learn and cultivate introspection.

• Be honest. Knowledge is not equivalent to value. An engineer's value isn't driven by the depth of their knowledge, it's driven by their willingness and ability to operate without it. When you don't know something, admit you don't know and then find out.

Wisdom is seeking and combining knowledge with perspective.

By operating transparently, you will inspire others to do the same and move you toward becoming a better leader.

Promote learning and Continuous Improvement

Healthy culture heals unhealthy process

Circling back to my point earlier, often engineers aren't holistically aware of what management does and often see them as "constantly failing and congratulating themselves" and I said this is true to an extent. So why do managers do this?

I would like to briefly reference this quote from Daniel Ek, founder of Spotify "We aim to make mistakes faster than anyone else". The Spotify engineering culture focuses on a fail-friendly culture because each failure is an opportunity to learn and improve. This is a unique one, and something that I am fond of, however, I think the key component of this is shared understanding.

In the example I gave at the start, if managers are so focused on continuous improvement and don't take the time to ensure staff is on the journey with them then that lack of understanding builds mistrust in their ability to make effective decisions. A manager is someone that directs whilst a leader is someone who inspires and motivates.

But how can such inspiration and motivation be built? Well the key to Spotify's success, in my opinion, is this line "Driven from below, Supported from above". A leader does not solve problems, they identify them and give their teams the support, trust, and tools to solve them (however they should occasionally roll up their sleeves and help out when needed). A team that can practice this autonomy can build a healthy cycle of continuous improvement, which in turn enables more autonomy.

Engineering Management is not just People Management

Leaders are built out of lateral and vertical influence

We've all seen those job postings, asking for 5+ years of experience as a manager for a junior management position. So what is happening here? Are Recruitment Managers so out of touch with reality? Well sometimes (for example this particularly hilarious one from Sebastián Ramírez), however, I think there's more to it. I think the term "management" has become synonymous with "people management" and "people management" has the inbuilt expectation of being a direct manager. But, a strong focus on matrixed hierarchies is not an indication of a good manager.

One undeniable trait of a good leader is their ability to influence others. Influence is not a matrix, it is by nature multi-directional. In the book "Influence Without Authority" the authors present the Cohen-Bradford model, a method of influencing without authoritarian structures. It involves a key understanding of human interaction, focused on understanding other people's situations, needs, and core values. This can be used for colleagues, stakeholders, and even your manager by anticipating their needs and "managing upwards". This method of influence is the key to successful people management and the main success driver in the ability of a leader to inspire others. Demonstrating this level of influence says more about a leader than "5 years of people management" ever will.

Engineering Management is not a science, it's a framework

Treat every person and situation as unique

One of the most important lessons is to not blindly follow. I'm sure you've seen fads come and go, and engineering management is not exempt from this. There is always radical thinking, experimentations, thoughts, and "best practices" - but it's important to not let these drive your decisions. Every one of these things has been driven by context, and context changes for every company, team, and team member. Keeping on top of these trends should only be to extend your understanding, not to drive your decision-making. Ultimately they should be a way to shape your unique perspective in your environment and make the most effective decision based on it.

What's next?

In future articles, I'm going to expand further on leadership transparency and strategies you can use to make effective decisions. But for now, I will leave you with this, think of engineering management the same way you think about software engineering. There are best practices, frameworks, libraries, and documentation that refine your knowledge, but they are only valuable when you take the time to assess their applicability to your unique product.

I want to hear from you, did you learn anything from these? What are your guiding principles towards engineering leadership? Please reach out or comment below.

Take Care

Ctrl + Leadership