Project management skills are transferable skills you can use in any domain or environment.
All of us have heard this, but I didn’t believe it until I realized the power of PM skills in two situations. The first one was in a software project I managed many years ago. More recently, I leveraged my project management practice in a new technical environment.
Based on my lessons learned, here are five main ingredients I’d like to share with you in terms of establishing your credibility in a new environment
I don’t have a developer background. When I was appointed, the team was skeptical. From the outset, I set the expectations: I said right away that I didn’t know much about software development. Talking openly about our limits is the cornerstone to forge trust among stakeholders.
The developers were experts. One of the sponsors tried to compete with them, asking tricky questions, challenging what they were saying. The developers interpreted it as a lack of trust—which it was, partly. He plummeted their engagement.
It’s not about foregoing a general understanding of what experts are doing. It’s about knowing where to put the bar. The time you will spend learning will translate to less time wasted down the line.
Take time to get to know the people you’ll work with—and remember what they told you. Taking a genuine interest in your team members will translate into stronger teamwork and better outcomes.
More importantly, think about creating spaces in your clogged calendar to self-reflect. What objectives would you like to achieve in the three coming months? It will help you to not go astray.
When you arrive in a new environment, you are also overwhelmed by names, faces, documents and information. I write down the information I get (including personal ones) to jog my memory when I need to.
When I revamped the delivery process in the new technical environment, I interviewed experts to understand the current state. I listened, I misunderstood, I asked again —that’s critical for understanding where the most important things lie.
In my former position, I trained newcomers. I was a reference on the team. In this new environment, I felt like a fresh graduate student with more ego. Thoughts of failure crawled in. It was not easy to accept. In hindsight, it was an incredible lesson in humility to push me to shift my mindset from “knowing it all” to learning.
Before being project manager, I contributed to different projects. In one of them, I hardly saw the project manager—and I didn’t understand how she managed it.
Drawing on this lesson learned, when I took over the project role on the software team, I explained how I worked, the way I communicated, what I knew (and didn’t know) and the frontiers of my role.
In both cases, I set up different communication threads:
A general email, like a newsletter every two weeks (a long email list with all stakeholders, including some top managers)
Dedicated project emails
Ad hoc conference calls (if needed)
Instant messaging groups
These also provided places where I could reward some team players for their contributions.
In the beginning, people didn’t see the value of these communications; I was accused of sending too many emails. But in the long run, it has held. It fostered team spirit