[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 Manager. They could be a Product Manager. They could be a Scrum Master. They could be a Dev Manager with no direct programming knowledge. I know those aren't (or shouldn't be) the same roles - but in some organizations those titles are used rather interchangeably. So for the rest of this article, I'm just gonna call them, collectively, "PMs".]
Maybe it's just an anecdotal observation, but it feels to me as though an increasing number of companies are organizing dev teams such that the programmers report directly to someone who is non-technical. Specifically, I've noticed that devs can find themselves being managed by someone who knows little-to-nothing about how devs actually do their jobs.
To be clear, this scenario isn't necessarily "bad" or "wrong". I've seen it play out well. Maybe you have, too. But the more times I've seen it put into play, the more convinced I become that it's the org-chart equivalent of a code smell.
Why do I say this???
Balance
I've found that, on some of my best teams, there's a sort of healthy, respectful... tension between the PM and the devs. Maybe that sounds too adversarial. So instead I'll call it balance.
Hopefully, we're all working toward the same long-term goals and deliverables. But on the path to those goals, there can sometimes be a bit of a push/pull between the PM, who's primarily looking at things like dates / milestones / demos, and the dev, who's primarily looking at things like tech debt / architecture / legacy bugs / etc. Consider the following putative (but realistic) conversation:
PM: The client's decided that this task now needs to be done by this sprint. Can you swing it?
Me: I'm pretty tight at the moment. What can I push out of this sprint to make room?
PM: Hmm... Well, this close to go-live, not much. But the task they're escalating has a pretty high estimate. Isn't there any way to do it faster?
Me: That estimate was based upon me needing to build a new endpoint to dynamically query the values that are needed in the code. But those values only change every six-months-or-so. I can do it much faster, and fit it into the current sprint, if I program it with hardcoded values.
PM: That would be excellent.
Me: But if I hardcode those values, I'm gonna create a new ticket to build the service. And you gotta promise me that it will be a top priority as soon as we launch.
PM: Deal!
Did you feel any tension in this dialog? It's subtle. But it's definitely there. I've had conversations like this hundreds of times in my career.
There's typically a high degree of respect between me and the PM, and in the big picture, we're both working toward the same goal. But when the PM is trying to manage the daily BS that tends to flow from the client/project, they can sometimes ask for things that jeopardize the long-term health of the project. And that's OK - just so long as there's good communication and I feel comfortable pushing back if I believe that something unreasonable is being asked for.
In the example above, we completed a basic negotiation. I gave the PM something they wanted (an extra deliverable levered into this sprint) by proposing a suboptimal solution. But I only did this because I knew it wouldn't have any immediate side effects and I received assurance that we can do it "the right way" once we get past the launch date. (Obviously, such assurances would be meaningless if we didn't trust each other, but for the sake of this article, let's just assume that everyone is a "good actor".)
The dynamic above "works" because, while the PM and I both have different types of authority/responsibility on the team, neither one of us reports to the other. Specifically, if I report directly to the PM, there's a much greater chance that this interaction becomes... problematic when the project reaches a hectic stage.
When the PM and I are truly peers on the org chart, it's much easier for me to provide professional pushback whenever I'm asked to do something that may cause short- or long-term issues. In extremely rare cases, if my "professional pushback" isn't sufficient and I feel compelled to hold my ground, I can escalate the issue by taking it up with my manager.
But when the PM is my manager, that kind of professional give-and-take can be much... touchier. If the PM isn't top-notch, they could become flustered by such pushback when the project is in the 11th hour. In the worst case scenario, they might just decide to order me to do it their way (or, the client's way), even if all my objections are still valid.
Needless to say, this can create some really uncomfortable situations. If, for example, I've been ordered to hardcode something that I know will soon break, how far do I go to cover my own backside? Because I've also found that trying to raise alarms with someone other than the PM can lead to its own set of headaches. (For that matter, failing to raise alarms can also cause headaches. Damned if you do, damned if you don't...)
Advocacy
I strongly believe that one of a manager's primary roles should always be to advocate for their direct reports whenever appropriate. That applies to any team, in any part of a company.
Sometimes that "advocacy" involves shielding them from the tone-deaf dictates of leadership. Sometimes it requires taking the employees' "side" when the client is pushing hard to do something that will actually torpedo the client's project. Sometimes it involves knowing which new members will best fit on the team - or, maybe, which team members need to go. In my experience, PMs are frequently downright bad at this.
This is rarely the PM's fault! How could it be? It's much harder to "advocate" for employees when you don't really understand what they do.
Also, in many orgs, the PMs spend so much time interfacing directly with the clients/stakeholders, that they become little more than their mouthpiece. In fact, as much as I don't care for endless meetings, I've occasionally told my PM that they should just let me attend the meetings directly. Because if I let them do their "PM thing" while I sit there and code, they'll end up just trying to tell me everything that was discussed in the call, verbatim.
This is one area where I've seen the starkest difference between technical and non-technical managers. When devs tell a technical manager - presumably, with at least a high-level understanding of the code - that the given approach is really really bad... they tend to listen. That doesn't mean that the devs always get their way. But it's rare that a technically-minded manager just dismisses the concerns of those who are actually, you know - doing the work.
I've seen too many times where a PM will just fall back (all-too-quickly) on the time-worn chestnut that this is the way the client wants it, so this is the way we'll do it. Install a toilet on the roof?? Who cares if that's ridiculous? That's what the client wants! Make the walls from styrofoam?? Who cares if that will all break down in a year? That's what the client put in the specs!
Technical Illiteracy
I fully understand that someone mustn't be a programming guru to manage me or the projects on which I'm assigned. But I've had some scenarios over the last half-decade-or-so that have been rather curious. Some have been downright frustrating.
In software, it can happen that moving a button on a page is sometimes a much longer task than it would seem to the end user. I don't get annoyed when end users are confused by this. I do get a bit annoyed when I report to a PM - and I have to (repeatedly) explain this to them.
When I'm a lead/senior on a team that reports to a PM, the annual review situation is always a bit odd. Some PMs don't involve me at all when writing the reviews for the other devs. And honestly, I kinda like that, because writing annual reviews sucks. But when the non-technical PM writes a review for one of the other devs, without even asking me (or anyone else) about the actual code that was written by that dev? Well... it's a bit perplexing to me as to how they came up with any sorta accurate assessment.
On other teams, I've had the PM lean on me heavily to help write - or to write entirely - the reviews of the other devs on the team. And while I understand the logic behind their request, I can't help but wonder: Why are they managing these people if they're not comfortable writing their reviews???
I've had PMs, trying to do the "right" thing by shielding me and the rest of the team from endless meetings, report to me that a big discussion was just completed with all of the stakeholders. A decision to pursue a potentially-catastrophic course of action. And I calmly tell the PM that we probably need to call another meeting, ASAP, to be attended by the exact same people and me, in which I can explain some of the nasty consequences that could result from this new direction.
Often, when there's, say, an hour-long meeting with me, the PM, and some other technical folks, I then have to spend 20-30 minutes after the meeting, on a follow-up call with the PM. I have to do this because the PM doesn't really understand what was discussed. And I have to do a long debrief after the original meeting just to explain, in laymen's terms, exactly what everyone was proposing.
Blunt Talk
This is probably more of a personal preference than anything. But when we're really trying to hammer out the best-possible technical solutions, I find plain, honest, blunt talk to be more than just a "nice to have". At times, it can be absolutely critical.
[NOTE: No!!! Not Emily Blunt. Who the hell edited this article, anyway???]
I suppose that devs have a well-earned reputation for being, well... a little too blunt. And I get that. Really, I do. But I've found that the PM non-technical-type managers can lean farrrr too heavily into political speak. They spew it themselves. They expect to hear it spit back to them.
I totally understand that, when we're talking to a client / stakeholder / executive, we can't tell them, "Wow. That idea's complete friggin rubbish." But when the devs are sitting around in a room trying to brainstorm how to solve the latest problem, and someone pipes up with a gawd awful idea, I'm gonna tell them, "Wow. That idea's complete friggin rubbish."
The best dev teams that I've been lucky enough to be on all had an atmosphere of friendly competition and frank evaluation. We didn't needlessly tear each other down. But we didn't sugar coat anything, either. As long as it was "just us" in the room, we had wide latitude to throw stuff on the whiteboard - and to get a few jeers when our idea was shown to be, ummm... lacking.
I've never had a problem with such communications when I report to someone who's technical. They know that I won't spout off in front of the client or in the boardroom. But as long as we're in our own sequestered environment, we can speak pretty freely.
This freedom really plays out during those rare times when two-or-more team members have passionate - and diametrically opposed - viewpoints on how we should proceed. That doesn't happen often. But when it does, I've seen devs get to near-shouting with each other as they fervently advocate for their chosen solution.
I've seen red faces. And a bit of flying spittle. But you know what? At some point, the team makes a collective decision. And even if my decision was shot down, when the meeting ends blood pressures drop, smiles return, and we begin the task of implementing said approach.
Again, I've never had a problem with such communications when I report to someone who's technical. But when I report to a non-technical PM-type person?? Well... I've seen these "passionate" meetings lead to formal write-ups.
The "problem", in such scenarios, is that the PMs work-and-operate in a sphere that is inherently political - at almost all times. Most dev teams, in my experience, are almost completely apolitical. So it's difficult for PMs to understand the healthy (but, to the casual observer, aggressive) jousting that takes place during these sessions. They take the discourse personally. They start acting like the sheltered tech session is a corporate board meeting. And when that happens, the typical dev demeanor does not fare well.
Conclusion
I know this probably reads as a long screed about why PMs suck. And believe me, that is not my intention. Some of the best coworkers I've had have been non-technical PM-types. And I've even had (a few) positive experiences reporting directly to these folks. There's really no reason why PMs and programmers can't "play nice".
But lately I'm starting to look back over the last 20+ years of experience and I'm noticing a general trend. When I'm directly writing code myself, and I'm reporting to someone who can't code at all, it creates more hurdles to be navigated. When I'm reporting to someone who at least knows basic programming principles, many of those hurdles (certainly not all) seem to go away.
Obviously, these general observations are not absolutes. I'm fully aware that, in some situations, with some PMs, it's just fine to have them managing programmers. I'm similarly aware that coding knowledge, by itself, in no way makes anyone a good manager (of programmers, or of anyone else). It just seems to me that when you have a programmer managing programmers, there are fewer opportunities for miscommunications.
I'm truly curious as to whether my view on this is limited to me? Or have other comes to similar conclusions in their careers??
Top comments (20)
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.
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 😁
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...
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% 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.
+100 to manager advocacy.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.