
Signs you’re working in a feature factory (2016) - aphextron
https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory
======
johnkarahalis
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 and more and more for no real benefit.

I've quoted this before, but what Don Norman says in The Invisible Computer
still applies:

"Don’t ask people what they want. Watch them and figure out their needs. If
you ask, people usually focus on what they have and ask for it to be better:
cheaper, faster, smaller. A good observer might discover that the task is
unnecessary, that it is possible to restructure things or provide a new
technology that eliminates the painstaking parts of their procedures. If you
just follow what people ask for, you could end up making their lives even more
complicated."

~~~
Reedx
A useful metaphor we use in game dev: Players are the patient, you are the
doctor. They're great at finding pain, but not at knowing how to heal it. It's
on you to figure out what the underlying problem is and how to solve it.

Also, some of my favorite quotes on this subject:

 _You listen to all your fans and they always say "You should add this" or
"You should add that." They never say "Take this out, take that out." They say
"add more, add more!" There's an old saying that I love about design, it's
about Japanese gardening actually, that "Your garden is not complete until
there is nothing else that you can remove." I think a lot of designers think
the opposite way - "What else can we add to the game to make it better?"_
-Will Wright

 _" People don’t know what they want until you show it to them.”_ -Steve Jobs

 _" Writers and people who had command of words were respected and feared as
people who manipulated magic. In latter times I think that artists and writers
have allowed themselves to be sold down the river. They have accepted the
prevailing belief that art and writing are merely forms of entertainment.
They’re not seen as transformative forces that can change a human being; that
can change a society. They are seen as simple entertainment; things with which
we can fill 20 minutes, half an hour, while we’re waiting to die.

It’s not the job of the artist to give the audience what the audience wants.
If the audience knew what they needed, then they wouldn’t be the audience.
They would be the artists. It is the job of artists to give the audience what
they need."_ -Alan Moore

~~~
joshspankit
I’m not saying this to argue against your points: I’m a fan of Tangerine bank
and have been _continually_ and _loudly_ telling them to remove the balances
on the account overview screen as it now triggers “burning a hole in my
pocket” psychology.

I only mean to say at least a few fans are actively asking for things to be
removed, simplified, and (thoughtfully) refined.

~~~
nicksergeant
You're asking a bank to remove visible account balances from a dashboard view?

~~~
sbr464
I think it’s a valid request. I wish Apple’s iMessage App would allow hiding
or moving conversations to folders to remove from sight. I may have an
emotional or upsetting text with someone that I don’t necessarily want to see
every time I open the app, but also don’t want to delete it. Or may need to
use my phone in a presentation etc, and not want to show certain messages.

~~~
IanCal
However adding an option to remove it as adding a feature, not taking one
away.

~~~
Aeolun
The app was not complete without that feature. In the ideal state of the app,
it was not something you could take away.

Or so I can reason around that logic anyhow.

------
jugg1es
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!

~~~
sidlls
This article isn't disparaging having a process for developing features or for
maintaining a pipeline of features. It's disparaging conditions that
prioritize the release of features _for the sake of releasing features_ as
opposed to _for supporting the business ' needs_ (as determined by data--
including analysis of the performance of features, market conditions, and
other factors).

This article describes the last company I worked for very well: that company
was and is struggling precisely because the senior leadership promoted a
culture of feature releases without consideration for their impact and
consistently changing the focus of feature development not based on data, but
whim, so that the product was steadily losing focus and coherence.

~~~
userium
Exactly. Feature factories build features based on random assumptions, and not
based on actual data.

I just wrote about this yesterday
([https://teamsuccess.io/hdd](https://teamsuccess.io/hdd)). I work as a
consultant with lots of Scrum teams, and many devs feel like they're just
sitting in the factory, cranking out features. Without knowing whether they're
adding real value to the end-user.

So what can you do to break free from the feature factory? Something that I
recommend for the teams I work with, and noticed that actually works, is
"Hypothesis-Driven Development".

In short, replace the items in your product backlog with experiments rather
than user stories. Instead of starting with a user story or epic, start with a
testable hypothesis. Then run small experiments that will prove or disprove
that hypothesis.

My favorite question nowadays is "Wait, why are we building this feature
again?" :)

~~~
bob33212
In my experience people are afraid to ask that question. The answer to that
question may lead to questions around total addressable market which could
cause uppermanagement to question the viability of the product or at least the
cost / benefit of having a big development and product management team in the
first place.

~~~
Super_Jambo
This is a terribly sad comment on the structure of our society, people worried
they might be making something pointless. And the solution is to make sure the
people paying for it don't realize.

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

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

~~~
lazyasciiart
> 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
I 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.

------
lr4444lr
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 charity. If your main gripe at work is
that you're on the value-adding side of a company, which is what feature dev
is in software, you have it pretty good in this world. Change jobs if you
must, but the realities of companies, especially as they gain traction, rarely
means the grass is ever greener. If this is unsatisfactory still, start your
own company. I just don't understand the problem here.

~~~
braindongle
Disagree. This is an endorsement of accepting the fact that your work, your
professional work, done by most of us at a job, makes you feel like a cog, a
unit of production. It is better called a surrender than a compromise.

Surely it's often case that life has people in this sort of scenario and there
is no realistic way to a new path. In that case, sure, take care of your loved
ones and yourself, stay put, and make the most of it. This scenario arises
from the messy mix of circumstances and decisions. There is no blame.

But! "Change jobs if you must", must, be changed to "Change jobs if you can.",
especially for younger people. It's not mature to accept an unfulfilling job.
It's a life-scale bummer. Tenaciously go after fulfilling work. Don't write
off 1/3 of your remaining life. An approach that worked for me: distance
yourself from the profit motive. It's not that hard.

~~~
PragmaticPulp
> This is an endorsement for accepting the fact that your work, your
> professional work, done by most of us at a job, makes you feel like a cog, a
> unit of production. It is better called a surrender than a compromise.

The grass is always greener on the other side of the fence.

The problem with cog in the machine analogies is that people only think of the
plus sides of having more input in decision making processes.

What people generally ignore is the added responsibility and liability that
comes with being more invested in the decision making process. In my
experience, after you start holding people accountable for making the wrong
decisions, most people quickly go back to being happy about being a cog in the
machine and taking orders from someone else. For the few who enjoy calling the
shots and accepting the blame when things go wrong, you can always move up
into management.

~~~
_drimzy
> and accepting the blame when things go wrong, you can always move up into
> management.

In most companies, accepting blame is career suicide. Most people who move up
in management are good at taking credit for wins and pinning down someone else
for failures, or moving on to different projects before their decisions come
back to bite them. And that's the kind of management that leads to broken
process that the OP mentioned in the article.

~~~
loopz
Blame will make problems go underreported and responsibilities shunned. A
healthy org will invite organic planning and distribute power while providing
psychological safe space for real autonomy. The moment of blame or downward
finger-pointing, all of this too easily gets lost.

------
titanomachy
I've never worked somewhere that could actually take a concept to a complete,
well-tested feature delivered to users in a two week sprint.

I've worked at little startups and a medium-sized tech company as well as
FAANG. In each case, we spent most of our time working on projects with 2-3
month time horizons. The small and medium companies called their development
strategy "agile". In FAANG we mostly just did our work and didn't spend any
time on the Kafkaesque exercise of "sprint retrospectives" and "grooming
sessions". Our product manager didn't tell us what to build, but acted more as
an advisor for the engineering team leads.

I think in some case scrum is an attempt to compensate for inexperienced
management.

I assume we just weren't "doing agile", but when I was younger it always left
me feeling vaguely inadequate: if I was just more efficient and competent,
maybe the 2-week sprint would fit better. Maybe that was the point.

Has anyone here ever delivered useful features to users on that kind of
cadence? What was it like?

~~~
BigJono
> I've worked at little startups and a medium-sized tech company as well as
> FAANG. In each case, we spent most of our time working on projects with 2-3
> month time horizons. The small and medium companies called their development
> strategy "agile". In FAANG we mostly just did our work and didn't spend any
> time on the Kafkaesque exercise of "sprint retrospectives" and "grooming
> sessions". Our product manager didn't tell us what to build, but acted more
> as an advisor for the engineering team leads.

Wtf? I've worked mainly for startups, with a couple of large companies in-
between, and I've had the exact opposite experience. The engineering in every
startup has been fairly lean and efficient with a few mistakes here or there,
and every large business has been an 'agile' hell where everything feels
ludicrously slow and nothing gets done.

I've always avoided interviewing with FAANG etc because I just assumed they'd
be in the latter category with the sheer number of employees they have. It's
interesting to hear that Facebook actually runs smoothly.

~~~
SeyelentEco
I agree with the parent poster. I've spent 6+ years at FB and the whole time
I've just worked on what I thought was important. No one was ever assigned a
project to me. The process normally involves managers and PMs highlighting
problems and potential solutions and then developers picking projects that
interest them. It sounds crazy but it is a controlled chaos. We incent people
to work on non-sexy work by aligning with performance reviews. So everyone is
required to show some better engineering impact (like writing documentation,
unit or integration tests, cleaning up deprecated code etc).

It's the longest I've stayed at a company (worked a decade at startups and web
dev companies) because of the freedom to constantly work on things that are
interesting. For example I've changed the type of developer I am twice since
joining.

So if it's worth a look if that's a style that works for you.

------
fogetti
Sadly this is the case in our company. I worked as a dev team manager for the
last 9 months and I was constantly wondering why do we work on these
features...

The more time I spent with our CEO though, it turned out that he wanted to
decide everything feature-wise. When I proposed that we should maybe do some
market research or user interviews instead, he boldly declared that he knows
the market the best. So go figure. No wonder that the whole company is a shit-
show and we're losing a ton of money each year. Also when new features are
prioritized I dared to propose to other managers that maybe we should tie the
priorities to our business plan. Again our genius CEO told us that the
business plan numbers should not be taken very strictly.

The more I thought about this why would anyone give money to such a moron, I
figured that he is basically a very effective sales person. He can easily
convince you how great he is and his vision, but he lacks all kind of
strategic or operational skills. And as someone commented here in HN before,
he also has management myopia: "If I can't understand it, it must not be hard"
he probably thinks.

There was even a case when we looked for a product manager. This is not
exactly the CEO's fault, but even 8 months were not enough to find one, even
though that we interviewed perfectly capable and matching candidates. But
there was always at least one person in management who found some excuses to
ditch the candidate. Now in hindsight I think these people were afraid that
the current status quo of the feature factory would change, so they sabotaged
the whole PM candidate screening.

So now everything in our company is as it is written in this post. Success
theater (this might be the same BTW that is called vanity metrics by Eric
Ries), no connection to metrics, no connection to user values, hand-offs, etc.

~~~
texasbigdata
Jesus dude.

Maybe you're spot on 100% right in terms of vision, in terms of business plan,
in terms of psychological blindspots, in terms of product market fit, in terms
of a path to profitability. You seem pretty smart so maybe it is fairly
insulting to you to not be listened to.

In what way is your world view helpful? And I want to be be gentle here, and
not mean harm. In what way is it helpful for yourself, for your own wellbeing?

Let's say you could fix the company and stop the losses. Then trying to do
that seems worth pursuing. Let's say you can't! We've all come across
situations hard and unmoveable. So now, unless some break happens for you
(because it's unlikely they will wake up and listen to you if they never did
before...just a pragmatic observation), you are stuck being chronicly slightly
unhappy.

It's not my place to suggest, and I'm trying to respectfully ask, would either
maybe letting go or conversely doubling down and standing up for yourself and
finding another job where they value you hurt you less? Completly serious
question because everyone deserves to be happy.

And also, a bit of conjecture, but if you're not profitable it's that same
CEOs ability to communicate a vision that's funding payroll right? I'm not
saying absolve him of every misgrievance because if the company isn't doing
well it's ultimately on his shoulders.

My point is maybe there's a softer path to walk here....?

Not my place to ask though.

------
davzie
I don't actually understand what's bad about this, maybe someone who is in a
company like this can explain why it's a negative? I am working with a company
that is moving more towards this approach and I'm really enjoying it. Isn't
this essentially what Basecamp's Shape Up method advocates for? Not everyone
feels they need to be building something that changes the world I suppose.
Each to their own.

~~~
UK-Al05
This is about making teams completely responsible for the product as you
possibly can. Maybe even profit/loss responsibility. The idea being they're
closer to product then anyone, and thus should make better decisions.

If you follow the feature factory route, the team will just produce things
they are told too. If it doesn't work, it's not the teams responsibility. They
did what they were told to.

~~~
wruza
Otoh, those who “tell” are closer to the business/client, and thus should
issue better requirements. I honestly can’t see what’s wrong with doing what
you’re told to. You cannot play a jack of all trades and program the damn
thing perfectly at the same time. (And if you can, you should not waste your
time bringing profits to that Corporate, Inc anyway.)

~~~
UK-Al05
Teams that take ownership have a product person, who sits with the team. And
is part of the team. Their entire job is work out the best product direction.
They interact, sit with, pair, answer questions from developers everyday, talk
to customers etc. Work with the team to set future product direction.

It shouldn't be external group pushing features into a team backlog.

Devs talk to customers, look at the logs, debug issues, look at the stats
being logged out. As result they have far better understanding of product
usage than most people higher up.

------
pyb
It's very interesting to see a huge cultural gap within the tech industry,
from many of the comments here.

Quite a few people are saying : what's so bad about the feature factory ? This
sounds like a desirable environment.

Whereas I, and many others here, see it as a living nightmare of endless
busywork and improductivity.

(I've once worked in an environment a bit like that, so I know they actually
exist.)

~~~
joegahona
I agree and think it’s a divide between product and engineering. Product
managers (at least good ones) love thinking about the problem, while
developers love thinking about solutions. I’m generalizing of course, and both
mindsets are needed, but it’s the product manager’s job to make sure the
developers are solving the right problems and not just launching features that
don’t speak to a customer benefit.

------
ryandrake
I'm surprised by so many negative comments here (actually, I'm not). This
great piece summed up a lot of awful aspects about commercial software
development that I've also observed over the past 20 years, but have been
unable to organize together and articulate as single problem.

People are asking why this is bad. One way to think about why the Feature
Factory is bad is that it's mostly open loop: You "launch" feature after
feature at the customer, but there's no real feedback coming in to understand
whether what you're doing is worthwhile, to understand what to improve or fix,
or to drive future decisions. The only feedback that gets measured are things
like revenue and sales, and the only thing leadership sees as driving revenue
is the constant spew of features--because that's all you're doing. The
insights that you get from revenue are very generic: "Money is coming in--keep
doing what you're doing" or "We're losing money. Do something different!". The
insights you get from salespeople are even worse: "We'll land this sweet-ass
deal (and I'll get my bonus) if only you churn out otherwise un-needed
features X, Y, and Z!"

I guess this is fine if you're an agency or consulting shop that just does
one-off projects and then moves on to the next client. On the other hand, if
you're writing software for actual people to use, trying to be the best in
class at one thing, or building a platform to last decades instead of months,
then your product will suffer if all you do is bolt half-baked features onto
it over and over.

~~~
BossingAround
I think the reason why I was confused is that it seems there's a very fine
line between a feature factory and Google/Twitter/Facebook/Amazon/...

At a lot of these high-functioning places, they seem to have "feature factory"
moments with some tweaks (e.g. actually building metrics, refactoring, etc. so
that the SW won't implode in 6 months down the line).

~~~
dillonmckay
People complain about it, but Google being able to literally ‘pull the plug’
and shutdown unprofitable or disproportionately resource draining projects is
important to note.

To me, that is a characteristic of the un-feature factory, or whatever the
opposite would be called.

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

------
funfunfunction
Feature addiction is exacerbated by VC. Without real consequences to a poorly
planned product roadmap due to the years of runway afforded by massive funding
rounds, entire orgs fall into the “one more feature” cycle and never focus
enough on measuring success in terms of real dollars. No one knows what went
wrong when all the money is gone and devs/designers/PMs rinse and repeat at a
new well-funded startup.

~~~
borski
This actually isn’t true. VCs don’t want companies to build features, they
want companies to listen to users maniacally and find product-market fit, then
focus on growth (and/or revenue) like mad. That companies focus on features is
a management issue and a sign of a failing company, not a sign that VC is
somehow bad.

~~~
funfunfunction
I agree that the issue is a problem of management. Though without oodles of
cash to wash away missteps, poor management would be much more obvious. The
ability to distill user feedback into the minimum number of valuable feature
enhancements is what sets successful product orgs apart from failed ones. When
cash is largely not a constraint, the tendency is to build exactly what each
customer has said they want rather than try to come up with succinct
improvements. The result is often bulky products that cost a fortune to
maintain and only appeal to small number of customers.

VC is good if used correctly. But dumping wads of cash into a company to
develop a product that isn’t capital intensive (like web or mobile tech) has
the tendency to create bloated product orgs which optimize for the wrong
things.

------
scottshea
I once worked in a place where we spent $100,000+ to add a feature that only
two customers used. They paid around $8,000 for the feature. It was deemed a
success. Features serve Hope while quantifying the value to customers rains on
people's parades

------
ttoinou
What's wrong with feature factory ? If you're delivering something good for
clients..

    
    
       No measurement / Success theater / core metrics
    

This takes time and mental space. That you could better use to... crank a new
feature! :)

~~~
scribu
> If you're delivering something good for clients...

That's the crux of it, isn't it? How do you _know_ that what you're delivering
is any good?

~~~
lazyjones
> _How do you know that what you 're delivering is any good?_

How do you know it isn't? You need to implement it and see whether it's good
or not.

~~~
dillonmckay
If you know it is going to be a nightmare to support, it will consume tons of
resources (cpu/storage), and nobody wants to pay for it (or not pay enough to
cover its costs), it is not good.

As has been mentioned many times on this site, it is very easy to sell $2 for
$1 all day long.

~~~
lazyjones
> _nobody wants to pay for it (or not pay enough to cover its costs), it is
> not good._

And how do you _know_ this in advance?

~~~
dillonmckay
You ask them.

‘Will you pay an additional $x/mo for this feature?’

You can estimate your AWS costs for what the feature would cost for that user.

You can estimate dev and implementation time.

It doesn’t even have to be 100% accurate, but if the numbers come nowhere
close to making sense, don’t pursue this further.

Now, there may be a future time where some fundamental cost changes, and it is
worth considering again.

~~~
sfink
It sounds nice, but it doesn't work very well.

Users lie. Not even maliciously.

Clients will say they'd pay for it, then when you deliver it they'll say they
realized that your competitor provides that and everything else that is really
important to them in the standard fee. The competitor is actually no better,
and would require the same amount of development to get to parity in other
areas, but they win by claiming that everything will be rainbows.

Clients will say they'd pay for X, but once you deliver it they'll suddenly
realize that it won't actually work for them until you also implement Y, but
they won't pay any more for X+Y than they would for X alone.

Clients will say they'd pay for X, but once you deliver it they'll have
shifted direction or something has changed and they don't need it anymore.

Clients will say they'd pay for X, but once you deliver it and they start
using it they'll discover that it's not at all what they actually needed.

------
spectramax
In this thread: When your whole life is based on assumptions of 98% of it is
wrong, you're gonna defend yourself to the tooth. It is emotionally
challenging and damaging to the ego.

Watch Jim Keller (designer of A4/A4 Apple chips, Ryzen processor, x86 spec co-
author and a legendary chip designer) make this point better than I can [Video
link copied at 1:22:34 marker]:
[https://youtu.be/Nb2tebYAaOA?t=4954](https://youtu.be/Nb2tebYAaOA?t=4954)

People would say that the author of this post is arrogant and want to reject
the status-quo - But I would say the opposite, people who have vested interest
in the status-quo because their reputation depends on it, their salary depends
on it are the arrogant ones because they reject reality in favor of their own
good.

------
rubyfan
Much of this describes some of my past experience at a Fortune 100. That
company is now undergoing much discussion at a senior level about agile
delivery. Senior executives are walking around talking about tribes and
chapters and have no idea what that really means or of the day to day work of
teams. It’s unfortunate what will come out of it in the end is some people
doing stuff now that will have new titles and maybe more ceremonies but not a
substantive change from what they do now or the way work gets done.

Middle management thinks they work in a factory and treat people like numbers.
If you trust the same group of people to implement the change then you can bet
their sole goal is to make it look good. Unless you change the middle then not
much will change.

~~~
tuanis
I actually feel like agile development can invite some of this behavior,
because the focus is on shipping instead of value.

Not saying agile is bad, just feels like a separate problem.

~~~
SpicyLemonZest
In principle agile is supposed to be guided by higher level processes
accounting for this kind of strategic problem. In practice, yeah, I do
sometimes see agile teams get away with writing "objective: ship my features,
KR: 5 features are shipped".

------
squirrel
[2016]. Previous discussions on HN:
[https://news.ycombinator.com/item?id=13639549](https://news.ycombinator.com/item?id=13639549)
[https://news.ycombinator.com/item?id=13044685](https://news.ycombinator.com/item?id=13044685)

Very good article, so good that my coauthor and I used the metaphor in our
book.

------
thomas
In this framing, a factory is supposed to be bad? Aren’t factories efficient
and the best way of producing things at scale?

~~~
jrockway
Factories are fine, but if you walk into a factory you're going to be finding
a lot of people working on the factory itself. Process tweaks, new machines,
maintenance, etc.

In the software "feature factory", people have mostly forgotten about that,
usually because someone does it "in their spare time". I guarantee you that no
factory worker lubricates the machines off the clock. I am not sure why we
should treat software any differently.

------
metalgearsolid
Been there. Anecdotally, a good indicator of a feature factory is the turnover
in marketing, a particularly gruelling department to be in when you are not
finding any consistency with the message you've been tasked with
communicating. That kind of situation is okay and perhaps even fun if you can
count your colleagues with your fingers, but at companies larger than that,
the general lack of understanding of what your software does is a kind of
debt, perhaps even classifiable as technical debt.

I tried to raise red flags to my bosses when our colleagues in customer
support we're making feature requests for features we already had. The company
as a whole lacked the courage or enthusiasm to tackle those design flaws, and
instead would request additional features. I tried really hard to fight for
removing features too...

------
sebringj
IMO, this is an ego-centric article. Unless you're trying to change the
world...be happy you have a continual stream of work. If they don't have a
need to keep you busy that's when you should be worried. As a programmer, I
try to keep my employer happy and I don't try to meddle in business decisions.
I try to understand them as best as possible and give suggestions or ask
questions when things are not clear or don't make sense but knowing that my
job is to make the things to match specifications. When I see "feature
factory" I initially thought it was good as you are building new things but
didn't know it was a negative article until I started reading. I'm grateful in
other words as I'm pretty normal, not some bright programmer working at
SpaceX.

------
lifeisstillgood
At a certain company size, there simply is not the level of control (ODA
loops) to know what product to make or features to add - it is a fairly good
survival strategy to have multiple teams duplicating huge amounts of work
simply because a few will deliver the right thing.

The internal politics of most organisations has a similar feel - lots of
duplication looks like competing camps and frequently is, but the duplications
is partly survival strategy (what if those others don't deliver) and partly
evolution (one team will deliver something that actually fits the market.)

Boy there are better ways to arrange it, but this seems to be a local maxima
that's easy to reach.

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

------
dennisgorelik
1) When John Cutler
([https://www.linkedin.com/in/johnpcutler/](https://www.linkedin.com/in/johnpcutler/))
wrote this article in 2016 - he was working for pendo.io that already got
~$13.3M in funding:

[https://www.crunchbase.com/organization/pendo-io#section-
fun...](https://www.crunchbase.com/organization/pendo-io#section-funding-
rounds)

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...](https://www.crunchbase.com/search/funding_rounds/field/organizations/funding_total/amplitude)

3) Amplitude looks more successful than pendo:

[https://www.similarweb.com/website/amplitude.com](https://www.similarweb.com/website/amplitude.com)

[https://www.similarweb.com/website/pendo.io](https://www.similarweb.com/website/pendo.io)

------
ericmcer
There is also a perverse incentive for employees to point this out. Why would
a product manager highlight that the status quo is flawed? Why would an
engineer shake stuff up and optimize tired old code instead of just cranking
out a shiny new features?

Raising these issues would ruffle a lot of feathers. I would not do that just
to make my own life more difficult and possibly point out that my own position
is redundant.

------
awinter-py
> success theater

such a good phrase. premature 'mission accomplished' is always embarrassing
even when you're just the one stuck cringing and golf clapping in the corner

Common thread here seems to be lack of argument / buy-in process. Central
leaders need to (1) convince the team that tactics accomplish team goals and
(2) _have_ team goals. Bad teams do none of the above.

------
nateburke
As the average tenure of an engineer (or PM, for that matter) at many medium-
to-large software companies edges towards two years, it is BARELY enough time
for the average employee to 1) ramp up on HR stuff/culture, 2) understand the
implementation of an existing system, 3) make and deploy a change to the
system without incident.

Best case, all of that takes 6-9 months, but the reality is more like 12-18.

Having time to understand the "why" behind features in a deeply critical way
is a LUXURY given this average 2-3 yr time frame. And all of this assumes an
absence of reorgs, mission-critical integration work, etc., which further
complicate understanding.

The reality is that customer needs are changing so rapidly that even CEOs and
heads of sales fail to grasp the "why" most of the time, and merely focus on
just doing whatever it takes to win the next big contract. "When one can see
no future, all one can do is the next right thing."

------
luord
Most of the points come from disregarding the cardinal rule that every
developer and development company should abide to (obligatory IMO): Fight for
the users.

In this case, you can't fight for them if you don't know what they want or how
the product is helping them.

------
pugworthy
Dear lord this is depressing to read. My personal annecdote here that's
probably not a big contribution, but this puts a label so well on the product
organization I just left on a large project @ a fortune 50 company.

What's really bad is that the much larger R&D organization (who is I now know
to label a feature factory), absorbed our smaller highly productive team that
essentially did everything opposite to this. The things we thought we were
good at were suddenly the huge flaws of our team - flaws that lead to a number
of us leaving to get away from the huge amount of process that got laid on us.

------
marstall
unfortunately this is almost every place i've ever worked. so many good points
here - but the most poignant for me is "celebrating shipping" vs celebrating
customer success ... so true

------
reddygaru
My software engineering course professor made the below statement which has
served me well.

Users know what they want but they don't know what they need.

Figure out your user needs rather than tending to their each want.

------
adamzapasnik
I worked at that kind of company, wouldn't recommend it to anyone. I could
write a very long essay why it sucked so much, meh.

In short, it's very easy to burn out and overall it's just stupid. The pace
was surreal, some of the features very complex, many people were overworking.
Everyone is super stressed out, the best decision is to just leave that
environment.

Bottom line, don't work for that kind of companies, because your value is
equal to the speed of your fingers typing.

------
Orcus90482
I’ve found #8 to be very important. If you don’t allow for revisions you get
code rot and suddenly every new feature becomes exponentially more difficult
to implement.

------
_drimzy
Ah man. This makes me realize why my time at a recently IPO-ed tech company,
as an engineer was so horrible. Except #10 the company is guilty of every
single point.

------
dragonwriter
While this focusses on places selling software (features added to close deals,
etc.), it is probably an even more pervasive problem in internal IT shops—and
a more tragic one, because internal IT organizations _should_ be better
positioned to tightly align on business value rather than sales, though this
is often hampered by internal organizational structures which sometimes
incentivize arms length, contracting-like interactions.

------
logicallee
I don't know, everyone. All the best software is so great because whatever you
want to do, you can find in 1 minute with a Google search. I hate googling and
finding "I don't think this is possible. I know you can do this in (a feature
factory competitor of what you Googled) but I don't think (what you googled)
has this feature."

I've seen comments like that thousands of times. Haven't you?

------
gfodor
Somebody asks for a feature, you build it, they pay you — that’s data.

Data isn’t just spying on your users to see how they behave.

~~~
gfody
A big part of product management's function is buffering all the features
being asked for so that they can take a step back and design a solution that
isn't just 100 new features. The feature factory process is mostly a symptom
of product being bad at their job.

~~~
gfodor
Sure, but my point was that this article seems to be focused on data-driven
product decision-making. Creating good designs with far reach in my view is
unrelated. I wanted to counter the narrative that unless you are spying on
your users and using that to 'prove' your features are being successful you
are doing a bad job at product development.

It's certainly possible in my mind to do requirements gathering, feature
design, implementation, deployment, and iteration without automated data
collection from user behavior. You can, you know, talk to people. Nowadays
when someone says "data-driven" they typically mean "instrument the hell out
of your product and observe user behavior." Perhaps that's not what the author
is getting at. But if they are, I think it's important to tell people to not
feel guilty for not spying on their users. If you are doing the follow-up work
to actually communicate with customers to understand their needs, you should
feel confident that you're doing your job well. And you should be proud that
you are doing so without having to spy on people.

~~~
gfody
totally agree, it's also possible to have built a feature that users have to
use but aren't happy about - then the data can be misleading.

------
srmatto
Here is the update to this article, 3 years later:

[https://amplitude.com/blog/12-signs-youre-working-in-a-
featu...](https://amplitude.com/blog/12-signs-youre-working-in-a-feature-
factory-3-years-later)

------
anonytrary
I've never heard of this term before, but when I think of "feature factory",
products like Jira and Yahoo! immediately come to mind. Such products feel
like a sinking bag of features with no real cohesive, central purpose.

------
CameronNemo
What do I do if upper management seems to be driving this process?

~~~
ipnon
If your input regarding how the company is run is valued by upper management,
then make a clear argument that they are running a feature factory and what
they can do to change.

If no one cares what you think, then the best outcome for yourself and the
your company is for you to find other employment. You labor is freed from the
feature factory for more productive purposes and the probability of survival
for your sub-optimal company is diminished, opening opportunities for more
optimal companies in the same space.

------
antoineMoPa
I'd rather work in a feature factory than a bugfix factory.

~~~
samyel
Eventually a feature factory will turn into a bugfix factory as more and more
unmaintained and potentially competing layers are added.

~~~
gfody
..or some features are actually bugs, now your a bug farmer.

------
kwhat4
Does this ever not happen? I am being serious... Have any of you worked at a
company for any substantial period of time where some for of this has not
become the norm?

------
xyst
To a certain degree, and in my experience, all companies have this problem.
Sometimes it’s at a team scale but for others it’s at an organization scale.

------
darepublic
This sounds like every place I've worked at ever and I don't expect it to
change anytime soon

------
emodendroket
I mean, let's say I am. So what? As long as the checks are clearing, not my
business.

------
anonu
This just sounds like regular software development.

------
filterfish
Twelve out of twelve for my company. Yah us!

------
gigatexal
Oh man I’ve seen these signs first hand :(

------
michaelfeathers
Great article. It should add Technical Debt as a sign.

------
0xff00ffee
I've had to make the decision to steer my design resources into "feature
factories" because my customers are sometimes fickle.

There are a number of instances where features were paid for, developed, and
then not deployed.

It hasn't become discouraging yet because there has been professional growth
in developing methods for constructing and deploying said features, but I am
concerned as to our financial ability to identify and reject contracts that
are just un-exciting features. Most of my devs are satisfied with the paycheck
despite the work, but a few are showing signs of not being valued. And I'm not
sure how to address that yet to avoid losing them. It's like: taking a lame
contract for $$$ vs. boring a good employee. I hate how personal it becomes, I
feel like I'm cajoling them to do the work, ... it feels icky and toxic.

~~~
sfink
I dunno, if I were an engineer in an environment like that I'd be fine with it
if (1) you were up-front about this being a necessary hack to sustain the
company for a bit longer, and (2) there is a vision and a process to refine
that vision of where you would all _like_ the product to go. (2) is so that
these seemingly short-term features could either be seen as prototypes or
first cuts at the future you'd really like to get to, or walled off as
extraneous stubs that don't interfere with the core architecture. (1) is
important because I feel good about helping keep the company afloat, but I
feel crappy about just doing stuff that I know is bullshit simply because I'm
told to (or worse, lied to that it's "important" for its own sake).

This also makes it possible to track the trajectory of the company over time.
When you're doing better, you can afford to turn down these types of requests.
Communicate that decision and why you made it to engineering; we love to hear
that sort of thing.

The safest answer that a salesperson can give is "yes". The safest answer that
an engineer can give is "no". You can't let either side always win, but you
can communicate the reasoning and importance to bridge the gap and make it a
team decision even if it wasn't the team making it.

~~~
0xff00ffee
Thanks for the feedback. That's pretty much how the discussions go. The team
is small so I can still be 1:1 with them, and be direct about the state of
things.

>This also makes it possible to track the trajectory of the company over time.
When you're doing better, you can afford to turn down these types of requests.

Yeah, this is a really good indicator. Heck, if this keeps up -I- won't want
to do it anymore! Which I think is perfectly natural.

------
redwood
This seems written by someone with an axe to grind.

~~~
BossingAround
Don't we all have axes to grind?

