
How many of you know that the team is working on something that no-one wants? - kiyanwang
https://iism.org/article/how-many-of-you-know-deep-down-that-the-team-is-working-on-something-that-no-customer-wants-54
======
worriedformyjob
Obviously using a throwaway here. Our board members got it into their heads
that successful companies must have an AI "play", so they instructed the CEO
to invest about 10% of our development budget on AI.

We are doing absolutely inane projects that have no hope of succeeding.

We serve a niche industry where certified professionals have to do certain
tasks personally, instead of being able to delegate to secretaries. Somehow
our CEO has been convinced that AI can be trained to do these tasks, at a
reliability level not achievable by other humans.

Team motivation is in a weird space: everyone is relaxed because there is no
pressure to succeed - we all know the project will fail unless someone
develops well-perfoming, human-level AGI before Q4/2020\. Lots of long lunches
and checking out early in the afternoon.

At the same time, everyone is worried how terrible the fallout is going to be
once the project reaches its inevitable conclusion.

Interesting times, but at least we can now tell investors we are a keen
company with an AI play up our sleeve!

~~~
reading-at-work
> we all know the project will fail unless someone develops well-perfoming,
> human-level AGI before Q4/2020

This is hilarious, and makes me wonder how many similar corporate AI
initiatives are under way in the world right now.

~~~
bob33212
I have had a couple conversations where a business guy starts off with a
decent idea then he says something like "the cognitive AI module will fill out
your expense report after watching you do it for a couple weeks".

What the fuck? If I had the ability to code a cognitive AI module which could
do that I would not be building it for you, I would solve self driving and
license the software for billions.

~~~
hieunc229
Business guys usually comes together and brag about their works. Quite often,
they start to talk about things they heard but don’t understand much.

And the other one hear about it, get excited, but also don’t understand much.
Then on the meeting, he brought the idea up and convince everyone to do it.

The next you know, you’re pulling your hair out trying to understand what is
going on

~~~
fxtentacle
Yes, the best salesperson is usually the one least concerned with reality.

Or as one VC put it: Never let facts get in the way of a good story.

~~~
bigiain
This makes more sense when you remember that being "concerned with reality"
for a salesperson mostly means "Getting the commission paid and moving to a
different role before everything blows up too badly", rather than "delivering
software that meets the sales deal's contractual requirements".

Salespeople are too rarely judged/punished for the disastrus messes they leave
behind, and all too quickly judged/rewarded for being able to convince a
customer to sign off on a big number without any care for long term
implications of that deal...

~~~
brain5ide
Hm... Vested commision?

------
malux85
Yes, so I put analytics in to prove it.

I told the project leader that nobody wants a share button there, because of
the nature of the data, nobody will share it.

They disagreed strongly, suddenly the share button was super important.

So I put tracking on it. A year after launch, guess what? Yep that’s right,
nobody clicked the button. Not a single user.

So I showed them the data and told them I was right. I told them I was sick of
not being listened to, and sick of designing and creating software that
literally nobody uses, and handed in my resignation

Was a good thing in the end because it pushed me onto the entrepreneurial path

But I know how much it sucks writing software that no-one wants

~~~
SwiftyBug
That was porn, wasn't it?

~~~
malux85
Hahahaha I re-read my paragraph and it does sound a bit like that!

I wish it was - then there might have been some engineering challenges related
to scale, but sadly no, it was a mobile web app for getting small % discounts
at stalls at a niche event.

~~~
rightbyte
Seems like a thing you acctually would want to share? Instead of copy pasting
the url which is almost impossible on smart phones nowadays...

~~~
malux85
It was an info page similar to a terms and conditions page, nobody wants to
share that.

~~~
rightbyte
Ok explains your comment.

------
mathewsanders
“Agile teams that truly iterate with the customer can often avoid these
problems because the customer is there the whole way through and the team
continuously pivots to close gaps discovered by the customer throughout the
project, thereby building something the customer actually needs and wants.”

I‘m 2 years into my first role as a product owner (made the switch from
design) and working at a fortune 100. The thing that’s struck me most since
starting this role is that as while the company has invested more to our
transition to agile teams (hiring external agile transformation companies,
everyone goes through scrum training etc) we seem to have distanced ourselves
even further from the customer.

I report to a product manager, who I think in turn has had zero hours
interacting directly with our customers or our users. Our roadmap seems
completely driven based on whatever features seem to be flavor of the month
(or quarter since we do roadmap planning quarterly) and it’s been a struggle
to even try and get buy in to having our customers represented in some way by
proxy (e.g. through personas, or setting product metrics that attempt to
measure customer value). Features that we do release have no expectations
around what is considered successful usage (usage will be measured, but
without context, so if 5% of customers use a feature there’s no interpretation
if this is really low, or really high).

The puzzling thing is that when I talk to my manager (or managers manager)
about this disconnect, they seem to agree in principle, and that we _should_
be doing these things but no one ever does.

I’ve been told that someone in leadership described me as being too “black and
white” in this area, but I consider myself both pragmatic and flexible to
alternative ideas.

Because I’m still new to this role, I wonder if I’m being naive or idealistic
around how we approach our feature development, or if this is just how most
companies operate.

~~~
gretch
I've worked 6 years as a PM, last 4 at FANG

Here's some advice, which you are free to take or to leave, (and that's very
reasonable since my advice is generic and I can't speak to your exact
circumstances)

1) Just start doing it. Don't wait for someone to give you permission to
prioritize customer needs. Pick up the phone and call them. Go to a store and
watch them shop for your product. Talk to people. When you set OKRs/KPIs, just
make them about customer needs. Be the change you want to see. Especially if
you have spiritual buy-in from your manager. But your intentions have to be
crystal clear on point about wanting what's best for the customer and the
business and doing so in a rational way until you earn some social capital. It
cannot be interpretable as political or they'll construe it as that and fire
you

2) Use bureaucracy jiu-jitsu. Do what you think needs to be done in order to
make the customer and the business successful. When someone tries to make you
work on their arbitrary BS, give them a form to fill out and tell them it's in
your team's triage queue. Make them force you to deprioritize a project which
has clear value and then when that happens, make sure you announce loudly to
all stakeholders why that project was depriortized and what's going to be
implemented instead. If your stakeholders have even 2 braincells, they'll do
the pushing back for you - you don't need to do it alone.

Lastly, you can't change an entire culture by yourself. For some places, it's
just too late. But if you can find allies who feel the same way you do, you
can be the beginning of a large change for your whole org by just being a good
example

~~~
teddyh
See also: _Getting Things Done When You’re Only a Grunt_ (2001):

[https://www.joelonsoftware.com/2001/12/25/getting-things-
don...](https://www.joelonsoftware.com/2001/12/25/getting-things-done-when-
youre-only-a-grunt/)

~~~
gowld
That advice reads as "If your job sucks and you can't safely quit, defy your
manager and work overtime until you are thanked for it or fired."

~~~
teddyh
Well, yes. Sometimes your options are limited.

------
TedShiller
I'll share a disturbing anecdote about one of the largest and most influential
software companies in the world, based in the Bay Area, and I'll leave it to
you to guess which one. I know of several people who work there who are ranked
very highly and are paid extremely well, who have told me personally that the
work they do there is terrible for the users (i.e. it's exploitative) and
terrible for the internet (it interferes with open standards and access). But
it also creates profits for the company. The individuals feel that it just
pays too well, and for that reason, they could never voice their true feelings
inside the company, and neither could their colleagues. It would mean giving
up humungous paychecks. Inside the company, it's like the Emperor's New
Clothes. Everyone pretends that they are making the world a better place, when
they know without a doubt that in fact, they are making the world a worse
place. They are not bad people. This company is filled with people who are
making that silent tradeoff every single day.

~~~
samvher
> They are not bad people.

Very few people are "bad" people but the way you're describing it makes it
pretty clear that they're making unethical choices, and they're doing so
consciously. Actions speak louder than words.

~~~
runeks
What’s the difference between a bad person and a person who consciously makes
unethical choices?

~~~
Inthenameofmine
Is that a rhetorical question? Because a person who makes conscious unethical
choices is a bad person. Otherwise there would be no metric for "badness" and
the word would be meaningless.

------
rb808
The problem is that software no-one wants often has the best careers.

I worked on a system used by many people and it was hard work, was getting
10-15 years old, held together with tape and lots of users who all had their
gripes and requests.

I moved to a system hardly used by anyone and life is so much better. Get to
play with interesting technology and no one minds because there is now risk of
annoying a our users who dont really care. The best thing is I get paid more
here too.

~~~
fogetti
That might look good in the short term, but there are many companies and roles
which require you to show the actual number of users, or the load of the
service that you worked on. Also many technically challenging issues only come
out under load, and actually working on challenging things are very different
from reading about them. Just my 2 cents.

~~~
ido

        there are many companies and roles which require you 
        to show the actual number of users, or the load of the
        service that you worked on.
    

I got my first job as a programmer in 2001 and not once was I asked that. I'm
sure they exist but I wouldn't count on that being so common as to
significantly impact the OP's career prospects.

Two things I've most often noticed people care about when hiring:

1\. experience with the exact tech / field that they're hiring for

2\. having brand-name job experience (google, amazon, etc).

It's sad but you'll probably get better mileage from having worked on a
useless prestige/pet project at google using fashionable tech than a critical
system written with JavaEE & serving a lot of high-value customers at Alliance
Generic Insurance Services Corp.

~~~
collyw
That last sentence sums up the sad state of hiring in the industry well.

~~~
yters
probably depends if you are applying to another faang or if you want to work
on mission critical insurance technology

people who really need skills are probably good at indentifying said skills

------
h0h0h0h0111
I currently work a "crypto" startup - we've developed our own language and
platform for developing smart contracts.

Our CEO constantly talks of "ecosystems" and "blockchain", when that's none of
what we actually have (or have concrete requirements to build...).

Our investors and customers have no real idea what they want or what to expect
- most of the customers just want a basic enterprise system, but have been
wooed by blockchains and AI and magical fairies that sounds really nice in a
contract but deliver no value in reality.

The saddest part is that we have an amazing team - the smartest folk I've ever
worked with, with so much potential to create amazing technology, if only we
had a plan or direction.

Like I saw on another comment, it has all become long lunches and checking out
early, because everyone knows the project is doomed (albeit well funded... for
now). Where does one even go from here?

~~~
snarf21
I work in a similar place now and have in the past. I've taken the following
approach as much as possible: 1) Use the opportunity to learn new technology
and toolchains regardless of applicability. This can greatly increase your
worth when looking for jobs in the future. 2) Try to find things outside of
work to give your days meaning. Find a hobby or side project. I started
designing board games. This lets you treat work much more as a 9-5 punch the
clock task and lets you look forward to working on your _real_ project later.

It is still entirely frustrating to feel like you spend your days digging
holes and filling them back in but you have to fill your days with your own
meaningful purpose.

------
denkmoon
I am currently employed to develop an entire data analytics system because a
government department can't get their firewall rules right.

None of the members of this government department want a bespoke system, they
want to use tools they are familiar with but due to the firewall rules this
isn't possible.

~~~
fancyfish
It truly is fascinating, the world of tools and ecosystems built up to
sidestep inane security rules in organizations.

Spoken from experience, this includes things like Anaconda in orgs where devs
can’t use just any Python packages, or scripts from the internet copied and
pasted into files because the firewall blocks git cloning. One could even
consider AWS as a platform for devs to get around InfoSec red tape and have
some semblance of control. The goal as a dev here is to fight the fewest
fights to make tools available, by getting access to the biggest “bundles” of
tooling they can.

In such organizations, there is either no concept of cost/benefit of overly
restrictive firewall rules, etc, or the culture is such that the security team
has become entrenched and unquestionable.

~~~
Aeolun
Can confirm. I’m able to spin up multiple sets of m5.24xlarge without anybody
blinking twice, but I’m not trusted to spend money to buy a ballpoint, for
which I’ll have to go through the whole PO process. The disconnect here is
unreal.

When the only tool you have is a hammer, everything by necessity becomes a
nail.

------
Kunigaikstis
For a couple of years now, I've been developing features for a product that
hasn't found product-market fit. Features that nobody _really_ gives a shit
about. I can talk directly to one of the cofounders, bring them evidence based
on analytics or the past failings of the giants upon whose shoulders we're
standing on. His response is, majority of the time, "yeah, I get that. We
promised this to a few customers and I really think it'll work". It hasn't
worked.

~~~
FreeRadical
You need to ask him to define success and failure for the feature. Under what
conditions will he accept it has not worked

~~~
Kunigaikstis
It's an iterative process. Our conversations have gotten better over the
years. He has the connections and market knowledge so I have to respect his
wishes most of the time. I make it sound bad but it's because I'm, like many
of us, tired.

~~~
the-dude
There is website for that : [http://tired.com](http://tired.com)

------
linza
A small team in a company I worked for got into machine learning a few years
back. They had some success with some toy examples and were now looking for
applications. They tried to use it for optimizing some specific engineering
procesess.

Two people (one was me) were warning them that this is a waste of time and
will cost the company a fortune and then no one will want it because the
quality will be so much poorer. And the whole thing looked like an instance of
hammer-looking-for-a-nail.

Fast forward a few years, the team tripled in size, built a multi-million-euro
product, and some very large customers now trust their operations research to
that new thing.

~~~
roryokane
It's hard to take a lesson from this without hearing why you think that
happened. Do you think the product got so big because the team applied AI
usefully and your initial evaluation was wrong? Or do you think they gained
customers because there is not much competition in that niche and customers
were drawn to the sales team's claims of AI despite the AI not being very
good?

~~~
linza
My personal takeaway was that I don't know as much as I think. I didn't
produce any data at the time to prove my point (not that I would have known
how to), and because of that it's hard for me to analyse the situation more
meaningfully as to why I was wrong.

Why they were successful in the end: the team struggled for some time before
they got momentum with a single really large customer that put in resources,
and made other customers follow. It's not that the tech got better that much,
customers were just more willing after they saw one of the leaders in that
space invest in that approach, and they were afraid of falling behind. It was
not because of machine learning, but despite of it.

------
transcriptase
Did anyone here work on implementing Bing web search into the Windows 10 start
menu?

I'm curious to know the decisions that led to an operating system file search
prompt ignoring exact file, directory and app names in favor of trying (and
generally still failing) to show irrelevant web results.

~~~
sbierwagen
After years of low level annoyance, I looked up the regedit incantations
needed to disable it. Now start menu search is amazingly snappy and only
returns relevant results.

~~~
mpfundstein
Mind sharing? PLEASE!!!!!

~~~
sbierwagen
[https://www.howtogeek.com/224159/how-to-disable-bing-in-
the-...](https://www.howtogeek.com/224159/how-to-disable-bing-in-the-
windows-10-start-menu/)

------
enra
I listening to customers is not really something you can only do with agile
scrum. You can figure out what customers need with roadmaps or projects too.
Outside enterprise, you also don't have one set of customer/users, you have
thousands or millions them.

I agile scrum often leads to situation iterate the teams iterate towards local
optimization or solving problems that people think they need, but fails to
deliver actually create next level impact, since teams are hesitant to make
plans longer than in two week increments.

I think most successful product teams take the practice of closely listening
to the users (as the whole team or product organization), trying to understand
the user, but choose to build product they think is right, even it's not what
the customers currently say they want.

------
nurettin
> Don't just build Something™, build an industry leading product that
> customers want and love!

The point of writing software is to get paid. If the process leads to
something actually useful, good on you. If not, you still got paid. It was
just a drill, life continues.

~~~
shultays
That is highly subjective. Money is a motivation but some people seeks more
from their jobs. I wouldn't work on a job if it is not really giving me a
sense of accomplishment either.

~~~
extra_rice
I currently work on a project that has struggled to make actual sense for a
few years now. Sure I like getting paid, but there's a growing void in my
soul.

------
SnarkRUs
I was cheering a little inside while reading this and agreeing mightily until
I realized it was an ad. Boo.

~~~
rigel_kentaurus
True, but I think we can separate the idea from the person/company.

The problem statement is very well written. The Director of Engineering
rotating because they can’t deliver, and the battle between Product and
Engineering.

Conclusion is rushed, but it boils down to what agile advocates at the core:
product manager and QA need to be in the room along with engineering.

It is until they hear daily about the challenges, first hand, and they see the
struggle that it makes sense. Does not matter how many reports the PM does,
first have seeing why technical debt is making things slow is invaluable.

Only addition I would add is: there is a reason why sprint waterfalls exist.
You can’t iterate forever, and someone needs to play the role of the mature
person that knows when something is good enough and needs to be shipped. I
think Agile as a framework is at its limits. We need something that lets us
run the engineering but at the same time becomes more predictable to business.

~~~
SnarkRUs
I suppose I'm tainted because I've seen one too many methodology consultants.
"What you're doing now is bad...but this _new_ way will solve all your
problems.." Enter "Value Scrum" your new savior.

After almost 3 decades in software, I've come to perceive a few things about
the industry and the people in it, especially the new entrants:

1) All problems begin with "how can we solve this with new
software/feature/etc?" because after all, we're software people and we make
software so clearly software is the answer.

2) Society believes #1. They expect that all problems are solved with
software. Not only does society believe this, VCs believe this also. There is
incentive to behave as #1 in the hopes that it leads to $$$.

3) Anyone not believing #1 is a detractor, or worse, a Luddite. Technology as
solution is the prevailing axiom. It is Maslow's hammer. All non-believers
must be purged or cancelled.

So when I read what I'll admit is an enticing article that demonstrates
experience and analytical thinking by the author I'm intrigued and mostly
supportive. Just like software frameworks (yes, you Javascript community) the
answer to problems is always a new present solution which one day will be a
future problem whether it be tech or tech inspired methodology. Tech first
problem solving usually always leads here.

I was reminded of this book when reading the article. Many patterns of org
behavior are well described here: [https://www.amazon.com/Organizational-
Patterns-Agile-Softwar...](https://www.amazon.com/Organizational-Patterns-
Agile-Software-Development/dp/0131467409)

I was also struck by an adaption of a statement I read once about XML. The
adaptation follows: "Agile is like violence, if it isn't working you're not
using enough of it."

So what does this mean, abandon all tech? No. It means, apply critical
thinking. Let dissent be ok. Do the things the article suggests. You don't
need training, or a seminar or a consultant. And if the leadership wants to do
something you can't fully engage in, find something else to do. Don't waste
your life.

------
laurentdc
Agencies and consulting companies have built their fortune on clueless
customers. But I honestly don't really care anymore. I just want to write code
and go home

------
MattGaiser
> Don't just build Something™, build an industry leading product that
> customers want and love!

One of the biggest challenges is that someone eventually has to say "no" for
that to happen. It is easier to just say yes to whatever is wanted than fight
with someone about doing it.

~~~
democracy
Words of wisdom and experience - I am with you on that one

------
franze
I am working with Start-ups since 2008 - and classic companies before that.

My chances to know beforehand what customers want is 50/50.*

So I am very humble by now. Launch super early. Get Feedback. Quantity wise
and quality feedback (listen closely if you made their life any better).
Iterrate and/or change path.

Yes, like flipping a coin. Sad that, quite a lot of managers have a way lower
hit rate as they have an inherent ”the customer is like me and users are
stupid” bias (both at the same time, so that makes them...)

~~~
tappio
I wonder what is the chance if you are following the "worst" practices?

User is stupid -mentality, being a dictator and not explaining why things are
done the way they are, etc... Id expect it to be lower, but not that much
lower. Luck is a major component because new product development is basically
forecasting the future. There are so many things which are out of your
control. If you get lucky 4/10 times with worst practices and 5/10 times with
best practices, it does not really matter.

Besides, it makes a much better story that you only knew how others are stupid
and because of this only you could do the right solution. Whole western
society loves the myth of intelligent jerks... Like Steve Jobs. "it's ok to be
an asshole if you are smart".

------
StillBored
Worse is when you know another part of the company is sabotaging what your
trying to achieve.

One might call it the right hand competing with the left, but frequently the
path forward to the next version/product/whatever is pretty clear, but the
existing product teams are well entrenched and of course make all the $$$$, so
its a game of politics, and keeping a low profile while trying to gain
traction.

Pretty frustrating in many ways. Especially when you start to gain traction,
then suddenly groups start to take 1/2 steps, which might have been useful and
productive years earlier but now just act subversively.

~~~
aloisdg
In my previous work, I learnt that two teams could write two solutions
tackling the same problem. After two years, they would each present their
solution and the hierarchy will keep one.

------
kevsim
This article makes me feel very fortunate to work the way we do in my company.
We have tight feedback loops with our users, we plan work together as a team
(not just a PM dictating things), we're not forced to give finger-in-the-air
estimates (we work on stuff until it's good enough to ship and then ship it)
and we follow up with analytics and user interviews to figure out if we
achieved the outcome we were after. We rinse and we repeat.

~~~
rheotron
Can you say more about how you plan work as a team? Interested to hear how you
keep this fast and productive and avoid getting caught in the weeds of other's
opinions.

~~~
kevsim
I'd say the main factors that avoid getting stuck in the weeds of opinion vs.
opinion are:

\- Focus on the outcomes you want to achieve, not the exact thing you're
building or the way you're building it. This should be based on the needs of
your users. Of course there are exceptions like refactoring tasks,
infrastructure improvements, etc.

\- Give people a lot of autonomy on how they achieve the desired outcome

\- Work together across product, engineering and design so people's opinions
are heard early and often

\- Ultimately have a "boss" who can stop the endless discussions if it comes
to that (doesn't happen often)

Another thing is if you feel like you're iterating quickly, you feel less like
stuff is set in stone and that results in less analysis paralysis and less
bikeshedding.

------
fdsa_9983827
I have in the past with (small) clients. This was an upgrade to an existing
product with flagging sales and their proposed direction made me scratch my
head from day one.

However, I both wanted to do the work (it was really interesting by itself)
and they made it clear to me that they didn't want my business input. It of
course eventually went sideways, accusations were thrown around, the partners
split up and I was left with ~18 months of unfinished work that didn't really
get me anywhere (except paid -- never, ever risk your time for someone else's
upside).

I'd say do the work if it's personally edifying and you don't mind the
possibility of weak-minded people trying to throw you under the bus when it
falls apart. If you're an employee, you are not shouldering the risk or
responsible for existential-level decisions (or at least shouldn't be).

Having said that, seek out better teams with a higher chance of success if you
can. Bad teams are sometimes hard to spot because they may look successful on
the surface but may, in fact, be a few bad decisions away from falling apart.

One thing to look out for is founders who have a company because of an initial
period of luck but questionable direction and drive to build something more
sustainable (or larger). I've seen that a lot, even in myself when I was
younger. People incorrectly attribute their success to their skills / vision /
mojo and have enough runway that they internalize those beliefs while ignoring
the slow death of their project.

It's hard to separate that misguided exuberance from a healthier drive. A good
sign is when they temper their confidence with humility -- "we really got the
timing right on the first one". If instead they talk about how they're
crushing it and how "number 2 is going to be 10x" you might want to rethink
hitching your wagon to them. In other words, if a founder ever makes you
cringe while talking about themselves, that's probably your intuition telling
you they don't really have what it takes.

------
rhacker
I'm working on something that uses Hyperledger, so yeah.

------
tappio
Nice write up of the problem, but the solution is not that simple. Not saying
that you shouldn't try, but the problem of doing something that customers want
is extremely difficult and has a lot to do with luck. We have implemented many
features no one wants, and many features that the users wanted and use. It's
impossible to know the outcome beforehand. We have always discussed with the
customers before hand, but that does not mean the feature is going to be used.
Even when customers are paying for something it does not mean they really use
it. So "Don't just build Something™, build an industry leading product that
customers want and love" is nice and catchy, but the reality is never going to
be that easy. And how do you even know if you just did it the wrong way? If a
small change would have changed everything? You can't really trust people
either because they don't know what they want. You can't trust analytics
because you don't know if you are measuring right things? When do you know
that no one wants a particular feature?

Putting yourself to a pedestal because you've figured out a problem won't help
for sure. Be humble and accept that figuring out the right thing is hard work.
Most often people are doing their best, working in silos or else where. Most
product managers are not there to make your life terrible, even though you
might think that way from the article.

------
vikramkr
This would be an interesting ask HN. I dont think theres much to discuss on
the actual link since it looks like its just some sort of ad for some training
program?

------
alexashka
It's inevitable, isn't it, given that we _have_ to work for a living?

In school they call it 'procrastinating', when you're supposed to be doing an
assignment, but you're doing everything but the assignment?

You can force people to do the bare minimum - I just don't know how long we
can have enough jobs where the bare minimum is better than not doing it at
all, or automating it in some fashion.

This is the question of the 21st century and I'm afraid it'll only be the
upcoming generation of politicians like Andrew Yang who even stand a chance of
answering it in a way that doesn't lead to significant civil unrest.

------
andrewstuart
Sadly most of the software I have developed has been "something no-one wants",
but I keep trying because if I ever do build something people want then that's
my greatest professional life goal met.

------
dragonwriter
Nope, everything we are working on someone wants.

Very often, that someone isn’t the customer, but someone in the team’s
management heirarchy, and usually those tasks are both prioritized and poorly
specified and subject to worse requirements flux than customer requirements
(unsurprising, since customer requirements are based on actual business needs,
while management requirements are based on whims, flights of fancy, that-
comment-a-higher-level-manager-just-made-that-gave-me-an-idea-of-how-to-
impress-them, etc.)

Agile methodologies at the team level don’t really protect against that,
though.

------
xivzgrev
Due date driven work isn’t necessarily because that’s copied from
manufacturing. It often seems to be just an accountability and planning
measure. Ie if we (stakeholders) know the thing will be delivered in June,
then I can launch my thing in July and I build that into my forecasts.

If there were no deadlines for features And teams could pivot willy billy
based on whatever they find, cross functional planning would probably be
difficult.

I think the right hybrid for larger companies is some agree on cadence for
adjustments in direction based on customer feedback / learnings (eg quarterly)

~~~
all_blue_chucks
At my company due dates are used purely as motivators. Every date promised to
upper management is absurdly aggressive. I'm told this is meant to instill a
"sense of urgency" to motivate people. It makes new hires burn themselves out.
The few who survive the pressure eventually realize it's all a show and just
get used to apologizing for all their "failures."

------
Havoc
This all seems a little back to front - engineering in a vacuum. I mean sure
it solves the problems the engineering team has but at the cost of making
everyone else's job near impossible.

"Date scrum" isn't an anti-pattern, it's a basic requirement. e.g.

Sales staff: Please buy our product

Customer: Cool. Can I see it?

Sales staff: Not ready yet

Customer: OK when will it be ready?

Sales staff: No idea. Whenever the engineers are done "discovering the best
solution". Also, please sign here to commit X millions for a solution not yet
discovered that will be delivered by an unknown date.

Customer: _spits out coffee_

~~~
Aeolun
Don’t try to sell a product that doesn’t exist yet?

~~~
jagged-chisel
This seems obvious to non-sales folks: why would you like to a potential
customer about what you're selling? But for some reason, it's common enough
that every software engineer I've ever known has experience with salespeople
attempting to sell things that aren't ready or don't even exist. When
customers push back, Sales comes to engineering with "we can't make this sale
until we've built X. can you have that by Friday so I can get this deal
signed?"

------
anonymous2020
I work as a product owner in a company described almost exactly by this
article. We shipped our important feature last month and nobody's used it yet.
We have a product team totally separate from the engineering department and
they come up with the ideas that we build. My input on the product is valued
only at fairly low levels, around detailed implementation (how buttons should
work, whether users will likely figure something out). I really don't like it,
but at my level, I don't know what I can do.

My primary approach to address this is to push for improved data analytics,
starting with our tracking and pipelines. I do think a data-driven culture can
help lead the team/company in the right direction, and that it can spread from
my level. Progress is being made, albeit slowly.

Execs have some lofty goals of changing the paradigm, but I don't see that
happening in the next 2-3 years. Any advice on how I can help effect
meaningful change from my position? Or perhaps could I be better served
working somewhere else, building better habits.

------
nraynaud
I have a weird story of the same type, I developed a new module on the product
(Quite an obvious one, no need to educate users), and got very little
traction, but after 2 years, but reports and support started piling in. My new
interpretation is that we just had to let the market pick up on it and do its
transition at its own pace (I don’t know if development is paid for yet).

------
gwbas1c
IMO, that's the biggest sign that your job's not going to last very long.

I remember partial involvement in a major feature that I thought was kind of
lame; but it pulled in quite a few engineers and was a major deliverable. I
thought to myself, "huh, I guess customers will actually pay for this?"

Then later I found out that no one actually bought the feature.

~~~
mnm1
This happens so much, I wonder what the effect would be if management actually
got honest feedback and listened to it. I think often the engineers
implementing things know if they will work or not but their opinions are
ignored, if they are even brave enough to point out the things that won't
work. It's the curse of the employee relationship. Employees don't want to
stir things up, so they do what management wants, despite their experience
telling them it'll fail. This is why I don't view success as connected to
whether a project is financially successful or not. Success is pushing to
production. That's all.

~~~
gwbas1c
It wasn't a situation like that, yet.

In this case, we (engineers) had a lot of trust with management because
usually features were developed with lots of customer involvement. (And when
features weren't, they were usually MVP-style to test-market something.)

So, in this case, I pointed out some limitations and immediately got back an
answer that implied that the customer was aware of the limitations and was
more concerned about something else.

That's why I was shocked to find out no one bought it!

Anyway, to further add insult to injury, the new feature added lots of
complexity to the product; complexity that added development cost to further
development.

------
kafan1986
I worked in a startup, that had around 30 employees (15 in tech at the time)
and we had a good product that sold like hot cakes. But due to some issues the
company closed that product down. Anyways, we were looking for new ideas.

There was this new guy who was previously in business development and customer
support and somehow had got his role changed to associate product manager by
talking to CEO, about his passion etc. He suggested a product by reading about
a recently funded company in USA. I, a product manager and another one of the
product manager, simply rejected the idea given very small market size and
complexity of the product and technology required. But CEO bypassed our
suggestion and we did build that product for more than 2 years, putting in
tons of effort and resources, perfecting it but even then there was hardly any
noticeable sales.

------
fofoz
And how many of you are working on something that no customer wants but
Gartner believes is the future?

------
zwieback
Failure of Agile can basically be summed up as: "customer not involved every
day".

~~~
MattGaiser
That much involvement is going to lead to customer driven architecture, which
seems like another failure mode.

~~~
capableweb
"Customer involved every day" doesn't necessarily mean that you let the
architecture or product be designed strictly for the customers need. Point is
to have as much user feedback as possible, to take into consideration (or
purposefully say "we're not considering that").

To end up with a useful product in the end, it's better to err on the side of
involving the user too much, than too little.

------
bluedino
Team 1 and team 2 both internally compete for projects at the same company.

Team 1 already knows their project won't be "bought", but they can't start on
a new project yet, so what's the point of wasting developer time on it?

------
downerending
This describes more than half of the corporate software projects ever started,
IME.

------
Invictus0
I worked at a major defense contractor in a small office for as an intern. The
entire 50 person office was working on a single top-secret contract which very
obviously was never going to get off the ground. After working on it for over
5 years, the prototype was still about as janky as could be and required a
team of human operators to perform dangerous, highly intensive, time-
intensive-training-necessary work just to get it to work. No one could say
anything because everyone would be out of a job, and so, as far as I know, the
project hobbles on.

------
hellofunk
I work for a bank and we’re rolling out later this year some new accounting
management software for our users, to help them keep track of their budgets
etc. Over the last seven years or so I have myself tried using such tools at
various banks I have accounts at, and I could never get into it never really
enjoyed it. I do use accounting software that is entirely separate from my
bank. And some of the ones I used to use were discontinued, perhaps due to
lack of interest. So I’m rather certain that what we’re working on is probably
not gonna be successful.

------
Grakel
Everybody working at Dropbox?

~~~
waheoo
You forgot docker.

------
Apocryphon
Don't want this to turn into a big politics tangent, but I've thought that one
use case for a tech workers union is to be able to push back against
questionable business decisions from management.

I've seen places where engineers and other ICs, some team leads and managers,
those with far more experience and clout at me, voice skepticism against
questionable product decisions coming from upper management, only to receive
nothing in response. Even when these decisions involve infeasible engineering
forecasts, leadership stay the course. The worst they might get is some
uncomfortable questions from the most bold, outspoken senior or staff
engineers during all-hands. And the response is usually some stock party line
about staying the course and everything will work out. Sometimes, this is
coupled with toxic cultures that prevent people from truly speaking out.

Beyond fighting for better labor conditions, an intracompany tech worker
organization should be able to push back against bad management decisions.
Imagine if your engineering guild had power not just to determine the tech
stack or coordinate between teams, but also to check the power of management
on product and technical decisions, or even question strategic business
decisions.

People imagine tech unions will just be a rehash of Industrial Era blue collar
unions, but they have the potential to be something more- a way for the rank
and file to finally have the clout to push back against bad engineering
decisions from poor leadership.

Sure, you can say disgruntled engineers can just leave, or companies with bad
management cultures should deserve to fail. But that just seems like
defeatism. It seems like a form of capitalism that promotes throwaway,
wasteful behavior. If employees have valid concerns, but management ignores
them, doesn't it seem like a shame for an organization to decline and the
product to die because of no one could oppose management's mistakes? What
about the customers?

~~~
sukilot
Imagine if your tech guild had the power to promote tech priorities over
business concerns, and drive the company out of business.

If your tech team is better than management at running the business, quit and
form a competitor.

~~~
Apocryphon
That's honestly not a bad idea- I've seen high exec turnover resulting from
their own mistakes, and much of the engineering team might have been happier
together under different leadership. Worked for Fairchild Semiconductor, I
suppose.

Who's to say that technical priorities aren't worth prioritizing? How many
times do companies treat their tech as a cost center rather than a profit
center, leading to expensive mistakes? I don't understand why one would want
to be an apologist for the Pointy-Haired Bosses, unless they themselves are in
management.

Everyone thinks corporate fiat rule is the best way to lead- until they find
themselves outvoted on a stupid initiative. Perhaps the right way to respond
to it is to vote with your feet, and leave. But again, that seems like a waste
if the course is salvageable.

------
carapace
I don't know if this counts. I worked briefly at a place that was making
sensors for fitbit-style wearable medical devices. One thing that was really
cool was a device that could measure your blood alcohol level. They were
trying to miniaturize it to fit in a watch or whatever.

The investors and intended market are a staunchly Muslim oil oligarchy.

(In case it's not clear: ¿ɥǝ 'sɯǝlqoɹd ǝq ʇɥƃᴉɯ ǝɹǝɥʇ sɹǝlɐʇoʇǝǝʇ ɟo uoᴉʇɐu ɐ
oʇ sɹosuǝs ǝzooq lɐuosɹǝd ɔᴉʇɐɯoʇnɐ ǝɔnpoɹʇuᴉ noʎ ɟI )

------
rodgerd
Everybody should go read Bullshit Jobs.

~~~
jkhaui
Amazing book. The funny thing is I never expected to see it applied to
software engineering - but in this context it's very appropriate.

~~~
tdsamardzhiev
I've been a duct taper all my career.

------
davidgerard
I had one of these, I found my writeup again today. It had an embedded copy of
OpenOffice to read .doc files.
[https://reddragdiva.dreamwidth.org/599841.html](https://reddragdiva.dreamwidth.org/599841.html)
Also, the specification implicitly required the implementation of strong
artificial intelligence.

------
osrec
Not meaning to make sweeping generalisations, but in my experience, any
company that mentions AI or machine learning too many times in there promo
material seems to fall into the rather unfortunate categories of "working on
something that no one wants" and "working on something unlikely to yield
useful results"

------
danielovichdk
A lot of software is used because there is no better alternative. So it become
the norm to use a certain product because there is nothing better.

Every phone OS is absolute shit, and in reality no one wants it, but we have
no choice. So it because the norm and we quietly accept it.

Not to mention a lot of frameworks and languages.

------
cwp
No. We know people want this. Many existing customers joined the wait list to
try it, and a few employees are using a ludicrously inadequate alpha version.

We might get the details wrong, but _somebody_ is going to make a killing with
this in the next few years.

------
democracy
Many of the features can be a total waste of time, true, once we spent 3/4 of
a budget building UI for the product whose biggest customers (95% profit)
never used UI. But then again, business plans change, some features need to be
customer-tested, etc.

------
qqj
at the previous company i worked for, we were developing _several_ products
that either no one wanted or were so bad you wouldn't use even if you could
for free (i didn't even install the app thing on my phone because of how
morally corrupt our mobile team was).

we had bizdev guys running around making deals in third world countries, and
pr dept. working overtime just to create the illusion something was moving.
r&d dept went through like 3 org restructures within span of 6 months, for no
reason other than to satisfy the ego of r&d vp. i mean, i've seen politics
that would make machiavelli seem virtuous by comparison.

it was beyond bizarre.

------
tupac_speedrap
This is pretty common in government. We have way too much duplication between
projects so somebody gets the bright idea to replace all the standards with
one standard but it doesn't get traction and basically doesn't get used.

------
JustAnotherVC
Love content like this, just goes to show that we're really just scratching
the surface of dev products and startups.

Kinda like cockroach db and hasura built very well funded startups around open
source products.

------
collyw
No quite as bad as that, but we are a feature factory, expecting the next big
contract to make it. Instead we keep on adding tons of features to an already
large product with a tiny team.

------
stefan_
That's not how it usually goes. It's more like: How many of you know that the
team is working on something that will never be released?

------
GoinginSircles
Throwaway on this guy, but I actually was ground zero on a project like this.
The rabbit hole went incredibly deep.

I was a pretty new hire at a small computer repair company with an absolutely
manic CEO. The guy was an egomaniac and thought that because he owned a
computer repair company (mind you, he has zero tech skills, his partner was
the one who did all of that), he was the next Steve Jobs.

I originally got hired at the company to do work on their web SEO "business
division".

By "business division", it was a 12 man team building Wordpress sites for
about 5 clients. No version control, no backups (unless you count zipping the
WP install and leaving the archive in the same directory on the server),
paying nearly $1200 for Enterprise Azure for traffic that didn't even equal
10,000 hits/mo across all clients.

It eventually got around I knew what I was doing, so I got pulled off to
another project--one to architect a custom backend for a new idea the CEO had.

One of the other coworkers at the company (who did everything in PHP--and I
mean literally everything), had built a wheel interface in a web browser.

The CEO saw the wheel, and decided that the interface was going to be a social
media app. Literally form over function.

The app quickly got convoluted because there was literally zero project
management. We would literally get ideas from the CEO in an email and we'd
start to work on it until he got the next big idea. There was zero
accountability to what we were building. We would be interfaces and logic that
would get torn down or hacked 6 months down the line. We spent literal months
building this convoluted 6-7 layer deep wheel interface to make a Yelp rip-off
clone.

Imagine you wanted an estate lawyer? You would have a wheel of 7 elements. One
was "professional services". You'd circle the wheel around and click on it.
You'd then get 7 more wheel elements. You'd circle the wheel around to
"lawyers". Once on lawyers, you'd scroll around until you found the icon for
"estate lawyer" and when you hovered to it, you'd get an interface on the top
of recommended lawyers based on some constantly changing algorithm of friend
recommendations and geo locations.

This app was in development for nearly a year and didn't see a single user
until around 9 months in (where we posted "gigs" to Craiglist, promising money
if you were a "top user", but I don't think anyone got paid).

We never did a formal launch because we kept building and building and
building.

We added business recommendations first. Then it became movies and other
media. Then we build a friends list that let you put in contact information
about your friends (we rebuilt contact list). Then we built a tracker that
would ping your location at few minute intervals and store it and a timestamp
on our server. Then we built an aggressive scraper that would scrape your call
history and contact list, store it to our server in plaintext, and then query
each phone number in a plaintext query to Google to see if we could match it.
We build a "pre-fetcher" that would aggregate data and scrape images from
Google Images and build business profiles we'd pass off as our own.

The list went on and on and on--all while rebuilding the friends privacy
settings over and over.

The entire time, I desperately wanted to find a new job, but couldn't because
the economy was shit. I constantly was berated and yelled at. Promised equity
but never got a statement. Pay was terrible (they bait and switched me with
the SEO pay).

Finally after some unreasonable disagreement with the CEO, I was "indefinitely
on unpaid leave" (I was basically fired without being fired), so I just quit.
I got a call with a death threat days later.

Luckily, I landed another small time job shortly after. I ended up suing the
previous company, but they hired the biggest defense firm in the state to
stall out--so my lawyer bailed. Not before they called me, leaving me a second
death threat for hiring a lawyer.

------
kderbyma
I haven't finished the articles first paragraph because I can't stop laughing
when I read the title - it's too true

------
emersonrsantos
Do it like Amazon, have two pizza teams.

------
dahfizz
I work on a team that makes a product for actual customers. They tell us what
they want and we do it :)

------
kmclean
> Instead, they are usually focused on making sure the team is building what
> their boss thinks should be built.

This rings so true. I vowed to never again work with companies with non
technical leadership for this reason. My career so far has mostly been
building features nobody wanted for people who are trying to impress
management and/or VCs.

> The less technical the dev manager is, the more likely they are to be
> ignorant of technical debt, that is until customer escalations become
> politically untenable. This life cycle is why the engineering VP job has
> about a one year lifespan at many companies who run Idea Silos.

I've never heard of this concept of idea silos before. It makes so much sense.
At my last company it was even worse. I had 4 managers over 2 years, yet the
more senior management gave the VP of engineering free reign to make whatever
changes he wanted (yes, they were all men), so the system was a cobbled-
together mess of half baked features as a result of each manager coming in
trying to make sweeping changes to show off their "scrum" skills.

> Engineers are problem solvers, and if the primary problem becomes delivering
> Something™ that will pass QA by the Date™, they will, with enough pressure,
> solve that exact problem.

Ahhh I can't even handle how accurate this is. You should have seen the
spreadsheets and meetings we had about sizing and building roadmaps. The
entire engineering department's job became keeping managers at bay by
producing roadmap items on schedule. There were meetings upon meetings about
"metrics", which were just numbers we made up but put into a fancy
spreadsheet, because doing calculations on made up numbers makes them appear
more legitimate than raw made up numbers.

The majority of the effort of our department was wasted on features nobody
wanted. They sounded impressive and apparently were cool enough to keep
investors satisfied. This company also went to great lengths to re-brand
itself as an "AI" company, whatever that means, even though none of the people
in charge had the slightest idea what AI was really capable of or how it would
benefit the business.

The worst part is that it took so long for me to realize I was wasting my
time. After the third major feature I delivered to be used by absolutely
nobody I realized we were out of sync with reality. I thought I had made this
great discovery and was almost excited to bring it up because I thought it
would be a great opportunity to change to do better by our customers. Instead
I was met with a response that essentially amounted to "shut up, know your
place, and give me code", which is when I realized I was really just a cog in
this machine designed to get engineering VPs bullet points for their CVs, and
left.

------
pjmlp
Plenty of times, but I always see it as a curriculum improvement opportunity.

------
yters
Don't a large portion of IT projects fail?

------
monadic2
Why not just quit? You’re 100% a re-hirable asset under better management.

------
magwa101
Always about AI.

------
newaccount12345
My manager (a director) at a FAANG used to give me (and only me, justified
with my strong background - though he used similar tactics on others) tasks
that couldn't be solved and didn't have any business justification so he could
keep me from getting promoted. The first few promotion cycles I still tried to
find alternatives (X doesn't make sense, but Y would reach similar goals in a
reasonable way), but the motives were quite clear.

At first I was looking for ways to move within the company (I was hired in the
wrong part of the organization and on the wrong level, making this a bit
difficult) and started working with other teams to be able to switch, but I
realized it wasn't really worth it because most teams were building things
that were very strongly driven by VPs and directors own motives rather than
users or even what is good for the business. [1]

My impression was that this is partially driven by several factors: \- the
very strong market position means customers don't really have a choice. It's
actually rather hard to make good decisions when the market can't give you
good signals. Situations would arise where one customer wants something,
another wants the opposite and both may have a negative short-term impact on
the bottom line. The lack of competition to really verify which decision would
be successful gives too much power to the decision maker with really bad
incentives, leading to some suboptimal decisions (unless there's a strong
long-term strategy that is followed through). \- the drive to make "data
driven" decisions, without understanding what that really means. Depending on
how the data was presented, completely different conclusions were possible and
instead of using common sense with the data, this was treated as an absolute
truth to end many discussions. What quite frequently would happen was
optimizing towards the wrong metric or underestimating bias. \- Silos created
by people who were hired at a different stage of the company. Some of the
managers just hadn't grown with the company - people who were around for 10+
years were hired for much smaller revenue und user numbers and this further
increased the problems with the two points above. My impression was that the
incentives weren't well aligned with overall goals of the specific product.

I think the solution in the article above would be a good way to avoid some of
the problems I've encountered, by creating a more direct feedback loop between
the product and the sales side and aligning incentives better. I don't think
it's the best way how many companies grow with very diverse sets of offerings
to have huge sales and engineerings orgs, rather than smaller groups that
cover the product end-to-end. It's still possible to have many of the benefits
of being a large enterprise (shared talent pool, operational processes, costs
etc.), while avoiding the drawbacks.

[1]: I can't share evidence, but this particular company is well known for
discontinuing popular services.

------
weeboid
I believe the TLDR of this article is, "skunkworks"

