I think product management entails some of the most important things a company does. But it's really hard work, and many less capable PMs gravitate away from it and more towards either "driving" (i.e. micromanaging) the engineering team or just playing politics. In an organization with separate Engineering and Product functions / org charts this is really hard to deal with. You can complain up the chain of command, but bandwidth in that direction is (for natural reasons) very limited. As an EM the end result is often that these PMs make life miserable for your best engineers, and they leave.

My current view is that the best approach is to embed product management in the form of a "mini-CEO" (i.e. PM) in each team, and if they're not technically competent pairing them with a "mini-CTO". Much less room for politics, and much more for teamwork.

The most successful teams I have been in had no dedicated product role, instead, all decisions were made by the developers.

My current view is best to remove all type of non technical people or even mildly technical people from the developers' way and let them build in peace.

PM for retail company did long stints in merchandising at Costco

PM for spreadsheet company was a former banking analyst

Most companies hire under qualified generalist PMs who have to learn everything about their market from scratch; it’s very challenging and prone to outright failure.

Hire fewer PMs, and make sure they bring a key skill to the table. Let Microsoft and Google train the juniors.

The insult to that is also "no changelog". I hate the generic "we try to make it better, but ain't telling you what". So at this point it's a gamble whether I want to update or not, so I don't.

Also for Spotify, perhaps it's time to allow a pool of 1000 (?) volunteers from each language to help you rewrite titles, names, etc. in the local languages. I'm happy for the latin alphabet, but do make a "local language" field and then let the users see THAT instead of the common if they choose to.

Then the perfectly qualified PMs start from square one again.

IMHO it's an essential skill for a PM to familiarize him/herself with a new domain in short time. It also offers cross-pollination / the chance to do things different. Imagine Steve Jobs coming from a pure IT background instead of liberal arts / calligraphy -> Apple wouldn't have been so different any more.

> Then the perfectly qualified PMs start from square one again.

Exactly the same point holds for programmers: what if (say, by becoming acquired) a company has to switch from being a, say, a Deno/Vue.js shop to becoming a Java shop? Exactly.

So the answer is: don't do such radical changes in the product portfolio and way of doing work if you don't want the employees to more or less to start from square one again.

They had the ability to learn technical things once, then they can do it again. (In a short time? Not so easy to find out until after you've hired them, in any case?)

https://www.google.com/about/careers/applications/students/

At the end of the day, whether you should have a Product Manager or not AND the number of PMs you should have will depend on various factors such as the product itself, team size, size of the company, type of company (B2B, B2C, etc). But saying that PMs are NEVER needed and Developers should just build is wrong. Someone has to wear the hat of a 'Product' person. Whether it's a separate person or the developer is dependent on the factors earlier listed.

My comment here [1] and the discussions for that post is a good example of this mindset of PMs are NEVER needed.

1) https://news.ycombinator.com/item?id=25975417

If you work in pretty much any kind of B2B SaaS and don't have PMs (or someone doing the PM work - if you've got engineers who were formerly PMs who spend half their time managing the roadmap, you can't really claim you're only employing engineers), you're probably doomed.

For example, in an area with strict financial/regulatory compliance laws, are you expecting every engineer to be an expert in those laws? And have contacts at the government agencies implementing those policies?

The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place.

> For example, in an area with strict financial/regulatory compliance laws...

How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?

Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time.

I happen to work in a highly regulated industry, and we have an in house law expert, and an in house medical compliance team.

None of these roles are embedded in the development teams though, they are simply asked for advice rather than manage the engineers (which would be insane).

That is how it should be.

Saying it’s often some new grad is like saying there’s no point having an on shore dev team because the devs are often fresh out of university. If you continually hire terribly you’re going to have a bad result.

A PM should become the subject matter expert in the product they are developing. They should be able to field questions on most every part of it, and be able to build a roadmap of features. Communicate with all teams associated with it. Having the programmers plan all features is a recipe for disaster if your product isn’t designed for developers. It’s like saying you don’t need a qa team because the developers tested it.

The developers MUST care for the quality, not outsource it to some external team. The desire of large corps to spend huge amount of $$$ to create artificial roles to water down ownership can never cease to astonish me.

If your devs can't think of handling nulls or corner cases, you got a skill problem, and you should ASAP upskill the devs, not outsource thinking to another tea.

Making quality somebody else's problem is the exact opposite of ownership! You want agile? Damn leave the devs alone, stop building walls around them and the product they are building!

As a former quality-focused dev, I can tell you that the industry beats it out of you with a club. There is always somebody above you who cares only about their own career ambitions and has more leverage than you do. This leads to a horde of devs who just do what they're told and not much else.

Businesses are all about risk management. The safest way to de-risk a business is to water down ownership, at the cost of injuring quality-focused devs. You're only a cog. You need to only be a cog to them. They must to be able to replace you with another cog when you leave for greener pastures.

  > I can tell you that the industry beats it out of you with a club.

i've seen pr's sent out for review that literally didn't work or crashed immediately on use... as if the expectation is qa will report whatever needs fixing but thats fine cause its "in qa now" so development is "done".

"When a measure becomes a target, it ceases to be a good measure".

Definitely can take a while to find one though, that much is true.

I used "advocating" loosely here. I hate the "advocate a lot, build nothing" mindset myself, and I am not a fan of the Bay Area and its practices (to put it mildly), so I edited my post.

What I mean is devs making tools for devs, resulting in better overall quality.

In my experience good test engineering teams can focus on having a more global view of systems while not being biased by implementation details.

Strangely enough, that's happening at a few companies (run by Amazon refugees IIRC) where they think that making devs do QA and removing QA/QE roles will speed delivery. I'm in one of those companies now, and I'm waiting for the #FAFO loop to happen.

If it's just clicking UIs all day long then obviously a QA should do it. Or have an UAT environment where a few more enthusiastic customers are willing to test and report bugs.

Nothing wrong with that, except what typically happens at larger scales is that some people enjoy wearing the hat more than others, then the team realises that it's better if those people spend most of their time doing product management, and then they tweak their job titles ever so slighty....

> How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?

In my (highly regulated) industry, always? They'd be bad at their jobs if they didn't have this.

Edit actually, I walk that last bit back slightly. They don't need to be experts in those things, but they need to know enough about the broad landscape to understand what tradeoffs need to be made and set direction. Similar to a CEO not needing to be an expert in product, marketing, engineering, finance etc. to be effective, but they do need to have enough knowledge to know how to balance competing requirements across these things.

> Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time.

I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else. I have long advocated that PMs /must/ be technical to be successful and, maybe more importantly, useful.

If you’re in an industry that is compliance encumbered, you should absolutely expect that your PMs are experts or at least professionally competent in the compliance standards you need to meet, or at minimum intellectually and contextually capable of getting there rapidly.

Hiring someone just out of college to be a PM is a huge red flag that your organization doesn’t understand the role of a PM, and that your upper level management is likely incompetent also. Without significant prior experience in some related facet to the product, it is not possible to be successful as a PM, and I wouldn’t expect a new grad to be able to do much more than push papers. PMs should always be former practitioners, if possible, but at least technically competent at minimum.

> I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else

Makes me wonder if you're saying that these cases are the exception. In my career they have sadly been the rule. Not 100% literally, i.e. my PMs have never been 22 years old, but they were, 99% of the time, grossly incompetent.

And yes they were a management / hiring failure, absolutely, but it seemed that nobody cared... :(

Absolutely this. And the engineering teams should have visibility of customer support and other functions to understand common pain points, causes of churn and opportunities for additional revenue-generating functionality. That doesn't mean answering run-of-the-mill questions or doing refunds all day, but it does mean talking to prospects, looking at escalated problems and keeping an eye on the wider industry.

Bonus the product team on reliability (as well as velocity), and the ops/sre team on feature velocity (as well as reliability), and it'll balance itself out.

I think some people simply can't get rid of the idea that there has to be some external paternalistic figure that looks over developers' shoulder and guides the poor hapless saps and their incentives. Do they give candy to the good boys/girls and coal to the bad ones? You might be thinking of Santa.

The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product. Management types insisting to compartmentalize incentives is them trying to have an excuse for their own existence.

We should all drag ourselves kicking and screaming to the reality that we can do much more with much less management layers. Even big companies, which are bloated beyond saving, are waking up to that fact. PMs are the first to go, just look at what Meta, a notoriously inefficient company is doing to their non technical PMs.

Think for a second why nobody has had the idea of letting an engineer be a 'Marketing Project Manager' of the marketing team and be calling the shots what campaigns to run, what marketing materials to produce, and make marketers estimate with poker cards how many of their leads will turn to a sale. Sounds stupid, right? Yet this is exactly what you want us to accept the other way around. Not gonna happen.

There is no excuse to have non engineers embedded in and actually calling the shots on behalf of an engineering team with the patronizing though that the engineers can't decide for themselves what to build and how to prioritize it.

Being on a team where everyone has a high level of personal ownership and accountability like that is truly wonderful, and I agree, it works great.

You just have to find (or build) a company that explicitly filters out the 99% of people who only want a job for the paycheck and don't care about the customers, the software, or the product.

The hard part is how do you design a compensation package for a developer or sre worker bee, to incentivize these? How do you make their bonus depend on something as nebulous and hard to measure as "greatness" or "popular"?

For most employees, the candy/coal model works. You're not going to find low-level individual contributors who work because they just want to make a great product.

Unfortunately, only the first part is practiced in my organization (company shares), but I am actively fighting for the second.

I have equity as part of my comp package, and I know there is zero link between how good a job I do and which way the Wall Street Wind blows today. So to me it's just like cash but with extra steps.

Maybe it's different in the startup world, I don't know. The only startup I was part of, everyone's equity went to zero when the business failed, regardless of how well anyone did their job, so I'm not much of a believer.

We just have a medical compliance team and ask them for input, but they most certainly don't tell us what to build nor drive the product direction.

In short, I question the need of a PM, not the need for domain experts (law,financials,etc).

Good PMs are often engineers or ex-engineers themselves. But a good PM will do a much better job than just sticking a bunch of engineers in a room and asking them to manage the product. A lot of developers really hate tasks like:

- Designing UIs

- Thinking through complex workflows to simplify them (unless they're developer workflows)

- Writing documentation

- Often also, identifying and fixing small quality issues like bad error messages

- Figuring out what the customer's actually need vs what they say they need

Some devs are naturally talented and capable of doing all the above, plus banging out the code too. That's great, maybe they don't need a PM or more likely maybe they will become one themselves in future. But left to their own devices a lot of dev teams will rapidly lose the plot and start producing features nobody cares about, or doing endless refactorings, or produce something that's too hard to use.

But imagine if the developers themselves could break down the external requirements into engineering needs!

Or are developers grug brains that need a bigger, superior brain to simplify scary real world into simple, safe engineering needs? Or developer grug so busy, must write code, no time look at feedback form, no time think client request, need simplified instructions, must slap keyboard, clack, clack?

Context: https://grugbrain.dev/

Maybe not an expert, but literally every project I've been involved with where those things are relevant, the PM knew more than most of us, knew who to talk to, and was responsible to make sure we did the right thing. It is pretty much what half the role was about. They were often pretty senior people with long experience working in a relevant field.

It's a well established fact developers love building things so much and hate wasting their time with useless meetings! The hero PM saves the developers so much thinking by being brave and talking with the scary outsiders.

The PM's selfless bravery gives the developers the time and space so they can focus on the really important part of building. The really important part of building is, of course, being in a 2 hour meeting where the PM is repeating (badly) what the experts said, and making you play card games where you pick some numbers, very much unlike a nursing home for the old playing bingo.

I love your take! You totally treats engineers as responsible adults who have multiple skills and abilities besides coding, and not at all like autistic children that would flip out as soon as somebody touches their crayons.

Correct. Most engineers dislike meetings, so much that they complain that they don't get enough focus time in the day and are constantly interrupted.

> like autistic children that would flip out as soon as somebody touches their crayons

No one said this, you're arguing against a strawman. But even still, how many devs do you know that willingly want to talk to customers?

I don't generally find myself in the Anti-PM camp; but I think one of the valid criticisms of the role is that high quality hiring for it is so extremely difficult that maybe its existence is an indication of a structural problem. As the article says; if the ratio of PMs to Teams should be less than 1:1, maybe the correct lens to view this role through is more of a higher-level product lead, or a separate product branch who act more like free agents that attach themselves to teams temporarily, splitting time, where needed.

I will say, I've worked in two roles where this was the case; one a very large public tech company everyone reading this would recognize, and another a 30 person startup; giving PMs higher cross-team authority felt, to me, like a really good decision. One small positive byproduct I actively observed: when speaking with our PM, who was shared with four or five other teams, he was constantly aware of all the other work they were doing, and would actively make recommendations about how our little feature could plug-in with their little feature to increase the quality of the overall product. One small negative he communicated: because the company had no entry-level PM roles, which is where he started before they refactored the org chart, its non-obvious how you backfill these roles or create an entryway for new talent to breach the industry. Their current solution to this is "well, we can't really promote internally unless an EM or Engineer wants to switch domains" which they genuinely did try to support.

- financial

- medical

- data protection

and you might need different experts' opinion for that. Do you suggest that they are all product managers?

> This let's you focus on the craft of delivery

I don't give a rat's ass about the craft of delivery! What a reductionist thing to think of engineers as "delivery machines". Me and my team mates are not a factory that simply takes input from a task master and produces code to their bidding.

I care only about one thing: solving the problem! That encompasses learning, understanding and, finally: delivery. To do that, I need to speak to stakeholders MYSELF, I need to see how they are using the product MYSELF, and any regulation I am gonna implement, I need to understand in depth. I don't need somebody to summarize findings for me, I can make my own damn conclusions.

Sure, I will ask the domain experts of their opinion, but me and my teams will decide what to build, when, and how, and do we will do it together, based on all our shared learnings, not based on what a PM told us.

Who prioritises the problems?

If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

---

> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

Ah, I see. There is a concept known as a separation of concerns that prevents this on most teams.

There is a good saying for complex service delivery that most developers operate with in application development and support. If you want to go fast, go alone. If you want to go far, go together. That "together" brings more skillsets that most small engineering teams have on staff, and is typically not beneficial for them to focus on gaining.

> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

There's two types of problems that developers solve. Problems that they, themselves created (oh no, I wrote a bug), and problems that are given to them.

The second type (traditionally, the "business problems") are being prioritized and solved by the people who care about them. Namely, the CEO and the exco. Those guys set overall strategy, culture etc. and then the delegate the implementation and some of the detail to people with more expertise.

Developers do not run the business. They are delegated to to solve specific problems in the context of running the business. Not all of the business' problems will be solved by developers, but all of the business' problems should be solved in a coherent and harmonious way that accounts for the context of all the other problems in the domain (market, regulatory, finance & tax etc.)

For a specific product, the place where this context is managed is usually by someone wearing a hat with "Product Manager" written on it.

In times of plenty, this works, and I think it can have high velocity. Especially with very small teams that all have high levels of direct investment in the result.

There are also times of famine, however, and the work that keeps the lights on is often not work that even invested software developers want to prioritize. When making money is on the line, there's always somebody who's there to make you eat your vegetables. Who, in your conception of the problem, is that?

What kind of work is that? And why are the developers willingly not wanting to prioritize it, if the alternative of not doing it is becoming jobless? Do we need some kind of PM figure to say things like: "If we don't make this feature for the client, we are doomed, so start coding. Chop chop!". And do we need to keep that guy on the payroll for simply relaying a message?

Yes, and yes! I believe you're starting to see. Good management has value. Even if that is to deflect invalid criticism for devs.

"But if you don't do these things, the company fails!" Yeah, and look at all those small, engineering-heavy companies that do exactly that! And further--eventually, as you scale you reinvent division of labor because as much as we like to kid ourselves, software developers are not, universally, better at doing everyone else's job. (If you find yourself in a position where you are better at doing everyone else's job, you should probably find a new company to work at.)

Middle men only improve transfer of knowledge between people under very specific circumstance. Usually they just make things worse

Let children play Chinese whispers, I don't need that in my life

This isn't just applicable to some niche organisations working within e.g. finance (though there's likely to be a higher regulatory burden there), engineers need a basic understanding of something like GDPR to do their job because it impacts every organisation handling personal information in any form.

Engineers are likely to solve problems that the customer doesn't care about. If you know engineers that say things like "the customer is an idiot" then you understand what I'm talking about. Even if the customer really is an idiot that is the person who needs to use the product.

I’m not sure you can generalize like this. Do the engineers have RSUs or financial incentives where they do better if the firm does better? I’d argue they’d care more then. Also, a lot of engineers intentionally chose to work in market segments they’re passionate about. I’ve been at the same company for over 13 years. I could likely make more elsewhere but I find the domain I work in quite rewarding and interesting.

They have a larger emotional incentive to work on cool things that they enjoy, as opposed to the relatively small change in company price if their individual product succeeds or fails.

1] https://news.ycombinator.com/item?id=25975417

How do you organize updating of documentation, training materials, enablement of support, pricing decision, updating of price lists, enablement of sales, presales, and customer success teams? How do you manage the input towards analysts like Gartner, that have a big impact on the decision process of your customers?

How do you evaluate the offering of the competition compared to your offering, how do you determine where you should be in 1,3,5 years to have a competing product in the market?

Most PMs are mostly concerned about what should be built to create a valuable product for customers, that provides healthy stream of revenue for the company. Most developers are concerned about how it should be built. That is a completely different responsibility.

That does seem to require at least a PHD in prioritization or a totally real role like a Product Manager indeed! A naive approach would be to make a spreadsheet with the names of the clients, their current and potential monetary value, group the issues by the corresponding teams and themes, and let the teams ask additional clarification questions to the clients so they can prioritize. But yes, I can see your point, a PM guy called Josh with an bachelor of arts degree indeed seems more qualified to do it than a bunch of software engineers, and make the better decisions. I dunno what I was thinking.

> How do you organize updating of documentation, training materials, enablement of support

A naive approach would be to have a frequently updated knowledge base. However, I understand that Josh and his arts degree make him the best at producing/updating of documentation, training materials, and enablement of support, so probably...Josh?

> updating of price lists, enablement of sales, presales, and customer success teams?

Sales + developers + finance sitting together? Shared company view of the important client metrics? Nah, Josh will do it.

> How do you manage the input towards analysts like Gartner, that have a big impact on the decision process of your customers?

Marketing departments? But I have the sneaking suspicion Jake (or was it Josh) is a better candidate.

> How do you evaluate the offering of the competition compared to your offering, how do you determine where you should be in 1,3,5 years to have a competing product in the market?

By analyzing competition, thinking forward and having a vision. Are developers supposed to only think on the benefits of mysql vs postgres?

> Most PMs are mostly concerned about what should be built to create a valuable product for customers, that provides healthy stream of revenue for the company. Most developers are concerned about how it should be built. That is a completely different responsibility.

Let me float a crazy idea out there, I hope it doesn't sound too far out, I am just trying to dream out loud. Because I believe that if we dream big, then everything is possible.

Hear me out... How about, maybe having developers concerned BOTH about what should be built and how? I know this is too radical, and we would probably need first to have that notion reconciled with mainstream physics, mathematics, and fluid dynamics, but it's just a crazy thought I've been having.

Just imagine a universe where engineers not only execute instructions from people with suits, but actively decide what to build themselves. Of course, that's science fiction and can't possibly be achieved, but just imagine!

P.S Sorry for the patronizing tone. I just think the industry got it really wrong as a whole, and that we can build far better things and far easier if we treat engineers as adults who know what they are doing. The existence of a PM (or PO) role for me is the opposite of treating devs like adults.

It also sounds like you have a PM on your team, but they actually have the title of SWE or Eng. Mgr. They probably spend > 50% of their time on the above listed responsibilities rather than engineering. Hopefully they don't get docked in their performance reviews for essentially performing the duties of a PM rather than those of an engineer.

> Performing the duties of a PM rather than those of an engineer.

The duties of an engineer are to know what to build, prioritize it against their other work, and build it, alon with the other engineer in their team. If you consider the "knowing what to build/prioritize" as PM work, so be it. I consider it engineering work.

But if the product and the users are alien to the developers then this is a recipe for poor UX and value (eg: building an accounting product)

You are comparing paid labor to unpaid labor, not a company with PMs vs a company without PMs.

There is no panacea to hiring and retaining good engineers, all I am arguing is that the money spent on a PM is much better spent as Christmas bonus to the engineering teams.

However, if you believe that what takes building great products is an unqualified semi technical person with a made up role and title who doesn't do any work themselves but passing messages back and forth and strutting around like a peacock calling all the shots, be my guest.

(By “designing” I mean like, designing it in the large, what does it do, not UI design or something. Though of course the same goes for pixel pushing.)

If they're at least very detail-oriented and can effectively lead sprint planning or whatever the equivalent is at your org, much chaos and indecision can be avoided.

They get bonus points if they're good at shielding dev teams from office politics and committing everyone to a firm schedule free of sloppy requirements or loose due dates.

Product Managers as they have become today (from my experience over the last decade+ in 7 companies) are far too involved in technical decisions (on which they most often have no clue about) and far too little involved in talking to real customers.

In the olden days (the 90s for me) we had people whose job was to track the pulse of customers to see what they needed and provide that feedback in an organized form to engineering leadership. At least in the companies I was in, their title was not PM (can't remember their exact title).

That was very useful, it gave engineering leadership a clear view on what customers like and what they hate and what they want in the next release. And it was not interference, as these people had zero say in engineering decisions.

Today the average PM is just meddling in technical decisions they are not qualified to have an opinion on and most of them don't really spend enough time with customers, their product direction is all based on their personal (largely uninformed) opinion.

Maybe there are still companies that do the PM role right, but I haven't met any.

Similarly, if one is building a consumer app where back-end, infra are 'solved problem' but user experience needs to be differentiated, only engg team would not cut it (designers would be needed).

If your product targets customers outside of the IT department, it's a whole different picture.

My product is utter crap. As an example, 2/3 of the code moves data from Oracle to JSON to MySQL back to JSON to PostGres to parquet that just reconstructs the schema of the original Oracle tables. It is fragile as fuck and the "architect's" proposed solution when I joined was to throw Redis in the mix. Customers hate it because it's always breaking down and has massive requirements.

I went to war with him, pointing out how absolutely asinine the whole thing is. Turns out, he was already on an RIF chopping block along with several other engineers that contributed to this mess. I just pushed it over the edge. When he left, I discovered one of them basically came in in the morning, logged in to customer sites, launched four screen sessions at each customer and tailed -f logs all day, manually restarting when their own shit code went down.

This is what happens when you get out of developer's way and let them build in peace.

For what definition of success, and at what point in the product lifecycle?

I've been on teams as you describe. They were great - as long as nobody had to deliver a working product and you were just running out runway until the next gig. They were also great when the product was already built and we were just KTLO and deliver some new features once in a while. But I haven't seen such teams deliver a product from initial idea to PMF and sustainability.

Here's the reality I've seen: PMs and EMs share a very similar domain of responsibility. The "20% work" of both jobs is different; but 80% of it isn't; its communication and defense from the rest of the business, and organizing the work the engineers need to actually do. Who actually does it, in your org, the PM or EM, depends on who has more political capital between the two, which is something of a function of their skill level, experience, and ability to market themselves. Great EMs look like PMs. Bad PMs do all the bad things bad EMs do, like micromanage.

Phrase that paragraph another way: in most orgs, in my experience, the PM role fills a need which arises when the team makes a sub-optimal EM hire, and vice-versa.

That's my reality; but the obvious problem with that reality is, if you look at the scientific, hypothetical definition of what a PM should do, its not that. There's tons of more product-focused "we want to build the best thing" kind of work that feels, to me, rare for even Fantastic PMs to actually get to do because they're compensating for an EM that isn't pulling their weight. Vice-versa, if you have a Bad PM it might not even occur to them that this "we want to build the best thing" class of work is a fundamental part of the role; ZIRP document factories that could basically be replaced with an LLM trained on all the meetings they've attended.

The additional lingering problem is that, part of that 80% work, "defense against the rest of the business", depends significantly on the rest of the business stepping back and creating an environment where this "unit" (the EM, PM, and engineers) can be autonomous; and I've also nearly-never worked anywhere where this was the case, even leadership that says "its y'alls call, you've got authority in this domain" inevitably catch wind of some decision they dislike, for reasons rarely more substantiated then "it feels wrong", and even a small number of torpedoes like that can seriously, seriously harm an entire team's feeling that they're allowed to go on of the offensive, rather than playing defense 24/7.

Point being: The single best characteristic of upper leadership, its not close, there's zero argument of this in my mind, its not technical ability, business experience, good talking skills, domain experience, whatever: Its Hiring. Being able to identify strong talent, keeping a pulse on the performance of that talent, ground-truth, all the time, and being willing to let people go if mistakes are made. But, what I've just described is extremely difficult to execute effectively, because every actor in this game is self-interested and will actively misrepresent the performance of themselves and their unit; politics is the hardest game in the book.

35 years in the semi industry. I must be stupid. I really don’t see politics. I see people trying to argue for their option and get support. But I’ve never seen this politics that people complain about. I’m so lucky I guess.

Is politics just someone making a better argument that is the wrong technical decision? What is “politics”?

Or am I just not at a high enough level (senior principal)?

Politics is also when middle managers and 2 engineers conspire to steal a coworkers work to get promoted and move up the silicon valley startup ladder, so that the company has to come back a year later to bring back the original engineer, because none of these people were capable.

If you haven't seen politics you might have been either blessed or didn't want to see it, but for every 1 company I worked with that was efficient I worked with 4 that were not.

But when I say gravitate away from hard work towards playing politics it refers to something else of course. Getting others to do your work while still claiming credit is one example.

I understand that what people typically mean is people who are “too political” where the pushing for interests stops being in service of some goal and starts to become its own point. But in trying to avoid the appearance of that, too many people fail to engage in any politics and in doing so actually cause more harm than good to what is important to them by missing the important point that it’s incumbent to speak up for things you need and believe in because people who allocate resources may have insufficient knowledge or insufficient time to dedicate to knowing your work that intimately.

It typically doesn’t stop being in service of some goal, but rather becomes entirely self-serving.

I think of politics as useless bickering that doesn't advance the project. Usually it is self-correcting for the reason above. I've seen a lot of bad decisions drive company's stock into the shitter, but I think of that as simply the "wrong" decision.

Shit, I think I -AM- blind. Hmm....

My boss, whom I will call Boss W (who spent a lot of time maneuvering people around) had first worked for my previous boss, Boss F. Boss W, I think, spent more time playing chess than anything else. First he worked out a situation where he was peer to Boss F, then, with another coup, managed to get Boss F working for him.. Still not satisfied, he managed to change to whom the department reported to from Uberboss J to Uberboss C.

Uberboss C, who was peer to another administrative type, Administrator W, was eager to prove the value to the change. And so I was tasked with developing a product rather similar to something that Administrator W had at his previous job. The product itself was politics, in that it presented to a group of stakeholders about a thousand to three thousand items to decide the disposition of. But this was futile, really, because we had about six hundred thousand items to have reviewed, so we would never actually get anywhere with presenting this to the stakeholders. But they wanted it and so ...

And so I was told that this was going to be an Agile thing, and I had until the start of the semester to have it done, and they needed to see a fully-featured prototype (a contradiction) right away. Although promised, I never got to meet with the internal stakeholders who would present this product to the external stakeholders who would do the disposition.

That's quite a tight deadline, but it gets interrupted because to prove value to someone else, I get sent on a week-long conference doing something utterly unrelated. They just wanted to prove to the guy running Dept B that they were going to have someone in the mix for his technology.

Despite this and catching a tremendous cold, I managed to have something developed by the start of the semester, because it was so very very urgent.

And then it was not shown to the internal stakeholders for seven months. All o that hustle! So Agile much wow.

Many developers are more passionate about technology itself – coding, solving complex technical problems, and creating efficient solutions. Their formal rewards (like promotions, bonuses, and recognition) are often tied to technical achievements. If a developer spends 40 hours on customer research, this effort might not be as formally recognized or rewarded as much as a technical achievement like developing a new authentication solution that benefits the entire team.

Shifting this dynamic is not just about encouraging developers to spend more time on product management. It requires a systemic change in how organizations value and reward.

Changing the incentive structure to be more user-centric and less technically focused would significantly impact middle and upper management roles. A shift would challenge the very foundations of their roles and responsibilities, potentially leading to a loss of control and influence.

It's likely that such changes would face subtle yet strong resistance from middle and upper management. These individuals often have significant political power within an organization and a vested interest.

Every software engineer worth their salt has a certain degree of pride about doing things well. If this only ever is about the code, the commit history or other abstract concepts, but never about how well it can be used by the actual people it was made for, then how would they even start caring?

When they tried to demonstrate the bug, it was immediately clear to me what the issue was. That was the first time I really grasped the difference in how we approach software products. It also helped me see how the product could improve their job by watching how the process was in real life. Gave me a lot of ideas on how to make their job easier by using the product.

Just seeing the moments of hesitation, how the mouse is moved while searching in menus, etc gives me a lot of information.

Even if I show them a couple of times, it is often quickly forgotten.

For me as well. I've started my "career" this way, building something very specific for a client (family member) whilst being on prem and having constant and direct feedback, so that's how it was done I thought.

Almost twenty years later, having worked different roles with teams in office and remotely, I have to remind myself, and others around me, that we are building something to be used by real people with real problems and my/your software must not be one of them.

Never before have I heard such a good argument for formalizing the job. If architects or civil engineers were to do the same we had building collapsing left and right.

I'm all for AI art, it's an incredibly valuable tool - but if your using an AI piece as the only image on the page, it should be for a damn good reason, not just space filler. Especially when you can't even curate the image generated well enough to have every person in the image have the correct number of fingers.

The image is meant to convey a feeling. It is meant to make an abstract concept from the article a little more tangible.

In the past, I'd search for images on the net that I could use to accomplish that. Now I can craft them with DALL-E, and they are usually much better.

This image should complement the article. Just like the text of the article is meant to convey some information, feeling, or concept, the image should do a bit of that as well.

But there's something funny about this. The blog template requires an image bucket, so mindlessly fill it with something, right? Too hard, so find a bland stock photo. Too hard, so purposefully generate a bland stock photo. Uninspired tasteless AI garbage is going to overtake everything in short order.

I like how one of the tablets seems to devolve into a paper notepad at the bottom, and how the notebook display on the right seems to be transparent and twisted.

Here's an article on selinux, bit first an image of a leaf.

Yeah DALLE-3 has this in the system prompt.

> Diversify depictions of ALL images with people to include DESCENT and GENDER for EACH person using direct terms. Adjust only human descriptions.

> EXPLICITLY specify these attributes, not abstractly reference them. The attributes should be specified in a minimal way and should directly describe their physical form.

> Your choices should be grounded in reality. For example, all of a given OCCUPATION should not be the same gender or race. Additionally, focus on creating diverse, inclusive, and exploratory scenes via the properties you choose during rewrites. Make choices that may be insightful or unique sometimes.

> Use "various" or "diverse" ONLY IF the description refers to groups of more than 3 people. Do not change the number of people requested in the original description.

> Don't alter memes, fictional character origins, or unseen people. Maintain the original prompt's intent and prioritize quality.

> Do not create any imagery that would be offensive.

> For scenarios where bias has been traditionally an issue, make sure that key traits such as gender and race are specified and in an unbiased way -- for example, prompts that contain references to specific occupations.

I wonder what not telling it to avoid altering unseen people does.

1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launch, watch for snags, provide support and solutions to users.

2. Communicate gathered feedback to engineering, and do so with an understanding of where the project is engineering-wise, where it is going, what needs to change. Give engineering the "why. Convey the priority of everything the project needs vs what it has and what is being worked on.

Repeat this feedback loop.

But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

Requirements gathering, mean user upset about a bug, weekly status call, need to break some bad news re: priorities? - send a senior dev or tech lead. Skipped most of the agile ceremonies too, busy guy. Never wrote or edited a JIRA ticket, that was for tech org to manage. He PMd 2 other tech teams the same way.

Tech leads/senior devs knew our PM was bad news from his first week but he outlived all of us until finally getting hit with a RIF after 4 years.

Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs.

I'm with you that all of this is bad PM work, but this seems to be the root cause. I've been at a startup like this where there weren't enough PMs to start and then a couple left, which just led to the rest being stretched across more teams.

You just can't do much of anything useful in this situation - your existence consists of preparing for and attending stakeholder meetings. I guess some people thrive on the pseudo-glorified existence of "managing" a bunch of different teams, but I found it to be as miserable as you seem to have found it from the eng side. I was there to spend time with customers and designers and engineers, and after a few months of doing none of those things, I quit without a job lined up.

Once you get to that point, it can become even worse because you end up in this doom loop of management realizing that the core PM work is getting delegated to eng, thinking that this means they don't need as many PMs and then delegating more work to eng.

At least that is better than eng doing the PM work and the PM getting all the credit for it.

Yes. If a team is incapable of either doing their job or in advocating for needing more resources to do their job, then they do not get to have more resources. Particularly when another team is covering for this gap, typically, engineering.

It never goes the other way right? How many times are PMs picking up JIRA tickets, handling bug fixes, joining on-call rotas, etc type tasks that engineering does?

If non-engineering roles/orgs are created to take load of engineering, and are incapable of doing so, then they need not exist. This goes for DevOps/CloudOps/SRE/Support/QA/Product/Project Mgmt/etc.

You can run a lean startup consisting entirely of 3 engineers. But you can't run a lean startup consisting entirely of 3 SRE/QA/Product/whathaveyou.

This is not a knock on these other orgs/roles. In a well functioning shop, they are essential. But when orgs like Product forget that the tail doesn't wag the dog.. bad things follow for everyone.

Beautifully put!

Ok, maybe I came to the wrong place to say what I'm gonna say because I guess that a sizable part of the demographics here works in hot, meaningful projects, but as a corp worker for the last 8+ years, it has been my experience that a lot of companies have products that are used either internally by their own employees or by another corporate client that still pays for them out of inertia or because there is just too much custom business logic that now it's too costly to replace them.

In both of these cases we're talking about uncompetitive products that are probably going to remain so before being discontinued. And in both of these cases companies will try nonetheless to create a SCRUM-like arrangement with PMs and POs and behave like they are building a revolutionary product, urgent taks and pressure for results included.

It has also been my experience that in this kind of environment normally PMs and POs will be fully invested in doing politics to try to climb up the corporate ladder without much concern about what makes a good or usable product. They will steer the project in whatever direction makes them look good to the administration or the client at the cost of creating a fragmented product that many times looks like it's doing a random walk in terms of functionality and improvements.

I'm not old enough to know how things were built in the 60's/70's/80's(no SCRUM/PM's/PO's I guess) but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.

Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern

With software I guess part of the problem is that there's a lot of diminishing returns, with it being much easier to just crank out some initial prototype that does a lot, then it is to adjust some spaghetti mess that users deeply rely on. But that should only really affect individual projects, not necessarily the industry as a whole

It's not exactly a new idea:

> The term "software crisis" was coined by some attendees at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany. [1]

As you can see, people have had the perception that it's harder to crank out software than before for a long time now. The reality is that we're collectively vastly better at it than we used to be, and that what we're trying to do gets harder and harder. No one is paying for the kind of productivity software dev had in the 2000's, and no one will be paying us 20 years from now for doing what we do now. Except if maintaining older software that yields value - in which case, well, maintaining and expanding a brownfield is always harder than greenfield.

[1]: https://en.wikipedia.org/wiki/Software_crisis

It's a wider pattern in fact:

"The productivity paradox, also referred to as the Solow paradox, could refer either to the slowdown in productivity growth in the United States in the 1970s and 1980s despite rapid development in the field of information technology (IT) over the same period, or to the slowdown in productivity growth in the United States and developed countries from the 2000s to 2020s; sometimes the newer slowdown is referred to as the productivity slowdown, the productivity puzzle, or the productivity paradox 2.0."

https://en.wikipedia.org/wiki/Productivity_paradox

Lately, I've been responsible for mentoring other PM's. Sure there's the widely shared roadmap, but also -- I can't tell you how many documents and sheets are created that are literally never seen again by anyone other than me, and I get the feeling were created to demonstrate that they are working. It's a habit I try to break.

The reason I advocate for technical product management so strongly is I've (over)simplified the problem in my head to be that some PM's are stuck at that high level of abstraction because they're unable to communicate with their teams on the detailed technical matters on a daily basis. So they end up in a weird grey area of project/product management.

Usually it’s places where the projects are plenty small enough for the normal manager to handle it but they’re lazy and want the TPM/PM to be their secretary.

Yeah, I've had PMs who've ground backlog grooming sessions to a halt so engineers can explain in detail what each one is, or shared incorrect information about a bug fix or new feature to a technical writer for release notes because they were so confidently incorrect.

The PMs with enough aptitude to understand and explain what the engineers are doing, even if they're not actively participating in implementation because they're applying that knowledge to broader strategic/roadmap decisions and cross-team coordination, are the best to work with.

That sounds terrible and predictable. Data managed by a PM should be managed and presented in the same product dashboard used by everyone else.

In practice over the last year, I've seen product managers make Gantt charts in Miro as the source of truth for a project and run backend engineering retros in Figma. These were done redundantly with our issue tracking system; my cross-functional team had to create issues in our tracker based on the Miro and Figma boards to actually manage our own work, then duplicate the updates on those boards to communicate them up to product.

PMs get a lot of stick, sometimes justified, but they're just having to play office politics in order to get stuff done

How do you feel about the transition?

They are not managing product, they are managing stakeholders

Whereas a PM in a small company can devote more attention to the product, customers, market, metrics.

What's a good question to ask to find out which sort of animal you're dealing with?

That is to say, the only customer we could convert to a PM was one who was fundamentally bad enough at his existing client side job that he was OK capping his income at 25-50% of his potential.

It also doesn't give them any training in how to PM.

They should just be someone technical enough with enough people skills and familiarity with user use cases to bridge the gap.

Managers of any company that think they can't afford to lose a single employee are doing something wrong and should google "key man risk"

Unfortunately most product managers are just people who sit in the role. They are just gatekeepers who take either credit or blame. They often have little skin in the game.

Overall, if you have a product management organisation, you're doing it wrong.

Agreed, the best (and most successful) products I've worked on have all had product ownership by actual implementers (engineers, designers, customer success, etc). I loved being on the support rotation as an engineer because it closed the gap of abstraction between my work and the real humans who were using it every second.

Very rarely, I have worked with PMs who add net positive value, and in every case they would have made okay engineers as well.

I've found myself on both sides of this issue in my career and I've landed on it being a good thing to have a PM organization, assuming your entire org is large enough.

The main reason why is that when PM (or whoever plays that role in a team) reports up to the same engineering management chain, all things eventually bias towards the needs of engineering. Much-needed feature work that is likely to advance the business eventually always gets de-prioritized because there's always tech debt or infrastructure work that inhibits people in some way. Sometimes it's actually the right move to do that, but you need tension between two orgs that have equal chairs at the table to make that kind of call. That ends up not happening when it's a part of engineering.

Of course a lot of the sad reality in our industry is that separate PM orgs get to have more power than engineering orgs because they get to own "what's good for the business", and when you combine that with a bunch of PMs who know how to follow a process or framework but don't actually understand their own products or users, you get a nightmare.

How many frontend engineers to backend?

How many engineering managers to ICs?

How many technical writers to (all) engineers?

How many product managers to (all) engineers?

And I try and keep the ratios finely tuned to have the greatest impact but the least meddling, the least micromanagement.

What the numbers for these ratios are is likely specific to your organisation, but if you detect meddling or too much of the "how" not coming from the engineers themselves, change the ratios, increase engineers per people or product manager, make it so that they cannot do this and instead have to prioritise what they get involved in, to step back from the micro, and to cede autonomy on how back to the engineers.

PMs should also be a lot more focused on the business’ goals than most PMs are. It’s necessary but insufficient to solve problems for your users. Solving those problems needs to translate into value for your company too.

Strong, product-minded Eng/UX partners are essential in enabling that.

I'll say it depends on the size of the product. If you're dealing with say ERPs (Oracle Fusion Apps, WorkDay, SAP, etc), a PM can't own an entire product. Instead, they'll own multiple features where each of those features are complex in themselves and being ERP typically involve integration with multiple other products.

But I agree with the general thrust of your point which seems to be that the PM should own something 'significant'

Problem is, the org needs to support that, and in most companies, the work that gets the most attention isn't visionary or growth focused, it's whatever is making the loudest noise. Often that is in direct conflict with a product owner/manager's desires.

My experience is completely the opposite. PMs that don't understand the how, that is, they don't know how their product works, are the worst.

Best PMs that I worked with had a technical background.

Best PMs I worked with just figured out what users wanted and organized the team to build it through good communication. That's it.

Sometimes the technical PMs can be an issue because they care too much about the how and not enough of the why and what.

If your product is selling devtools to developers, then yes, it helps to have a technical PM. Case by case.

You want a PM that knows the product (really) well and brings new work to the developers in the form of well documented problems, not solutions.

You don’t want your PM to get involved in the technical details.

> not solutions

Often yes, solutions. When you're still in the "what are we building" phase you want a good PM deeply involved in the process. I think you may have implied that, but solution creation happens before code gets written.

You also sometimes want a PM to get involved in technical tradeoffs when they impact the user experience. I've found that this happens more often with a technical product (API capability or SDK interface) than a UI screen, but it comes up. When your PM is the expert in your userbase and how they expect to use something, they need to be involved a lot.

It may include knowing technical weaknesses and strengths in the energineering teams abilities and their plattforms abilities and weighing that in for planning and priorities. In reality development in product that are over the teams abilities may lead to a real mess.

When people try treading on other patches, it always ends in disaster. That works both ways: engineers are lousy at the "Why?" and the "What?" because they think too much in terms of "How?"; and yes, product managers need to step away from the "How?" unless it's to clarify the "What?" or the "Why?".

Of course there needs to be communication and context, but when engineers start to try and direct the "what" or the "why", it becomes as absurd as PMs trying to dictate the "how".

There's no one to balance the complexity of building this vs the gains achieved.

I think best engineers would be people who also use the product and can give their own insights on this, as well as best PMs are someone who have good knowledge of the technical background and context.

It's a team sport, there needs to be communication, but there also needs to be clear areas of ownership.