Leading with influence

How a software engineer learned to lead

“Leadership is influence — nothing more, nothing less.”

In the past couple of years, I’ve started taking on more of a leadership position within various technical teams. As I reflect upon this experience, I’d like to share what may help others on a similar journey.

I’ve never identified myself as a leader. I suspect most other developers in the tech industry don’t. Some combination of imposter syndrome (I did not have a CS background), my Chinese upbringing (which emphasizes obedience and filial piety), and popular stereotypes of leaders (as infallible and always correct) had put a distorted definition into my head. I had put the position of a leader/manager on a pedestal, someone to be viewed with admiration and not to be achieved by a mere lowly mortal such as myself.

With leadership feeling like an unachievable goal, I focused more on my technical abilities. However, no matter how good I understood a topic or how convinced I was that a particular technology would help us, when it came down to putting into practise within a company or team, I’d always inevitably hit some barrier - A colleague who ‘just doesn’t get it’, or a boss who wouldn’t let me even try.

It felt so frustrating, and I started to develop unhealthy habits to deal with the situation. Passive aggressive code review comments, or stealthily implementing a library before people caught on. These tactics sometimes gave me the results that I wanted, but most of the time would backfire, causing more fallout that had to be dealt with in an increasing hostile manner. It made me resent my colleagues, and think ‘if I was in charge, I’d do it differently”.

But even as I was employing these tactics, I felt there must be a better way; I could see others around me not afflicted with these types of failures.

There’s a famous quote by John Maxwell: “Leadership is influence — nothing more, nothing less”. I came across this whilst reading his book “360 Degree Leader”. I took it to mean that, no matter where you are hierarchically in an organisation, you could still lead by influencing others around you, whether it’s your manager, your peers, or your juniors. This quote unlocked a mental barrier that I had in my head.

The conundrum that I had in my mind was that whilst I would like to be a leader, I could never understand how one practises to become a leader. For technical skills, I could learn about a new skill/framework/idea, then practise through code katas, or personal projects until I was proficient at it before using it ‘in the real world’. My main concern was that if I used a technology or skill before I was comfortable with it, I could fail at a particular job and disappoint the people who were depending on me.

Leadership however, by definition, is a skill that requires you to interact with people. With my previous hierarchical definition of leadership, this meant that if I wanted to practise, I’d first have to be put in a position of power, and then my mistakes could actually hurt those underneath’s chances of doing their jobs and their careers — something which I’d seen happen in past jobs.

My new definition of leadership helped me see how I could practise my leadership skills in a low risk way, by influencing those around me. It helped me to see that, actually, I’d been practising already, whenever I convinced others to adopt a framework, or when I taught a junior something that I knew, or when I gave feedback to my team leads on what was a good idea or not.

As a consequence of this, these types of activities took on a new meaning for me. No longer did they seem like the drudgery in the way of productive coding work, I reframed the tasks to be opportunities to practise my leadership.

The new mindset helped me navigate a particular problem our team had been butting up against. At the time, the company wanted to modernise the look and feel of the product. There was internal disagreement about which approach we should take. Some preferred sticking to a server-side MVC framework (Our backend team used C#, so ASP.NET MVC was the preferred choice there), others wanted to use a client-side JS framework. It had been discussed a few times but no consensus formed. The lack of movement on the subject was starting to be felt by the product leadership.

The problem we had was not a lack of ability; The team had the skills to execute well on any solution. Rather, it was a lack of clear direction. Through my new definition of leadership, I could see that, although I was not in a position of leadership to decide for the team which direction we were going, I had the ability to clearly lay out what the options were.

I made a presentation that clearly laid out what our current architecture was, why it was deficient for what the product goals were, and what the available options we had considered are and how they solved it. I presented not just to the engineering group, but to other groups within the organisation. I did not try to gloss over the technical details, but did my best to explain it in a way that a lay person could understand. This helped build buy-in from the rest of the company, and restore some confidence within our team.

As a result of the presentation, we decided that going with a frontend framework would be the best decision for the company. Even better, the decision was arrived at with greater clarity and understanding for all people involved. Our teams could now move forward with greater confidence and direction.

I felt the same sense of accomplishment that I get when I solve a tough engineering problem. For the first time, it was my leadership abilities, not my technical abilities that had solved an issue. It gave me confidence that my mindset was in the right direction.

I started to actively seek out more and more of these tasks; I would start chairing meetings. I helped run a book club. I helped run a weekly coding lesson for new comers in the industry. Through some heavy pushing by a fellow colleague and mentor, I even ended up talking up on the Web Directions Code stage on ES6 Symbols (overcoming a personal fear of public speaking).

Eventually after a few years of doing this, the organisation started to recognise the skills I’d been demonstrating and gave me a few direct reports. By this point, I definitely felt a lot more confident in my ability to lead.

I see a lot of confident technical people around me not taking up the mantle of leadership, which I suspect has a similar root cause as mine. And I see how it causes them strife, because whilst they are right about the particular domain they specialise in, they never seem to be able to convince others of the ideas in their heads.

If you are in this position, I recommend “360 Degree Leader” by John Maxwell. It may help you see something new to leadership like I did.

Please share your thoughts with me. I’d love to hear them.