What did I learn as a software engineering manager
You are at the peak of your software engineering career.
Or at least that's what you thought at the time. You have done it all. New development, maintaining legacy applications, refactoring code, performance improvements, different kinds of database technologies, from proprietary to mainstream distributed systems. You have even tried your hand at web development and improved web app load times, things that as a backend engineer you never knew about! You are about to wonder what next to get yourself to the solutions architect or a software architect role. Then suddenly out of nowhere comes an opportunity to take on a managerial role.
You are a good engineer but you are not sure if you can be a good manager, after all, you have never managed anyone before. At school, you had been the leader of your class for several years. You had been the responsible kid that the teachers trusted, for reasons beyond your comprehension. You begin to wonder if all that added up to this additional responsibility of managing other people at your company. You begin to think, maybe you should give it a shot. You start listening to Eminem's Lose yourself: one shot, do not miss your chance to blow, this opportunity comes once in a lifetime yo. Those lyrics resonate in your head, several times, debating within, whether you should go for it or not.
What to expect?
Nothing prepares you for a job in middle management. Depending on your firm, there will be a level of authority that you could use to expedite change and improve the conditions at work for yourself and others, including your reports. There could be a level of autonomy to make crucial decisions that could change the way work is done at least within your team and maybe in teams of your immediate influence. There might even be a bit of free time on the side to explore what more can be done to improve efficiency and exceed all expectations.
The unseen and often unheard reality
Nobody told you that leading a team, means slowing down and waiting for everyone to catch-up. No one ever tells you that, it is your responsibility to ensure there is enough time for your team to train themselves. No one tells you that, just because you can move at 90mph, others might not or would not be keen to move at the same pace even if they can go faster. Nobody told you that if you wanted to focus on being a technical/enterprise architect, you should not jump into middle management too soon and lose opportunities to get your hands dirty in meaty technical projects, even though, some of the skills like excellent interpersonal skills are required for both. Noone told you that when you become a manager, your one job, and the most important job is to ensure that your reports are happy and motivated. Noone told you that your success is basically having your team motivated and productive to succeed as a whole.
How life was before management?
Up until the point you chose management, your world had only one person. You only cared about what you worked on and how you could solve the problem at hand and never cared about how others around you might need help. You only care about how you can shine not how your team can go forward and make an impact as a whole. You never thought about how you should share your code review comments in a way that empathises and understands why a person might have chosen to so a thing a certain way. You never gave it a second thought on why the legacy application is in a state that it is today. You never cared why you felt like all those developers who wrote code before you were idiots. You always failed to think about the bigger picture, the environment, the pressures, the context switches, the inefficiency in the flow of change requests
The wake up call
Management puts things into perspective.
If you are lucky enough to experience a cycle of it all, you will appreciate it every bit as much as I did.
A story from the life of an engineer turned manager:
The advent of a highly anticipated application that would change the world, the gradual rise in delivery pressure and deadlines that pushes engineers to the limits of corner cutting, the guilt in getting things done for the short term, in order to achieve the edge in the marketplace, leading to a lack of pride in ones accomplishments as none of it was done properly, although it works and achieves the desired outcome for the business. The application has soon become scary and untouchable among the development teams that shared the ownership of it and in a period of two years, the spaghetti has become so fragile that if you changed a line, you could spend a sprint, trying to understand why you broke this completely unrelated other module.
You, the manager in the middle-management position, then looks back and wonders, everyone you had in your team, was an excellent engineer, and had what was needed to get the job done right. What went wrong then?
When deadlines approach, engineers often focus on just making things work, rather than quality. A high pressure environment never really results in good quality software. Although quality can be improved in the long run, that effort to improve could also go south. As an engineering manager, one has to be pragmatic about this. Delivering value with reasonable code quality in the short term that you can improve in the longer term is always better than software that hasn't gone out to customers at all.
So what is the difference between management and leadership?
Management is about bringing order into chaos. It is about caring, empowering and rewarding. It is about making an environment where your engineers can perform at their best, without having to work extra hours. It is about understanding that the real reason why excellent engineers write bad code, is a frustrating, never-ending, unprioritised, flow of change-requests that cause extensive cognitive load and exhaustion that leads to the slow death of the most crucial element of software engineers: their ability to think and come up with creative pragmatic, maintainable solutions. That is what short-sighted, artificial deadlines do.
Management is engineering at a different level.
While software is engineered by people as a product or service for other people (mostly people), a manager is responsible for engineering the environment that makes their reports more productive and efficient.
There is a bit of science and humanities involved and that is why it is much harder than pure science. Because science is mostly facts and deductions/inferences from facts and evidence. However, humanities involves emotions and feelings that are subtle but more powerful and harder to get right. After all: One cannot improve what one cannot measure. And emotions are one of those things that cannot be quantified. Hence, requires intuition and empathy and patience to build that relationship with every report you have. To be in a position to have conversations in a way that every feedback leads to a positive response that helps your report to not only get better themselves but to also empower them to suggest feedback for yourself. To build a relationship where feedback goes both ways and is not taken as offensive, because you understand that what you are building is a mutually beneficial relationship that takes your team and organisation forward.
But I am an introvert, what do I do?
You like your computers, arts, books or games or whatever that keeps you content and engaged. You enjoy your solitude and in fact, get drained by talking and interacting with people. Making small-talk is painful and exhausting.
But think of it this way, no one has ever gotten better without getting out of their comfort zone. Management or leadership, in general, will stretch an introvert to the extrovert spectrum and will force you to make room for others in your life. It is a skill that is hard to perfect for introverts and extroverts alike but it will take you further, not only in your professional life, but also in your personal. As an ancient African proverb states: if you want to go fast, go alone; but if you want to go far, go together.
Management and leadership is about learning to influence people around you beyond just the authority you may or may not have. There are books that will teach you everything about leadership or management in general. There are degrees and MBAs about all things management and entrepreneurship. But if you do not practice and not know how to influence people by building relationships, no book or degree will help you get any further.
Why have I used management and leadership interchangeably in this post?
Quite often, a manager, is portrayed negatively as someone who does a lot of planning and organising. Let us clarify what they mean first.
- A manager, in simple terms, is one who controls, organizes, directs or handles.
- A leader, is one who leads or guides, or has command over others (this is the power of influence not necessarily authority)
A good manager is often a good leader. One who inspires the best out of others around them, one who sets an example, proactively takes action, responds to change and takes responsibility and ownership of the failings of the entire team/group. Strictly speaking, anyone can be a leader; they need not be in a position of power or authority. Although a lot of the qualities of a leader is desirable in a manager, there are some that managers need specifically. Yes, the admin is important, the communication skills, strategic decision making skills, organisation skills etc. This is why, you should not consider being a manager as a lowly or a negative job.
So what's the point?
Try it. If you feel, you are up for a challenge that's different from programming, take on a managerial role for a while, explore the part of you that rarely gets the limelight as a programmer. You might surprise yourself with what you could achieve and what you could withstand. You might even enjoy it a bit too much to return back to programming. I just shared what I went through.
Management was just one of the many responsibilities that I held in the past three years in the small firm that I work at the moment.
It was fun exploring it and comparing it with the managerial role I held previously at a much larger corporation, where processes were in place and roles and responsibilities were well defined. There was always time for thinking and self-development in the bigger firm, and I had a team of mostly experienced engineers, who needed very little technical help.
Comparing that to where I work now, there was a lot more pairing needed and hence much less time for strategic thinking and self-development. This is probably because a large chunk of the time in this role was spent in firefighting and dealing with critical production issues.
The other factor was, I did not have room to grow into, in my current organisation. Career progression as an engineering manager, was pretty much it. Unless, I stick around for several years, or the company suddenly decided to expand rapidly in the next year or suddenly we had to re-organise or restructure through some acquisition of sorts.
So I have temporarily moved away from management, till I see one that I like.
But every role is different, so you will never know until you step up to it.