Hacker News Reader

I worked at Microsoft for a few years and later as a contractor at AT&T for about 2 years. I saw the 2 extremes as far as PMs go.

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.

I had the displeasure of using AT&T's website today and even before I read your comment, I was thinking that AT&T must have a dysfunctional "development by checklists-for-PMs" culture. The site seems like UX appropriate for an SPA, but whenever taking an action, you get redirected 4 or 5 times before landing on the page you intend...only to have some of the elements "lazy" loaded, where "lazy" means "never actually materializes."

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.

The way Apple manages to do this is that, to a larger degree than others, the company is run as a collection of different companies. This has pros AND cons but one of the pros in this context is that their hiring is less "work at Apple", and more "work for THIS team at Apple". Hands-down unbeatable for the specific question of role clarity, but it's naive to pretend there aren't downsides to the practice.

This is how Bell Labs was back prior to divestiture, up until the mid 1990s.

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.

This sounds an awful lot like research at a university. It definitely has it's strenths and weaknesses. Some labs collaborate more than others. Some feel like islands in the ocean, while others feel like a townhouse in the city. Some labs are poor and a few are incredibly wealthy. All of them seem to filled with hard working interesting people.

similar to SRI currently as well.

Multi-divisional form (MDF / M-form).

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

Usually contrasted with unitary form (U-form).

I’d say Apple is structured substantially less like a bunch of different companies compared to one which is explicitly split into separate SBUs.

Yep, I have noticed this about project managers too.

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 key characteristics of a good PM I'd identify are intelligence and memory.

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.

Would echo your sentiment that the role of project manager, product owner or whatever they're calling it these days needs to be rethought. In my org we literally have a squadron of these individuals which leads to bickering and an in-cohesive product experience.

My issue with the two “PM”s I interact with the most:

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

I used to see things the way you do.

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.

Your experience meshes with mine perfectly.

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.

project manager are there to free devs mind from various distractions.

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.

Project managers are very useful when there are clients and budgets to deal with, as in outsourcing and contracting shops.

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 definition of PMI on what is a project: A project can be defined as a temporary endeavor undertaken to create a unique product or service.

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.

I think the issue is that we call it project/product manager, but what we actually want is secretary.

Micro-management has been institutionalized in much of corporate America while romanticizing "vision" without actually developing one.

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

Been thinking a lot about this - right now I run eng for a pretty broad product in healthcare, and there is overlap between eng and product.

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.

> 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.

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...

> I've still not quite cracked what's different about Apple culturally that they seem to be more immune to this problem.

... 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

I'm not sure you're talking about the same "this problem" as the thread you are replying to.

I took that as the "secret FAANG".

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

Likely a direct legacy from the Steve Jobs days. When you have a CEO with such a strong product vision you don't actually need product owners/product managers any more other than to fill in the details. Those are still super important, but if you got those wrong it wouldn't pass review anyway.