5 ms·
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 wi
by lsalvatore 7y ago
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-feature factory" AKA "employee-happiness machine", I miss the feature factory.
Imagine you're building a Great Pyramid with 100 workers. The workers can't see the Pyramid and don't care about why a Pyramid is important. Is there time to explain to each worker exactly why they're moving a specific block? What about time to "review" why that one block didn't fit?
"Real work is always a bit messy"
Would you care about anything else other than how quickly each block got into place? The Pyramid can only be completed when all the blocks are in place, and most importantly- each block doesn't have to sit perfectly, and also, you can get by without ever delivering a "perfect block".
This is why product managers will never be 100% aligned with engineers. Product managers see "is the block there" and engineers see "is the block perfectly set" and "why am I not being appreciated?" and "why do they only care about putting down blocks".
It's bizarre to read how this person is so opposed to "up and to the right", that's the key indicator of you business and what will pay your bills. Yes, everyone is always going to be obsessed with revenue and you will never stop hearing about it.
Of course as an engineer- Resolve tech debt. You have to. But from the view at the top, it's a very temporary detour and needs to be resolved quickly so they can continue pumping out features.
Yes, I am making the analogy that engineers should accept being a "slave" to the product manager, or more directly, the product itself.
- narak 7y agoI think a lot of people are missing the point of the article. It's not anti-feature. It's against building features that have no measurable impact to the real goals of any business: better product for the customer AND therefore more revenue. The problem with the Pyramids analogy is that the Pyramid was the goal. In software companies, features aren't the goal. Better products for customers are. The right features are the means to the end, everything else is a waste of time and an illusion of progress.
- loopz 7y agoWhat actually happen is: There are multiple pyramids. Sometimes 20-30 pyramids being built simultaneously. Then priesthood comes up with their own tasks, and add random initiatives at random intervals to the load. There's also certifications and external verifications/revisions, each time a big surprise. The blocks, pyramids, tasks are often unfinished or neglected after completion. Because nobody has time to make proper utilization of it all!
- underwater 7y agoI think you are more aligned with the author than you think. A feature factory is bad for the business not because it's not "fun", but because resources are tied up producing huge amounts of work that don't really matter. Kind of like a civilization using its vast resources building giant piles of rocks in the dessert because that's what they've always done.
- lazyasciiart 7y ago> This is why product managers will never be 100% aligned with engineers. Product managers see "is the block there" and engineers see "is the block perfectly set" and "why am I not being appreciated?" and "why do they only care about putting down blocks". I just want the damn PM to be able to tell me where the block should go instead of fucking around with bullshit vague descriptions like "the block should be in a good place". And after I get instructed to place a block midair somewhere, I'm going to want the PM to show that he actually decided "where" based on some kind of information and not by throwing darts. It is also totally reasonable to expect that someone is looking at each block as part of the overall goal, and identifying that those blocks which were just placed on the ground next to the pyramid were a total waste of time. It doesn't have to be me - but if nobody is doing it, who says we'll end up with a pyramid at all!?
- Aeolun 7y agoI don’t have anything to add, but I really enjoyed your imagery. It also feels true. Especially building a block in midair. PM just doesn’t seem to realize the rest of the blocks aren’t there yet.
- alexandercrohde 7y agoPyramids are the perfect analogy to disprove your point. The pyramids were useless tombs that wealthy kings wanted because of religious beliefs. As an engineer, I have spent many months building features that were disabled/deleted because the measurements showed they were no good after release. Now, for the 1% of product managers who make the right call every time on their own, having an engineer participate in the discussion may be a burden. But in my personal experience, every product discussion I'm in I bring great value to.
- bcoughlan 7y agoAnd from the engineer's perspective the frustration is: We're so busy lifting blocks on top of blocks, that we don't have time to come up with better tools to do it faster. Also some of the blocks are triangles and this pyramid is 5x bigger than the last one and will probably collapse if not re-designed. The slaves are exhausted because they just finished working overtime to build the last pyramid you wanted, and in a given work day, half of them are working on patching up the other crumbling pyramids we built. 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...