My PMs at Microsoft were all good at tracking tasks/projects and managing blocking issues. At a minimum they saved me a lot of headache having to answer why a task was late when I was blocked by a dependency. They also had quite a few technical PMs, my brother was actually a PM there before I started after getting his Bachelors and Masters from MIT.

AT&T's PMs were a totally different story. Not only did the PM team outnumber our dev and test teams, most of them were tasked with being product owners for insanely small features. Consider having a PM literally responsible for how a light switch works in home automation, that's the level they broke it down to. Some of the PMs lacked skill or experience, but all were expected to do very little of value and were considered to be successful if they were in meetings nonstop to take notes and give them to the next team in line.

PMs can be vital parts of a tech business, but only when they are given real responsibility and expected to create value rather than countless piles of noted and calendar invites.

And when working through their two-factor-auth process, I kept getting redirected to a version that wouldn't accept my one-time-password because the javascript on the page wouldn't load for some reason. The trick was to switch from Chrome to Firefox.

I wish I didn't understand why it's possible for stuff to exist on big-company websites like AT&T.

Anyway, sounds like an absolute horrorshow for both PMs and devs alike.

There really wasn't one huge Bell Labs, there were literally hundreds of hundred person teams run as if they were little companies, but with a huge bureaucracy providing funding, guidance, and all sharing a knowledge pool.

If you changed teams, you could find a completely different team culture using completely different tools. And like biology, some teams thrived, and some failed.

https://en.wikipedia.org/wiki/Multi-divisional_form

Usually contrasted with unitary form (U-form).

I have worked with some amazing project managers, but almost all of them were more hybrid-somethings than purely business-degree folks. Usually designer-PMs or SWE/DS-PMs who drive the vision for the product at large. They make sure everyone in the loop buys into the same idea, is on the same page and stays in sync.

However, to do it effectively, the PM must have deep insights into the product. even better if the make-or-break aspect of the product is their specialty. A PM who facilitates communication without insights of their own is being treated like an expensive secretary by the company, and IMO, hurts the development of both the product and the individual.

I maintain that an amazing PM has scope to make a far larger impact than an amazing SWE. On the other hand, an average PM actively slows down progress, when an average SWE meets expectations and still gets their work done.

The best PM I ever had the pleasure of working with couldn't code worth a damn. And yet, he could recite details he'd heard from developers 3 weeks ago, and apply the understanding he'd gleaned to current decisions. Furthermore, he had an unvarying nose for bullshit and ability to gently push if developers were trying to make lazy decisions.

Unfortunately, I don't think that's something you can test for or train. Either someone is that type of person, or not.

Project managers basically do something that the devs, especially dev manager, can handle themselves. It seems like a leftover process for when software contracting was more common. There’s no reason a developer can’t just manage the Kanban board and write a quick report.

Product managers can be really good but in a lot of cases they just devolve into stakeholder management with poor/no vision. Because they talk to upper management a lot they can get a lot of credit for things they didn’t have a lot to do with, because they’re the visible face for it. This can sometimes lead to the Product org getting too big because they get promoted up to Director and now need 10-100 reports for something that only needs like 3 Product managers max. Then you’re in a really bad spot because you’re going to be bothered by PMs with small scope a lot about stupid shit

Then I actually ended up in the position where I took on the responsibilities of a Project Manager in the course of building a department. I see it much differently now having worn both those hats as a generalist. You're tracking two different sides of the same body of work, and there is solid value that a good project manager provides in terms of producing a meaningful skeletal specification on which more in depth technical analysis and work can be done.

In addition, not all devs are full on gung ho let me throw something out there that I know will be mostly wrong until the details get filled in by everyone else. As a PM, you're as much the Rock in a pot of Rock Soup as you are the guy in meetings all the time. I've had to eat a lot of humble pie since getting saddled with building a department. The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles.

It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something. You don't want to have to do it all at the same time.

Especially this is key: > The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles

> It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something.

Exactly! Thank you for putting this so succinctly.

Just being aware of what needs to be done and in what order is critical. For that you need a bird's eye view of all relevant pieces, which is almost impossible to do when you are in the weeds.

I'm glad I can delegate them the reasoning about which task is more urgent, and them acting as buffer to clients frees me from a lot of time trying to understand what they want, how they want it and all the back and forth about how much they want to pay for it.

good project managers, that aren't just bossing internal people around but working with the team at different part of the projects like communication and operations, are rare, but are a joy to work with.

The role is not as useful in tech companies where developers are working permanently. It's actually hurting collaboration across teams if you start budgeting projects and people tightly.

The Devs who are permanent employees and maintain a set codebase/application/etc do not fall into that. They know what to do, they have a defined Change Management/SDLC abd they are challenged into finding the technical solutio. The project management includes tracking the requirements, sequencing events, getting resources/contractors, etc.. A dev should be spending '8h' per day coding, not figuring out budgets and interviewing contractors. Of course different companies have different approaches, but ballpark and from experience I think my above writings are pretty valid.

So you have non-designers enforcing their personal "vision" without cross-team collaboration or user research.

In your case, it sounds like you have crappy product leadership. This is _way_ too common.

You need a cohesive product vision from the top down (VP/head of product), which they communicate to their team of PMs. The head of product needs to ensure that their team can make the correct product decisions. This means guidelines on where the product is going, what the company prioritizes, and how products inter-play/work together.

With an actual vision from the top down, these calls which your PM team bicker on should become easy.

An engineering analogy: the CTO/lead architect sets the standard for the direction of engineering, its services, etc. This is followed by everyone in the engineering org (hopefully) with alignment and without bickering. This SHOULD happen for product, too.

Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.

You could probably reach out to your engineering leader and have them coach the head of product here. After all, that's the engineering leader's role - making sure their peers make the right decision and remove blocks from you, the engineer.

Regarding overlap, a good PM should amplify engineering. You might be a product focused engineer, but trust me: an engineering team cannot and should not be focused on writing user stories, performing research, and deciding the larger impact of features alongside their regular job of executing with code.

To expand on this, there has been one defining difference in good companies and bad companies I've worked for.

In good companies, everyone has expertise. Your PM can talk about details. Your director can talk about details. Your VP can talk about details. They do this because it's culturally expected that they know this. So they spend enough time to familiarize themselves and do normal paper-pushing responsibilities.

In bad companies, that's just... not there. If you ask anyone of those roles about details, they don't know and can't speak intelligently.

Consequently, in the former, you get much smarter decisions from all players. In the latter, you get ignorant decisions because there's less shared knowledge.

The strangest thing is that it seems more cultural than training / education. Either the company has this expectation of its people, or it doesn't. If it doesn't, no amount of degree will paper over that. If it does, it doesn't matter if your people are sharp but lack degrees.

There's a famous story from Microsoft back-in-Gates-days, whereby Gates was notorious for his detailed questions in meetings: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

... Really? I do not get that impression at all after Catalina and Big Sur. Every release these days seems to have more problems than the last. I'll put up with macOS until High Sierra is unsupported and then I'm done.

As an Apple employee commented here last year, "I am awed by the fact that we manage to release any software at all, let alone functional software."[0]

[0]: https://news.ycombinator.com/item?id=21218413

Apple definitely has PMs but they work differently than they do at most other companies.