Live data from Hacker News

Signs you’re working in a feature factory (2016)

cutle.fish

61–70 of 286 posts

Re: Signs you’re working in a feature factory (2016)

#61

Sigh... At some point, most healthy adults who are not living in terrible circumstances come to the mature realization and compromise that their job is largely to produce value for someone else, not to be the primary source of personal fulfillment, and they come to understand that there is dignity in being productive, if not creative. Be creative on your own time. Lead a civic group. Be a good parent. Volunteer at a…

> Change jobs if you must

Or if a new job can offer you a better deal. If these jobs are all interchangeable, then you may as well interchange them for what benefits you most.

Re: Signs you’re working in a feature factory (2016)

#62

Earlier quoted context omitted.

The problem is that, if you're churning out features without thinking critically about why, your work might not even change the company. I've seen engineers, teams, even entire departments spend multiple quarters being a net drain on the company. But they never noticed, because they kept consistently defining release targets and hitting them.

> churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.

> Why would anyone build features without any thoughts about their benefit?

> In practice you never know how a feature is going to work out

Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know.

This all boils down to having or not having a vision.

Some leaders have a vision and you can see the long-term goals, others (like Google) throw things at the wall to see what sticks then shuts them down. If you're not a monopoly, that strategy will not work.

Re: Signs you’re working in a feature factory (2016)

#63
Yes! Very well put together list because at my last role (in the same company) this was essentially what I was trying to escape and when I look at the work that team is doing, it’s not impactful or noticeable but the devs are always building some new complex thing that won’t even see the light of day once.

On my current team, feature building is the second to last step (right before a retro) because product development requires many non-coding steps to first understand problem. Some times, I believe it should be “problem solving” instead of “product development”.

Re: Signs you’re working in a feature factory (2016)

#64

Feature addiction is real. This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more…

I really liked Blizzard of Ghostcrawler era - he plainly stated that they listen to users carefully to identify problems, but do not listen to them carefully about the proposed solutions. And well - his design team got stuff mostly right.

Re: Signs you’re working in a feature factory (2016)

#65
I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement.

It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input.

There is a reason that the points in this article exist at all - because the alternative is actually worse!

Re: Signs you’re working in a feature factory (2016)

#66
I've heard this called 'being on the hamster wheel', you are running forward as fast as you can but not going anywhere.

I've had an experience where I dreaded the daily stand-up, it was all about 'story points' in a mad scramble to find traction with customers. Management was stabbing in the dark, we didn't have a direction. Once we did have a direction we lacked the required input to push us in that direction.

Re: Signs you’re working in a feature factory (2016)

#67

Earlier quoted context omitted.

The problem is that, if you're churning out features without thinking critically about why, your work might not even change the company. I've seen engineers, teams, even entire departments spend multiple quarters being a net drain on the company. But they never noticed, because they kept consistently defining release targets and hitting them.

> churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.

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 feature X”. The sales person doesn’t ask what actual problem they’re trying to solve but instead reports back “the market is telling me we need X!!”. An executive picks this up, writes a business case, and then hands a solution (build X) instead of the problem (our customers are struggling with Y) to a product manager. That PM is no longer really empowered to think about the overall outcomes but rather is tasked with discovering requirements and then project managing the feature through.

At some companies this is how all product decisions are made. It’s not that there is no thought about benefit, it’s that the wrong people are the ones doing the thinking and as a result you end up with teams who spends years never delivering anything actually valuable to their users.

Re: Signs you’re working in a feature factory (2016)

#68

Feature addiction is real. This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more…

Most times when users say they won't use a product because it's missing a feature: - Those specific users won't use it anyway even if you add it - The problem they identified is a legitimate problem that was preventing other people from using it - Whether your metrics actually go up depends on where that feature was in the critical path of your funnel. All else being equal, fixing legitimate problems with your produc…

> Those specific users won't use it anyway even if you add it

I think people read this and think, "Why bother, then?"

As someone who is often this user, I don't end up using your product because I've already moved onto a competing product or service; or because I never hear that you have added the feature. Whether your metrics move after adding the feature might be a matter of timing.

There's also the chance I will come to your product in the future. Hypothetically, let's say you offer a password vault application, but I dislike it because it lacks a feature I want, so I end up going with your competitor who offers the feature. You add the feature, but I don't switch because I'm now content with your competitor. Later, your competitor starts pushing towards a subscription model while simultaneously showing a real lack of professionalism and social grace towards customers in public. Since you've added the feature that I thought was lacking, your product might now be an option for me. If you haven't added the feature, there's still no chance.

Re: Signs you’re working in a feature factory (2016)

#69

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-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.

Re: Signs you’re working in a feature factory (2016)

#70

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…

Agreed, this article is interesting on the surface but if you look more closely it is written like a horoscope.

Almost all the points can apply to 90%+ of companies. They are carefully worded so that everyone can say oh wow, these apply to my company.

Post reply on HN