As a software engineer, I really enjoy creating applications and solving complex technical problems. But some years ago, there it suddenly was: I was no longer only a “do-er” but an “oversee-er” as well. At that point I had received very little formal managerial training, so learning on the job or from mentors was crucial to be successful. The soft skills I needed for my new role turned out to be more difficult than I initially thought. One of those difficult soft skills for me was (and often still is) the ability to influence people. Influencing others is not just about getting them to agree with your point of view or manipulating them to get your way, nor does it involve forcing others to change by using power and control. It’s about noticing what motivates others and using that knowledge to leverage performance and positive results.
Taking up the technical team lead role is not always an easy one. Often the skills necessary to be a great developer don’t translate easily to the role of a technical team lead. In this post, I will give some tips on how to be an influential technical team lead.
Have a clear vision
A vision is a clear image of how you see the future. It’s something that keeps you motivated and excited to do what you do. A technical team lead must be able to both zoom in and zoom out on a project. On one hand, you need to be able to look in detail into a technical requirement. On the other hand, you also need to keep the bigger picture in mind and how the requirement fits into the greater vision. If you’re a technical team lead that has no vision and isn’t going anywhere, then how can you expect your team will follow you? In order to create a vision you can ask yourself questions like ”What do you want to achieve?, “Which (tangible) output do you want when achieving your goal?”, “How would that output change the way things are done now?”, … Setting specific goals together with your team that move towards your vision will help you to achieve it.
Once you have that vision and goals, being predictable is key. By doing so, everybody knows what you’re trying to achieve. The Don’t-Repeat-Yourself principle, which is a key principle for each software engineer, does not apply when working with people. Communicate your vision and goals over and over again: repetition and predictability are key.
Be collaborative
A top-down approach where nobody has a say in the process and where both vision and goals are pushed downwards, is very easy for team members to reject. A different and more sustainable approach is to be a collaborative technical team lead. This means that you regularly seek out a diversity of opinions and ideas amongst teammates to solve problems. Involve your team in creating a shared vision, and identify the behaviours necessary to accomplish it. It’s all about getting the team to think through these difficulties themselves instead of telling them what to do all the time. As a result they are more engaged, feel trusted, and are more likely to take ownership of their work. Building meaningful relationships is one of the key responsibilities of a technical team lead.
Practice active listening
We often think about influence as being what we say or how we say it, but improving your listening skills is key to gaining your team’s trust and creating psychological safety. As technical team leads we’re often pulled in many directions throughout the day. The most common pitfall is that we listen to reply, not to understand. It’s easy to be a passive listener by multitasking and only listening to the highlights. While it may seem like you don’t have time, making the time to really listen to your team can increase your leadership capacity significantly. Active listening is the ability to focus completely on your team, understand their message, comprehend the information and respond thoughtfully in a relevant way. This also includes not only capturing the message, but paying attention to subtle hints and non-verbal communication such as tone, emphasis, facial expressions and body language. Keep in mind that a true servant leader only speaks about 20 to 30% of the time, the rest should be spent on listening.
When your team members know that they will be heard, they are more likely to openly share their ideas and provide honest feedback. Knowing how and when to gather knowledge of your team members is important, since you can then synthesize it into a better solution before deciding the course forward.
Influence others
At a basic level, influence is about compliance. It is about getting someone to do what you want them to do, it allows you to get things done and achieve desired outcomes. However, this can never be accomplished by power and control, but only by genuine commitment of other people.
This simplified diagram is based on “The theory of planned behaviour” by Icek Ajzen, a social psychologist and professor emeritus at the University of Massachusetts Amherst. His theory assumes that before every Behaviour, there is an Intention.
A simple practical example: you notice a specific behaviour from a software engineer on your team, namely that he/she refuses to write unit tests. As a technical team lead, you are interested in why he/she formed the intention not to write these unit tests because you’re convinced that unit tests have a variety of benefits such as improving of code quality, finding bugs early and facilitating change.
There are three elements that can help us trying to understand why your colleague formed this intention:
- Attitude a.k.a “Is the behaviour good and is it right?”: We’re deciding if the behaviour is in our own best interest or if it is the right thing to do. So if we have a positive attitude towards the behaviour, it is more likely that we will perform the behaviour.
- Subjective norm a.k.a “What’s everyone else doing?”: We’re asking ourselves what others think of the behaviour and how they judge it. If we think that others consider the behaviour to be normal or good, it is more likely that we will perform the behaviour.
- Perceived behavioural control a.k.a “Can I do it?”: When we believe that behaviour is easy to perform, we are more likely to perform the behaviour.
So when you’re asking the software engineer on your team to write unit tests, the three elements listed above will cross his mind and he/she will ask himself questions like: “Is it a good thing to write unit tests?”, “Is it in my own interest to write unit tests?”, “Does everyone write unit tests or is it just me?”, “Do I know how to write unit tests and do I have enough information/time to write them?”, … Targeting each and every one of these elements is the key to success when you want your colleague to start writing unit tests.
So what can you do to influence the other person’s thinking?
- “Is the behaviour good and is it right?”: Identify what the other person cares about, what he/she thinks is good and what he/she thinks is the right thing to do. For example, your colleague might think it’s super important to finish his user story as quickly as possible. The key thing to do here as a technical team lead is not to be manipulative or dishonest, but to genuinely align your goals with his motivations and things he/she already cares about. Writing unit tests facilitates change, provides documentation, and ultimately saves time.
- “What’s everyone else doing?”: You can present that writing unit tests is an industry standard and not some kind of crazy idea you’ve just come up with. Presenting it as a good practice and being able to demonstrate why other successful teams or companies do it, is a good way to help your colleague see that what you’re asking him to do is normal in the industry.
- “Can I do it?”: If your colleague thinks it is too difficult, he/she will never start writing unit tests. Therefore, present it as a clear and small change, and make it easy for him to do. Offer your support and show examples of good and successful unit tests so he/she gains confidence and knows he/she can do it.
“The key to successful leadership is influence, not authority.” – Ken Blanchard
