Can Non-technical Project Managers Become Solution Architects

To All Project Managers: How to Score with Technical People

Hackernoon is the author of a new article on people management. He is hoping to help PMs work more effectively with technical people (the "T"s in your organisation who are individual contributors who do not like managerial work, or trying to guess what people are thinking and navigating the political landscape. He has worked with some of the best PMs in the world and hence warrants me to at least talk about people management in this article. The best practices of good PMs became even more apparent to me only when I met someone who contrasted from them and committed these faux pas.

Zhi Long Tan Hacker Noon profile picture

My third article on hackernoon, and I thought that all my posts would be technical articles detailing my learnings on algorithms. However an experience with a bad PM made me put those other drafts aside, and write this one out in one sitting. I am hoping to help PMs work more effectively with technical people (the "T"s in your organisation who are individual contributors who do not like managerial work, excessive meetings, or trying to guess what people are thinking and navigating the political landscape).

I worked in a hybrid role for 4 years in a company which excels in project management, and (as a sweeping point), measures the employees by a main metric: Leadership. That company is P&G, where I have worked with the best project managers who were masters in planning, cutting down project timelines by parallelising work, excellent communicators with top notch influencing skills, and great people managers. My first manager told me that his main job was to make me shine. I grew rapidly as a result. I believe that I have worked with some of the best PMs in the world and hence I feel that experience warrants me to at least talk about people management.

Outside of the company, in another role and in another life, I had the chance to work with some shoddy PMs and I want to document the bad habits that I observed. The best practices of good PMs became even more apparent to me only when I met someone who contrasted from them and committed these faux pas. Here is the list.

Be humble.

If you are a PM without any formal reports (which is usually the case nowadays), and have to influence technical people to help you, bear in mind that you are seeking help from the technical folks for their skills to build something that you cannot execute as well or/and as fast as them. Hence it would go a long way to always be mindful of tone. Recognize that you need them for your scorecard to look good.

Don't tell the technical people how to do it.

If you are a PM with a slight technical background, chances are that when you want to solve a technical problem or build a tool, you would already have formed your own preconceptions on how you would execute the solution. I'll boldly say: Just keep in mind that 99.99% of the time your solution sucks. Either it's the wrong approach, or a totally inefficient solution so don't waste your time telling the technical people how you would do it, unless they ask for your approach on an example to check your thinking process. Else the technical people would just zone out or listen and nod politely. Some PMs try to talk about how they would execute the solution in an effort to impress, but you are just wasting time. It is OK not to know the solution. Technical people recognise that is it not your job to know. Just don't pretend.

Prioritise reusable effort if possible.

Technical people want to build something reusable, and not spend time and effort on solving a problem or building a tool which would only be used once. A truly useful tool or solution is something that has a multiplier effect; it is something which would attract other technical people to expand upon it because it is widely used or it makes a big impact. If you are asking technical folks to build a one-time tool or solution, go and re-think or re-prioritise how you can make the effort reusable. Else you would just be sending signals to everyone that you want the work to be done just because you have made the mistake of committing it to management, or that piece of work somehow pushes your personal tactical agenda and does not bring benefit to the bigger organisation as much as it does to you.

Always be clear on the objectives before meeting starts.

Technical people hate attending meetings. Technical people just want to lock down and build beautiful things. Don't drag a technical person into a meeting which is unnecessarily long and worst of all, try to figure out what you want only during said meeting. Figure out your objectives beforehand, set your message track to pass just enough useful information, and feed it to the technical folks in a smart way without needing to talk about the entire history or background of the project if you are not asked. Just talk about how the project is beneficial, objectives and help needed. Fast and boom. Whilst listening to you, their problem solving trait is already kicking in and a solution is already forming in their heads.

Don't be dismissive and underestimate the effort.

I have met a few PMs who tell the technical folks that they can do it themselves but they choose not to because they are too busy. I think this is common sense but if you say that as a PM frequently, you would not be in your role for very long. Also, don't stick too rigidly to the preconceived timelines that you have. Different technical people have different levels of abilities or capacities which might be due to other priorities at that point in time. Your job as PM is to earn respect, not just command it. Double check and respect the timeline estimation from the technical people unless you want bugs or shoddy work. Or unless you are Steve Jobs.

And surely do not mention you once "did a website from scratch 5 years ago" hence you know how to make a web app.

Be generous with giving credit.

As a leader your goal is not to shine, but to reflect in the glory of your team. If your team looks good, you look great. To have an eye for selecting talent, influencing them to help you, maximising their efficiency, then integrating their work so that your team produces the best work achievable, is a rare and valuable skill. Recognising and promoting your team's talent and skill is important because all technical people gravitate towards leaders who show appreciation of their work and skills and continually affirm that their work is making a difference. And think big. Be generous with developing people and provide and recommend the best environment for their growth, even if it means they would grow out of your team and become bigger than you. Their development and life is more important than your project. Nothing would ever stop people with high potential from being great one day, and you want to be the reason for their success.

Always end with giving a deadline.

I have been in many discussions with weak endings, and nothing gets done in the following weeks because deadlines are not clear and not given. Technical people need deadlines to work on problems because deadlines determine how deep and detailed they would go into producing the solution as well. Pure technical people can spend a lifetime on most problems, enjoying the discovery and problem solving process, or producing insights and building tools which far outstrip the original objective. Or maybe without a deadline they won't even start on it so that they would not fall into the rabbit-hole. Always give deadlines so technical people know what to do and when to do it.

Hope this helps.

Spafford Forrind