[NOTE: Throughout this article, I'll use "PM" as a generic catch-all for "non-technical person who manages programmers". A PM could be a Project M...
For further actions, you may consider blocking this person and/or reporting abuse
For any project that is quite sizeable the PM should always have basic IT knowledge. You would not ask a plumber to supervise the assembly of a computer...
Any dev should report to a PM that have technical and business understandings. That pm should then maybe answer to a more business focused pm if needed for bigger projects but having a pm that understands what you are doing will save time, money, miscommunications and other issues.
Very nice read otherwise.
Amen.
Lovely article, most definitely agree with what you're saying as I've had very similar experiences throughout my career. Right now, I am in the fortunate position of having a non-technical PM who takes the time to understand why a problem is a problem and will take my feedback to the client (and include in me in the meeting where necessary) instead of just insisting we do it the client's way.
Just wanted to comment on "this is the way the client wants it, so this is the way we'll do it".
It reminds me of that meme of the four people pushing a cube along with one person pushing a ball and the caption reads "work smarter, not harder". In this analogy, we'd rather push the ball, not the cube because it's much easier right?
The problem is, what if the client has a cube sized hole they are trying to fill and you thought you knew better by giving them ball - which was really only easier for you but not what the client wanted or needed.
Understanding should go both ways and before I shoot down a client's idea, I first try to understand what they are trying achieve before proposing a better solution. That way, I tend to get much further with the client (and my PM) than if I spend a lot of time explaining why their idea is bad or problematic.
In the analogy above, I might propose that we make a ball much larger than the cube sized hole the client is trying to fill and once we have pushed the ball to where it needs to be, we cut it into the right size cube and fit it. That solution works better for everyone.
The client tends to go along a lot easier when they can see I'm trying solve their problem, not my problem and more often than not, I end up solving both of our problems.
Absolutely agree on all points! And I suppose this is some of what frustrates me about those times when someone (the PM, or anyone else for that matter) foists the client's dictates upon me without giving me a chance to have an intelligent conversation about what is truly desired and how we can get there. If I know we're trying to achieve X, and the client asked for something that doesn't seem geared toward X, I can then explain better options that might get us closer to the client's goal and make the process more sane for the dev team. But if I'm locked out of the goal-defining process, and I'm just told, "Do this thing, because the client wants us to do the thing," it's very difficult to provide any sort of intelligent input.
100%. As I like to put it, don't tell me how you think the problem should be solved, tell me the problem. Solving it is what I'm here for. I learned that back when I was doing tech support, and it applies to so many areas -- including, in keeping with your other post, medicine.
As a former PM currently turning dev, I couldn’t agree more with this article.
As I grew into my PM role I made so many embarrassing mistakes because I lacked technical knowledge. I was lucky to work in orgs that didn’t give PM’s direct reports though and had tremendously helpful technical peers and managers that lifted me up to their level. I was always willing to admit my ignorance when making suggestions though and offered my respect to the experts without issue. That went a long way to prevent miscommunications and mismanagement.
Great read, thanks!
I'll also point out that a technical PM need not even be a developer, necessarily. I've had some PMs who were from an engineering background. They still understand the process and mindset of a developer fairly well, and they are usually confident and experienced enough to not fear when the technical aspects are over their head. They know when to trust their developers and back them up to management, but they can also grasp enough of what's happening technically to keep up and know when to pull in a senior dev or lead dev for planning. Experienced engineers also often make excellent liaisons between technical and non-technical people, just because of the nature of traditional engineering.
BTW, are you familiar with the idea of the "tact filter"? The (very short) article has been around for a couple decades now, but it's still pretty accurate -- though I can't say his explanation for why people have different types of filters is right (or wrong):
mit.edu/~jcb/tact.html
I hadn't seen that tact filter idea, but it makes a ton of sense to me.
I'm a product manager coming from an engineering background. In small companies, I often have devs reporting to me, even though I don't write code anymore. So I have extensive experience in why devs reporting to PMs is a bad idea. :)
The issue is that an engineering manager has different deliverables than a product manager. As a product person, I can succeed (in the short term) even with fairly miserable code. I usually report to executives who could hardly care less about engineering quality. What they want from me is all about the market. That would not be the case if my title was about engineering.
I do make time for refactoring and for investing in infrastructure, but I can't make a winning argument for that from a product POV. Usually, I have to just take a hit on perceptions of my job performance and hope to earn it back in other ways.
The massive hurdle to "investing in infrastructure" will probably be a topic of a future article. Anytime someone on my team pipes up about wanting to improve architecture, I always invoke my plumbing example.
Imagine you're a master plumber and you take a look at a homeowner's pipes and realize that they're absolutely atrocious. So you tell the homeowner. And you tell them that it comes with a massive bill. The homeowner walks to the faucet and turns it on. They can't discern any current problem with how the pipes are working. And even if they could, they could hardly stomach the bill that you're proposing.
So they ignore your advice to re-pipe the whole house. And they'll keep ignoring it until something goes catastrophically wrong.
This is very interesting.
I would fully agree if the following sentence was slightly rephrased, or with just a little extra qualification:
"The issue is that an engineering manager has different deliverables than a product manager"
W.Edwards Deming has been credited with transforming Japanese manufacturing to such an extent that Japan itself became an economic powerhouse as a result of those changes. His influence was a mere philosophical change: that quality should be the focus, and that when quality is the focus, quantity of deliveries improves.
How right he was.
So in an environment like Deming's Japanese manufacturing plants, the engineering manager's deliverable and the product manager's deliverable are in perfect alignment. Not only that but their goals are too.
The issue is not, as your sentence suggests, that these two managerial roles have different deliverables, but that some organisations make the profound error of defining those roles as having different goals.
Yes, I absolutely agree. There is no theoretical reason why the PM's goals and the devs' goals need to be (or even should be) different. That's what Deming was getting to with regard to things like mission statements and vision statements - the idea that every person in the org, from the janitor to the CEO, should all be rowing in the same direction. But in practice, this is too often not the case. In practice, I've seen too many times where the PM is hellbent on delivering whatever the client asked for - to the letter - even if it means delivering a crappy, brittle, bug-ridden project.
In medicine, we have strict separation for these kinds of things that works well in practice, and seems like it would address these issues as well.
Say I'm an LPN. I'm in a position where CNA's have to answer me with respect to nursing services, but RN's and up completely override any medical decision I could have. Business administrators have no relevance to medical decisions and can not (legally) have any input in those matters. Similarly, even as high up as an MD is, it's not a business administration position and they have no say in strictly office operations. People are kept to the domains they actually have experience in, but can advocate across those boundaries. Through that advocacy, peoples needs are (often) met.
I've also cooked professionally where these clean boundaries don't exist. You wind up with management who've never worked in a kitchen before, trying to tell me, as head cook, how things should be done. Unsurprisingly there's huge dysfunction.
This is great insight and you can't possibly know how timely it is for me. You see, another article, that's been floating near the top of my "mental queue", is about how dev is often compared to construction (e.g., the "building a house" analogy), but I feel strongly that dev is more accurately compared to medicine.
I'll get this written up in the not-too-distant future. Stay tuned...
I have no proffessional experience yet, so I can't disagree. I also would like to report to someone who understands somewhat of the dev work when I find a job... But if it's not the case, at least someone who can communicate effectively with their team.
Nice post! Thank you for sharing your experience 😁
100% agree with this. I was aghast when, during my interview for my current position, I asked a product guy:
"So I assume you're from a technical background, right?"
to which he answered to the effect of:
"Nah, that's not necessary for product roles"
Yikes 😳
I can actually kinda sorta agree with that person - but only under several conditions.
First, in keeping with this article, that "product guy" shouldn't have any programmers reporting to him. I can absolutely work with a product guy on my team, even when that guy has no technical background , assuming that he's someone who works alongside me - and not someone to whom I report.
Second, the less technical a PM is, the more I expect them to defer (within reason) to the programmers and other "tech types". If I tell them that a task will take all week, I don't mind them asking me for a high-level explanation. But once I've given that high-level explanation, I don't wanna hear them continually challenging why this takes so long and continually asking me if it couldn't be done a little faster. Also, if someone is truly non-technical, then they need to be more aggressive about pulling in the tech guys whenever planning is being done. In other words, don't come back from a big quarterly-planning meeting, held with tons of senior leadership and no technical people, and then tell me exactly what the tech guys are gonna accomplish in the upcoming quarter.
Third, non-technical product guys are only appropriate in certain environments. For example: If we have a large, mature app with many features to be learned from the front end, I don't so much mind a non-tech type being that person who knows all the features in-and-out and knows all the client's priorities - but doesn't know anything about the technical underside of the project. But if we're doing a big new greenfield project, perhaps creating some kind of functionality that goes beyond your "standard" web/form-based UI, then it's gonna be a lot more difficult to deal with a product guy who has no idea what it takes to put such things in place.
Loved this article.
I find it hard to think of any administrative work in the 21st century that is not technical.
Just recently my wife tried to pay her social taxes but the money was transferred to a bank account that did not correspond to her appropriate district. For some reason the correct bank account number was not communicated to her, and for some reason districts have different bank account numbers.
The country in question is still quite backward when it comes to administration. Departments are not integrated. Money that goes to the state to one account number can't be identified by a different district as a state payment. It's a mess.
The reason why it is a mess is because the people doing the administration are non technical. Today, nearly all money transfers are electronic, nearly all form submissions are electronic, and 99% of administrative business processes are or can be automated.
Administration == IT.
Now one might try to present the argument that project management is not about delivering technical change but about orchestrating people.
This is usually not the case. Unless we are talking about control systems or engineering, where senior managers focus on tight quality control and other peripheral aspects of technical change, most white-collar work is about delivering change to business processes. And in this day and age those business processes are largely automated.
To effectively deliver change you have to understand what you are changing, and today that means automated business processes. In other words, IT systems.
I think though that it would be too harsh to draw the conclusion that PMs should all be technical or be fired. The real problem is that all too often there is no economic incentive for ineffective project management to change. Most projects fail, most projects are inconsequential, and in the Western world most projects exist just to keep someone in some bullshit job. Money is largely synthetic and real production is automated.
If devs want technical project management, then we should either demand it, or educate and train those managers we have. If the PMs are our bosses, then we either have to manage the managers or quit. It's as simple as that.
+100 to manager advocacy.