Members Area
E2W Connecting Women in Financial Services Men For Inclusion
Open Menu

Women in Financial Services Blog

E2W coach Elizabeth ONeill - “People aren’t computers, but…”

E2W coach Elizabeth ONeill - “People aren’t computers, but…”

Katie.Dix / 26 Nov 2019

E2W coaching partner Elizabeth ONeill

"After nearly 20 years of building and leading technical teams and organisational change, I know that people are the key to success."

I remember my very first job like it was yesterday. I worked on Saturdays in the local sweet shop and I loved it. That was until a new guy started as a supervisor who was a total dick. Sorry, there's no other word for it. You know the type that thinks a badge and a title give him the right to order everyone around and be obnoxious.

After about two months I left. Although I loved the job, I couldn't work for this manager. I'm not proud of it, but on my last day I spat in his tea and smiled as I watched him drink it. My only defence is that I was very young. However, this experience has stood me in good stead my whole career.

As a manager or leader, you have the most significant impact on how engaged and fulfilled the people around you are. We've all experienced managers who have a detrimental and destructive impact. The reality is that people don't leave bad companies or bad jobs, they leave bad managers and bad teams.

Given that each of us has an impact of between 30% and 50% on how engaged the people around us are and that employee engagement is at an all-time low, we have to do something different.

Too many technical people are promoted into management positions because they are great with technology and they are then not given the support or development required for their new role. This causes devastating results for the individual and the ripple effects through the team and department are far-reaching.

I believe that you (yes, you reading this) have the potential to be a great leader and a positive impact on the teams you work with.

I know this for two reasons:

1) Leadership is a skill everyone can learn

2) You already know the method to learn these skills, because you have used it to become the fantastic technical geniuses you are

However, be under no illusion. Being a leader is hard and it's thankless most of the time. When you get it right, no-one notices. But, when you get it wrong, boy does everyone bitch at you.

Leadership is not a position. Leadership is attitude and action. It is about consistency, not big or grand gestures once or twice a year. It's about showing up every day. It's about the little things you do every day. It's about consistently saying and doing the right thing, even what you don't want to. Add team dynamics to this – quirky personalities because, after all, we are talking about technical teams – and it can seem impossible some days.

However, as I said, you have transferable skills that you learned from your years of working with technology that can be applied to improve your leadership skills.

And I am going to give you three examples to prove it. 

1) People aren't computers, but when you learned about computers, you invested time in learning and practising your skills. Being a leader is the same

There is a reason that, on an aeroplane, you are told to put your oxygen mask on first before helping others. This is not a selfish act; you can't help others develop if you don't develop yourself.

Working with people and understanding them can be learned using precisely the same steps you used to learn your current technical craft.

Step 1: We all started by doing. The best way to learning anything is to actually start. You didn't learn your technical skills by just looking at a computer, you had to do something.  Leadership is the same. You have to start actually doing something. You have to interact with people. You can't just rock up to work tomorrow and say “Hey, I'm a leader”. It will be your actions that determine this, not your words.

Step 2: When you started, it was with the fundamentals. For the coders, that’s usually “hello world”. For the hardware guys, it is usually building a home PC. In a leadership context, this means building trust, putting the team first, collaborating and showing your team that you care. These fundamentals will take you a very long way where people are concerned and will build the foundations.

Step 3: Once you had the basics mastered, you started to look at what others were doing. That may have been looking at code snippets or how others had tuned their server to improve disk I/O. You would have taken what others had done and tweaked it your needs and your environment. Leadership is the same. There's a lot of information out there; read it and then tinker with it so it fits your team, your company and, most importantly, your style. There is no one-size-fits-all, take the bits you like and make them your own.

Step 4: At some point in your journey to the technical genius you are today, you ask the people around you with more experience for help. Guess what, leadership is the same. Find a leader you admire and ask for help or advice. Find a mentor or coach to help you get there quicker.

Finally, Step 5: You got really good at debugging not just your mistakes but other peoples’. From a leadership point of view, this translates to the fact that you and others will mess-up even when you've tried your hardest. Apologise when you're wrong, fix it and learn from it. None of us are perfect, and people are a lot more forgiving than computers. 

2) People aren't computers, but the principles of good code management still apply

The practices you follow when managing code directly translate to the practices of being a great leader. Here are three examples to illustrate my point:

1) Commit early and commit often – We all know this. It's a universally agreed fundamental of code management. From a people point of view, this translates to making small check-ins as often as possible with people. Stop by their desk, say hello, ask what people are working on, ask questions, make the tea. These things make a difference. Remember, leadership is about consistency.

2) Don't commit half-done work – We have all broken the build by checking in half-done work. From a leadership point of view, I should have really put this one first as it's the most important. It translates to don't do half a job, don't be half-arsed about it. 

If you are only doing what you're doing to tick a box on some ‘how to be a great leader’ checklist, please take my advice and don't bother. Your team will smell the BS a mile off and it will do more harm than good. You will come across as unauthentic, which is one of the worst things you can do in my book as a leader.

3) Write valuable check-in comments – We've all seen check-in comments like “fixed a bug”, “sorted a typo” or, my personal favourite, “done some stuff or something else beginning with S”. These are completely useless to anyone else. From a people point of view, this point is exactly the same. Make sure that what you are communicating is useful and valuable to the team. Please, please, please stay away from corporate management speak and abstract terms. No-one knows or cares what “credibly strategising the interoperability of meta-services on a hybrid shared and tier architecture” is and, to be honest, you will sound like a complete...I'll let you fill in the blank.

3) People aren't computers, but, like computers, getting the syntax correct is vital

In this context, I don't mean grammar. I mean how you structure your communication.

Like computers and programming languages, each person has a way of accepting and deciphering information that works best for them.

So in the same way that you learned where to put the curly brackets and semicolons to make the program compile or configure a firewall correctly. The same applies to people. For example:

  • Some people are big picture and some are detailed
  • Some value stability and some love change
  • Some are cautious, and some are risk takers

Understanding each person's preference will help you get the syntax correct and enable you to communicate better with them.

So, in summary, if you can learn to program, you can learn to be a great technical leader. If, after reading this, you think you or your team would benefit from more support and guidance, please contact Katie to connect us. 

 

I really like this article     


Back to blog