51–60 of 130 posts
Now. Where can a 57yo idealist find a job in today's world?
I got stuck on the first one "Product Manager". Do the newer companies have this role? I mean, for the companies that are consumer facing and not enterprise oriented. IMO, this is a spillover role from the enterprise heavy 90s/2000s into today. Am I wrong?
As your company grows, it easily becomes a full-time job, if not a full team. It has nothing to do with 'Project Managers' from the 90s. It actually is not about project management at all in many cases... the engineering teams run their own processes. But it is about making sure they are solving the right problems, at the right time, in the right way. (Meaning, correct consumer experience... Product Managers should not be telling the engineers what to do on the technical side.)
Where is the category for devs that will weasel out of any work by claiming a ticket is out of scope, or that the responsibilities for handling a certain piece of work lies with some other team, or that you should go through the project manager so that the work can be done 5 sprints later?
Earlier quoted context omitted.
I spent about a decade as a PM at startups, so I can definitely attest they do. Obviously I'm biased here, but the PM role isn't just some spillover, it's work that needs to be done. Someone has to talk to stakeholders, gather and document requirements, work with customer-facing teams on launches/preparation/etc. and so forth. If the product manager isn't doing it, then engineers are doing it, which means they aren't…
From my experience PMs serve one true purpose well. That’s reporting to the higher ups (execs building a moat) and being a single point of contact for the devs. Everything else is red tape. Gathering requirements is hard and a PM digesting it first is never optimal.
This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…
I'm pretty sure it's supposed to be at least somewhat humorous/tongue in cheek. I can certainly recognise the tropes both in myself and in others.
It's just kind of fun, and I'm certainly not planning to take any of its advice that seriously.
This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…
If you meet an asshole in the morning, you met an asshole. If you meet assholes all day long, you’re the asshole.
I think its a great Illustration of the different problematic behaviors you encounter when you work pretty much anywhere. However, the solutions although quite straightforward and make sense, in real the situation is not so simplistic. For e.g. you have the dictator PMs that refuse to do anything that didn't come from them. The solution is to have the upper management talk to them. In my work, we have a PM who is lit…
I think its a great Illustration of the different problematic behaviors you encounter when you work pretty much anywhere. However, the solutions although quite straightforward and make sense, in real the situation is not so simplistic. For e.g. you have the dictator PMs that refuse to do anything that didn't come from them. The solution is to have the upper management talk to them. In my work, we have a PM who is lit…
If the dev team reports to a non-technical PM, your organization has bigger issues than just a rogue PM.
Earlier quoted context omitted.
From my experience PMs serve one true purpose well. That’s reporting to the higher ups (execs building a moat) and being a single point of contact for the devs. Everything else is red tape. Gathering requirements is hard and a PM digesting it first is never optimal.
I'll second that. Any time I've seen PMs involved in dev work (like requirements gathering) it's a shit show. PMs can usually have shallow conversations about software, but not deep enough to do requirements gathering.
Requirements gathering is the main job of the PM, and it's most definitely not technical (or at least not remotely to the level of technical knowledge required to actually write code).
For example, a PM at Twitter defined that Tweets should be 140 characters (at least in the olden days). That's a fundamental requirement of the platform, but it's related to the company's objectives, user engagement and other things that have nothing to do with writing the code. There's zero reason that engineers should have anything to do with that. Once it's been decided that Tweets are 140 characters max, then that requirement gets handed off to the engineers to actually do the development.
Obviously all oversimplified, but the point is that if you think requirements are technical, then you're probably dealing with bad PMs who aren't drawing them up particularly well. The irony is that when this comes up, it's usually because the PMs used to be engineers and don't have the experience to separate the two roles.