Software developers who speak business language and project managers who speak engineering language are nice to have, hard to find, and… not a requirement. Managing technical projects without a technical background requires skills in interpersonal relationships, research, and communication.
As a project manager, here’s how I’ve conquered the fear of not knowing in a technical setting. With these skills, I lead software and product teams to stay true to our process and ship gold, one brick at a time.
Do Project Managers Need Technical Skills?
As I look around my Revelry PM team, we’re at half-and-half. Some of our product managers come from an engineering background, and the others come from a product background. Do technical skills afford the developers-turned-PMs a clear advantage in managing technical projects? After all, an inside-baseball knowledge of code lingo and jargon can help you communicate with the developers.
Then again, you’re nearly always going to be managing communication with an external product owner. And perhaps, a non-technical approach can help to see the issue from the point of view of the end user.
Managing Stress While Managing a Technical Project
So, here we face the dance of the digital producer: balancing the needs between the client and the team. A product manager must accurately and effectively communicate the product owner’s goals and priorities to the engineers. And, she’ll need to support and unblock questions and challenges that the engineers face during implementation.
Here’s the thing: it’s definitely a challenge to constantly hear terminology that’s outside your wheelhouse. It’s discouraging and frustrating to experience a feeling of not knowing, or to perceive a lack of control. And people from all disciplines will do their weakest work when they feel discouraged. This is especially debilitating when leading and managing a project team.
But you’ve got this. You’ve got sharp interpersonal skills, whether they’re instinctive or learned, and you can apply them in a technical setting. Here’s exactly how I’ve learned to be comfortable with unknowns and navigate technical conversations.
Reiterate What You Just Heard
It’s natural for technical teams to use shorthand for everyday terms and concepts. And if you’ve never heard the original term, let alone its abbreviation, this is confusing.
Don’t let impostor syndrome creep in. Don’t be afraid to be sure you know what’s being discussed. When there’s a pause in the conversation, I jump in and attempt to reiterate the gist of what I heard. If I haven’t correctly clarified the concept, someone will correct me, and I write it down.
If I don’t feel confident enough to even begin to summarize or reiterate, I’ll start in a different way. “Adam, could you please repeat or clarify what you said about [x word I heard but don’t recognize]?” This smoothly continues the conversation and allows everyone to hear the reiterated comment, so they can respond.
Re-read Written Communication
Whether it’s project conversation in Slack, or ticket updates in GitHub, a lot of our communication is typed. As a project manager, it’s important for me to catch up and re-read all project conversations. This is especially helpful to take in technical conversations at my own pace.
I don’t have to actively participate in technical conversations or debates, but typically there is an action item to record. The team discussing the technical concept may not have even realized the number of action items being brought up, and that’s why we have PMs.
When I’m re-reading and I hit something that confuses me, I type notes into a digital notebook. And then, I read the conversation a third time. This combination of writing and reading helps me digest the information, so I can pinpoint exactly what it is I’m unclear on.
Just Ask.
Once I’ve formulated my questions and/or I really just DO NOT KNOW what the heck something means, there are a lot of ways I can find the answer. I’ve mentioned how I can bring up the question immediately in a conversation. But if I’m catching up asynchronously, I’ll message or Zoom with a technical team member and ask for their definition. Then I write it down, since writing is how I learn – and then look up again for future reference.
Another way of asking is to straight up ask for the layman’s terms for a technical statement. This is also good practice for the engineers, since the ability to communicate a technical issue in non-technical terms is a great way to understand and grow within the discipline. A solid engineer can tie together the business goal with the technical implication, and be able to express it to various audiences.
Asking lots of questions is never, never, never a bad thing. Even “dumb” questions.
Pairing
Pairing isn’t just for coding. Pairing can happen between any two people who need to work together to solve a problem or get something done. The opportunity to utilize a tech lead sync or to grab any available developer is invaluable. I sometimes get blocked writing Acceptance Criteria for tickets, so I’ll find a pairing partner and work together to understand the problem.
This opens the conversation to allow for implementation considerations that I may not have been aware of. Sometimes I allow the developer to ramble a bit. This actually helps to get their thoughts out, so then I can organize their thoughts into BDD style format. We get the AC to a place where we all feel comfortable before assigning the client to review and approve.
Own Your Strengths
Part of being a PM and not a developer is that you are responsible for very different work than the developers. Since a PM is not in the codebase all day, they have the ability to zoom out on the project. Much like a coach who sees all the players on the field in order to call out plays from the sidelines, a PM who can zoom out is able to see the big picture of the product and the team.
Players on the field, as engineers in the codebase, appreciate being able to keep their head in the game. They can trust that someone will provide the guidance that keeps them on course.
Staying Awesome While Managing Technical Projects
No one likes wasting time by working on the wrong thing. The greatest gift a PM can give their technical project team is the room to do what they do best. This means that they don’t have to expend energy worrying what’s next or whether their work is aligned with the product owner’s goals and priorities. We create space for engineers to work on the technical details by making sure they know we’ve got their back.
So go forth and be awesome, non-technical project managers. Acknowledge that learning new things is hard, be patient with yourself, and trust that the technical team will give you the same courtesy. Together, we make each other better. It’s the Revelry way.
If you enjoyed this managing technical projects article, see more of my work here! Connect with me on LinkedIN.
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.