261–270 of 286 posts
Earlier quoted context omitted.
In software/tech world, PM's customer are often internal stakeholders, often not all relevant ones. Very rarely company's customer. PM juggles internal issues like milestones, priority, resources, budgets and even some politics.
Yes. This is a redefinition of a role though, this should be called Project manager.
Earlier quoted context omitted.
The general rule though is that the clients are asking for X, actually need Y, and get delivered Z - isn't it?
That depends on who the clients are, and why did they hire you. If you're just a subcontractor in an org run by smart people, it may very well be that they're asking for X, actually need X and expect to get X - they just outsourced the boring work to you.
Earlier quoted context omitted.
The general rule though is that the clients are asking for X, actually need Y, and get delivered Z - isn't it?
Absolutely. https://www.zentao.pm/share/treeswingpm-97.html captures the reality very, very well.
Earlier quoted context omitted.
Until you come to the realization that most developers are “dark matter developers” doing yet another software as a service CRUD app or bespoke app that will never see the light of day outside of the company. At the end of the day, if you got hit by a bus, your company would send flowers to your funeral and have an open req for your position before your body was buried.
> At the end of the day, if you got hit by a bus, your company would send flowers to your funeral and have an open req for your position before your body was buried. Which is exactly what I expect them to do. Its a business and not a family. They compensated me for my work, I don't expect them to cry for me when I'm gone, but to hire someone immediately to continue the business.
Earlier quoted context omitted.
I'm not following - Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?
> in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X This is misleading, you should not be refactoring some other random code. You should be refactoring the code you are adding to/changing as part of the work. And it should be in proportion to the size of the change.
Earlier quoted context omitted.
There are lots of bad actor reasons (putting career advancement ahead of product success), but there also structural issues that can lead teams to operate this way. The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does. Usually this looks something like a sales person hearing from a couple of customers “we really need…
I hear that these situations exist, yet this is the complete opposite of what I was taught, which is that (at least !) the project manager had to have frequent and direct contact with the customers starting from trying to figure out what their real needs are - for the project to have any hope to succeed?
Earlier quoted context omitted.
Aha, I see why there’s been pushback. To be more clear: I only want to see the balances from specific accounts. The two chequing accounts in this case. I don’t want to see the savings account that has a slowly (and automatically) increasing balance because then I subconsciously count that as “too much” and think things like “I could spend a little and it wouldn’t make a big difference”. To be fair, I’m also working h…
Really off-topic here, but for savings accounts that are going to tick up over time and don’t need to be available within 24 hours, you can open a savings account with a different bank that has better savings interest rates and set up an automatic or manual transfer to that savings every month. You can shop around for the best interest rates, but I’ve seen Ally be consistently better than anything I have locally. The…
I just looked and there are other options available. I think this might be the excuse for me to go to Wealthsimple and start taking a more active role in making that money do some work.
I suggest re-reading this article in the negative: Assume that your team implemented every single one of these bullet points perfectly, for every feature in every sprint. Now imagine that each of those bullet points is a recurring meeting invite on your calendar. Now imagine how happy you'd be spending all of that time in meetings or reading process-related e-mails so your company could satisfy the criteria of not be…
I’ve worked in both a company that would score a perfect 12 (5 employees) and one that scores a zero (10000+) employees. The first definitely knew what things weren’t working, and tried out new things all the time (which also didn’t work). The second has no clue if new things are working (or at least, nobody bothers to inform me), but they’re quite successful. It feels a bit unfair.
I had a similar eye-opening experience. I worked for a company that insisted on doing everything the right way, with mountains of process, planning, metrics, measuring, followups, reviews, and customer feedback. It sure felt like we had the recipe for success, and it felt like we were checking every item on this list. We always felt super busy, as if we were doing important work every minute of every day. Yet it took us forever to ship new features, and the onerous planning, review, and feedback requirements turned into planning gridlock.
I then switched to a company that focused on quickly shipping features above all else, only measuring feedback with random sampling of customers and spot checks of quality. All of our customers loved the company because we could deliver their features quickly, and they could always see that we were moving the product in the right direction.
It's difficult to communicate the stark difference between these two environments unless you've seen both sides of it. It's even more difficult to convince engineers that the process-heavy, data-driven approach isn't necessarily the best way to run a business.
I suggest re-reading this article in the negative: Assume that your team implemented every single one of these bullet points perfectly, for every feature in every sprint. Now imagine that each of those bullet points is a recurring meeting invite on your calendar. Now imagine how happy you'd be spending all of that time in meetings or reading process-related e-mails so your company could satisfy the criteria of not be…
Ultimately it isn't an engineer's place to complain if they're working for a product that needs 100 more features to succeed in a competitive marketplace and win over customers. I had the exact same reaction as you to this article after seeing it again, and wanted to share why I've also changed my mind on this. I was in "a feature factory" for few years and absolutely hated it. After leaving and going to a "not-featu…
But the only metric the manager cares about is how many blocks per week we're pumping out. And that's why we'll never get along...
https://www.crunchbase.com/organization/pendo-io#section-fun...
Eventually pendo.io accumulated $208.3M in funding.
2) John Cutler now works for Amplitude (pendo.io competitor) that received $136M in funding: https://www.crunchbase.com/search/funding_rounds/field/organ...
3) Amplitude looks more successful than pendo: