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 being a feature factory. Does a feature factory sound so bad now?
I thought this article was great when it first came out, but I've since changed my mind. I've seen too many engineers, especially junior engineers, become overly cynical about their jobs after reading too much into this one article.
1) With 12 different "signs" of a feature factory, it begins to read like a horoscope: Almost everyone reading it can find something to identify with. Multiply this across every different project or initiative at a company, and everyone can think of multiple times their job has resembled the descriptions in this article. Does anyone actually read this article and walk away thinking their company has never once resembled the vague signs in the article?
2) It begins with an implied assumption that working in a feature factory is a bad thing. Combine that with the horoscope-like 12 possible indicators of a feature factory, and the reader will always conclude that their workplace is the bad thing.
3) It sets unrealistically high standards. The alternative to a "feature factory" is defined in the negative in this article. Can you think of any company that would score a perfect 12/12 on every bullet point in this article across every team in every department? The process overhead would be significant, and it would very easily translate to a lot of meetings, e-mails, and overhead.
The kernel of truth within the article is still very valid. Teams should absolutely take the points into consideration and apply them judiciously, where it matters. However, it's a mistake to use this article as a checklist by which to judge your company's process. Real work is always a bit messy, communication is never perfect, and just because you don't see these things with your own two eyes doesn't mean they aren't happening somewhere in the company.
As a product manager, suggestions are always welcome and I'm happy to discuss reasoning for decision making, but I also don't burden the entire team with every detail of every step of the way.
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.
> 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!?
I 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.
I 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.
Pyramids 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.
And 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...
What 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!
Fortunately, the author wrote a great many other articles that go far further. It seems to me like the article is fine for what it is, it's just calling out a problematic pattern that commonly exists. It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points. He instead writes lots of other articles dealing with the nuances of how to do better.
But it also sounds that you're worried about engineers constantly challenging product manager's decisions? I don't think that's the implied end state. Engineers don't see all the input to PM's decisions, and yes it would be more comfortable for the PMs if the engineers just trusted them to get it right all the time. But we (I'm an engineer) aren't dumb. We know nobody gets it right all the time, and we don't expect you to. But if we never learn which things worked out and which didn't, and some of the why, then what you're asking for is faith, not trust.
You don't need to include engineering in the decision making (at least, not more than you need for feasibility and cost estimates.) You do need to include engineering in the feedback loop, because we're not dumb monkeys whose only value is in realizing your vision. We know more about what's possible, and how to overcome some types of challenges with relatively little effort compared to the cannon that you'd need to (ask us to) build.
> But it also sounds that you're worried about engineers constantly challenging product manager's decisions?
No, that's the exact opposite of what I said. In fact, I explicitly ended my post with a call to action for engineers to communicate concerns, suggestions, and questions to their product managers.
> It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points.
That's my point: The article seeds this unrealistic idea of an over-idealized product management process that explicitly includes the reader at every step of the way. It manufactures an anxiety in the reader that a feature factory is a vaguely bad thing and if you recognize any of these 12 vague points, you're working within the bad thing.
Again, my problem isn't with the core suggestions to improve PM process that might be elaborated in the author's other posts. My problem is with the trend of people reading this article, finding some point to identify with somewhere, and erroneously concluding that their employer is doing it wrong and that's a bad thing.
My point was that if you want to be involved in the decision making process, provide feedback, or understand the reasoning behind the decisions you should be proactive about communicating. Instead, I see too many people reading this article and passively becoming disgruntled with their employers, without taking any steps to be more involved. Or the more they are involved, the more the complain about too many meetings, interruptions, and process overhead consuming their time that they'd rather use for quiet focus to get their work done. You can't have your cake and eat it too.
> The second has no clue if new things are working (or at least, nobody bothers to inform me), but they’re quite successful.
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 don't think the article is saying engineers need to have a meeting for each of these. I think you're entirely missing the point.
It's simply saying that you measure before you build a feature [and again after]. Any good product owner will already have data to support their prioritizations (e.g. this bug affects 10% of users, this feature only applies to 2% of users)
> I don't think the article is saying engineers need to have a meeting for each of these.
I think you've missed the point of my comment.
As I said, the core principles of the article are not wrong. It's the framing of the article that causes problems.
When engineers and other ICs read this article, they tend to assume that these planning sessions, feedback loops, retrospectives, and other mechanisms aren't happening because they don't personally see them. That's why I pointed out that most engineers wouldn't be happy if they were pulled into every single planning, retrospective, and feedback meeting that the product managers are doing. I'm not saying they're bad, I'm just saying it's bad to assume you work in a terrible feature factory if you don't see every item on this checklist.
This goes both ways, of course. It would be silly for product managers to read an article entitled "12 Signs You're Working In A Code Factory" and then start second-guessing all of their engineers' decisions or assuming the engineers aren't implementing proper process behind the scenes. That type of article would generate outrage on HN, but engineers second-guessing product management is always well-received in an engineer-centric forum.
>> When engineers and other ICs read this article, they tend to assume that these ... mechanisms aren't happening because they don't personally see them
I think you're missing the second point of the article here. Per the article point 1 "Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work worked"
So the article is also highlighting failure to share as a failure mode. Every good company I worked at, I [the lead engineer] had equal ownership as my product owner. The respected my opinion, learned not to doubt my warnings, trusted my intuitions, and made adjustments based on my recommendations.
That balance of shared ownership is a defining indicator that it's not a feature-factory, whereas a "I call the shots as product" mentality is more feature-factory.
Is it possible you [rightly] worry about this article because you are what it's talking about?
Organizations where individual contributors are respected find ways to communicate what's discussed in those meetings. I wouldn't want to be a manager in an organization where engineers can assume those meetings aren't taking place.
Most of the points in this article are relative, for instance what does it really mean to have no care for technical debt drawdown? How much care is not enough? However, one thing that it's specific about is the lack of measurement. There are some companies out there that have zero focus on customer feedback, and since there's only one zero, that indictment is not relative to people's expectations.
> There are some companies out there that have zero focus on customer feedback, and since there's only one zero, that indictment is not relative to people's expectations.
No company has zero focus on customer feedback, but the company may not be taking the feedback through channels that are most visible to you.
One of my most eye-opening experiences as a product manager was realizing that the most important customer feedback was not from the vocal customers complaining loudly on social media. The most important customer feedback was number of new customers signing up and their retention rate. To my naive surprise, chasing the feedback of the loudest complainers and detractors rarely turned them into proponents, and was even less likely to turn them into paying customers.
Someone, somewhere, is always making decisions according to customer feedback in some form.
I thought this article was great when it first came out, but I've since changed my mind. I've seen too many engineers, especially junior engineers, become overly cynical about their jobs after reading too much into this one article.
1) With 12 different "signs" of a feature factory, it begins to read like a horoscope: Almost everyone reading it can find something to identify with. Multiply this across every different project or initiative at a company, and everyone can think of multiple times their job has resembled the descriptions in this article. Does anyone actually read this article and walk away thinking their company has never once resembled the vague signs in the article?
2) It begins with an implied assumption that working in a feature factory is a bad thing. Combine that with the horoscope-like 12 possible indicators of a feature factory, and the reader will always conclude that their workplace is the bad thing.
3) It sets unrealistically high standards. The alternative to a "feature factory" is defined in the negative in this article. Can you think of any company that would score a perfect 12/12 on every bullet point in this article across every team in every department? The process overhead would be significant, and it would very easily translate to a lot of meetings, e-mails, and overhead.
The kernel of truth within the article is still very valid. Teams should absolutely take the points into consideration and apply them judiciously, where it matters. However, it's a mistake to use this article as a checklist by which to judge your company's process. Real work is always a bit messy, communication is never perfect, and just because you don't see these things with your own two eyes doesn't mean they aren't happening somewhere in the company.
As a product manager, suggestions are always welcome and I'm happy to discuss reasoning for decision making, but I also don't burden the entire team with every detail of every step of the way.