Domenic was very intelligent, precise, and had great success in his current job (as a chemical engineer). He was offered the chance to be a team leader, a position he wanted and where he felt he could contribute.
He accepted the role and was frustrated. He was frustrated because he spent hours per week in meetings where he had solutions to problems but no one was listening. He had the experience and the background, but he couldn’t get his voice heard.
Andrew ZeitounAndrew Zeitoun met Domenic one year later when he signed up to one of Andrew’s advanced training classes.
There are many experts and smart people out there, but no one listens to them. Why?
Some people lack credibility with their stakeholders. Others have a different focus, focusing on what is important to them and not what is important to their stakeholders.
Sometimes the credibility and focus are right. However, communication styles can hinder effective communication.
These are all challenges for those who want to transition from technical roles into leadership and project management roles.
Domenic. Andrew met him again and he revealed that Domenic had been successful in making his voice heard. He also said that he was promoted to team manager.
This is the power of communication and stakeholder engagement skills that are well-executed and know how to use.
Andrew leads a course on how to change your approach to lead teams and improve careers. Andrew is also a technical expert who teaches how to become a project manager and leader. It covers six transformations that you will need to make in order to make the jump.
Continue reading to learn how to go from subject matter expert to team leader. Spoiler alert: More technical skills are not the answer. It’s all about people.
Andrew, a key part of moving from technical expert into leader is knowing how you can position yourself with stakeholders. Can you give an example of a situation where this has been a problem?
Early in my IT management career, one of the most difficult lessons I learned about stakeholder engagement was when I was just starting out.
We had created a new infrastructure solution that connected our Beijing office to the Canadian headquarters. My boss, the divisional head of IT, wanted what we built. I didn’t realize that he wasn’t my primary stakeholder. My primary stakeholder was the managing Director of the Asia/Pacific Business Unit.
To make matters worse, the managing director kept pushing back, claiming that our solution was slow, unreliable, or didn’t meet his needs. I continued to deliver data that contradicted his claims.
No matter how technically sound the solution, I discovered that it doesn’t matter how good the solution is if your primary stakeholder doesn’t trust the solution or if users don’t use it.
I wish I could claim that I saved the project with my knowledge and expertise. Truth is, I didn’t. This project was saved by an accident. Some of the tools and techniques that we now teach to understand stakeholders and engage them saved the project.
What’s the best way to avoid situations like this?
Understanding your stakeholders is key.
You need to know a lot about your stakeholders. Understanding their communication preferences and how they measure success will help you establish a solid foundation.
You can then take concrete actions that reflect the views of your stakeholders and your project.
Stakeholder analysis doesn’t happen in a single, static way. It is a process that can be repeated and refined as you work on a project. You can also carry it over from one project to another.
