Home // Posts
I am a Software Engineer, not a Manager. This is the story I tell myself on a regular basis since being promoted to a Delivery Management role. Now, after more than one year in this role, it is time to reflect on my journey so far. To share my experience from the perspective of a reluctant leader.
As a software engineer, if asked what characteristics my ideal leader have, I would conclude that the leader know my job well enough that they could empathise with me, understanding the difficulties of my role. They could then use this understanding to advocate for me with the rest of the organisation.
Given the characteristics I described in The Ideal Leader, it would be logical to conclude that the best leader for a Software Engineer was previously a Software Engineer. They can empathise effectively because they could do their job if required. The problem I have experienced with this conclusion is that a Software Engineer when becoming a leader, wants now to be both a Software Engineer, and a leader. I have found that these two roles form an unavoidable dichotomy. As such, for a Software Engineer to become a leader of Software Engineers, they need to take a step back from the skill-set that likely got them noticed in the first place.
Yes, but not for everyone. From a remuneration and responsibility perspective, it definitely opens up the opportunity for increases in both. As a technical leader, I have more autonomy to define a technical direction for my teams work, within the context of the organisations strategic direction. Being able to make technical decisions, then seem the success or failure of these decisions is a humbling, but rewarding process. In the following section What are a Technical Leaders Responsibilities?, I will attempt to summarise my current responsibilities to provide context for subsequent sections where I will further explain why I am a reluctant leader.
Technical leadership will look different for each organmisation and kind of technical leader. The following is based on my current responsibilities only.
As a technical leader, it is your responsibility to lead the process of making technical decisions that will define the constraints within which your team will operate. Some decisions you will make on your own, but this is rare. You will need to bring together experts from your team, and across the organisation to make decisions. Decisions that you will then need to own and advocate for. You will need on one hand, to look to the horizon to identify threats and opportunities in the future, while on the other hand, look inwards to the current state of your technical infrastructure to ensure it continues to provide an effective platform for your team to operate within.
Not all technical leaders manage people, but when you are, you have the privilege and responsibility to provide guidance on personal development and career direction. Your decisions begin to have a real impact, both positive and negative on the lives of your people and their families. You will need to lead their performance evaluations, and provide timely guidance if they are falling behind expectations. Expectations that you will find are partly your responsibility to define and refine over time. Depending on the status of your team, you may be called upon to participate in the recruiting processes to grow your team.
As a technical leader, you may be called upon to support the workflow of the team. This might include looking after the issue tracker workflow, or running sprint ceremonies. Depending on when you are a technical leader, you might be responsible for supporting a move from in person to hybrid, or fully remote working environment. If your team is not working effectively, it may be your responsibility to change that.
As a technical leader, you are likely already fully loaded with responsibilities before even considering participating in the software engineering process day to day. I would argue that its cricial you do so, and that your leaders make it clear that it is a requirement for your position. This could manifest as code reviews, bug or security fixes, or new feature development. It is critical that you be careful not to become a blocker in the critical path of your team, as your time will be limited and not evenly distributed.
Before coming to a conclusion on why I am a reluctant leader, it is important to emphasise that you may not need to be a leader to lead. I have learned from my career so far that individuals within an organisation with manager or leader in their job title, are not always the most influential force on why a specific decision is made. Peer employees in many instances can have more sway regarding the direction of a decision. A developer with the ability and willingness to teach gains significant influence over technical direction as they are seen to be an authority on a topic.
I am a reluctant leader because I am passionate about software engineering and see the necessary change of focus needed to be successful as a technical leader to move me too far away from what makes me excited to get up in the morning. I hope that other developers continue to try out leadership positions as it is incredibly important that software engineers continue to have a seat at the table for important business critical decisions, but at this stage in my career, I need to take a different approach to leading.
As I have mentioned, being a leader is only one way to lead, and I endeavour to continue pursuing alternative avenues for influencing technical direction by always sharing the knowledge that I learn, as that is what the most influential leaders in the software engineering field have done for me.