[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??