

Your job is not to tell us how to do our job - a-ghost-fart
http://www.privatepaste.com/580c63478e

======
onion2k
_Does 2% of our user base use IE8 on Windows XP and the expected revenue from
those sources is less than the cost of supporting that platform? Then I’m
sorry, but they can fuck right off. That’s not worth the time it takes to
support._

That decision is absolutely _not_ the place of the developer. Failing to
support a particularly market segment has implications far broader than simply
the bottom line dollar value of each user. Even if those users bring in _zero
revenue_ it can still be worthwhile developing the code base so that they're
supported. This sort of thing is an example of something that you, as a
developer, simply aren't equipped with the necessary information or knowledge
to make decisions about on your own - it _has_ to be a collective decision
informed by developers, marketers, product managers, and C-level managers.

A trivial example - the decision whether or not to go with a single page
Javascript application design versus rendering pages on the server can be
influenced by user demographics but have a _massive_ impact on _everything_ in
the business from hardware costs to how you integrate payment reporting in to
the workflow of the business.

Any developer who puts their needs in supporting particular users over the
requirements of the company as a whole, frankly, probably ought to be shown
the door. They don't understand how the whole business process works and they
will almost certainly screw up something really important later.

~~~
crazychrome
The view that developers are just coders to implement business requirements
shall simply follow instructions/specifications is dangerous. The attitude of
"my way or highway" is absurd if you really understand how organization/team
works. It's your job, as a project manager, to not only provide material
supports for your engineers to do their work, but also translate business
logic into clear, acceptable, feasible and inspirational vision to your dev
team. Engineers, on average, are smart and reasonable people. It's your
personal failure being unable to convince engineers on "why" questions (e.g.
why support IE8 on XP).

btw, 90% of business fail. it means 90%+ of the so called "business
requirements" are just bs. it doesn't hurt to explain your business to your
engineers. Can you sell your ideas to team? if you can't, it's a bigger
problem than couple of _naughty_ engineers.

Edit: delete the last line considered offensive.

~~~
bradleyland
The parent poster said nothing deserving of this rebuttal.

------
wkearney99
"That’s not worth the time it takes to support."

THIS is wrong. What missing is the dialog behind what determines what is or
isn't "worth the time". If you're paid to dig ditches and you don't like
digging ditches... well, perhaps you should get the fuck out of the hole and
get some other job.

Realize, it's all about communication and that goes both ways. That it's
tedious to support something is irrelevant if the target market requires it.
That YOU don't like it, well, get out of that ditch. FAR too many "developers"
fail to make this point effectively. Yes, at a certain point there's a
diminishing amount of return. But not without actually having that discussed
in language that ALL parties involved understand. THIS is often a LOT more
tedious that the software support, at least for a lot of "developers". Yet
failing to do this leads them precisely into the proverbial ditch.

------
ukigumo
The author of this article does himself a poor service by exposing the limits
of his knowledge and his unwillingness to learn from others.

Being a good coder is really nice, and you earn loads of cookie points with
your team members and even some of your managers, I'm sure, but a valuable
engineer (the kind who is trusted to make decisions about products) is one who
understands how the scope of his activities affects the product perception for
the clients and, ultimately, the bottom line for the company.

Want an example or two? Sure. 1) If 2% of your users represent ~20% of your
revenue their concerns and requirements will be prioritized accordingly.

2) If you need to know a specific set of information that you don't have
access to at any time, ask for it. If such information is not available, raise
that concern and work with your team and the product manager to make a
judgment call.

~~~
a-ghost-fart
I'm not entirely sure what point you're trying to make here.

If you're insinuating that I don't think of the wider business value or the
business as a whole then that is just false and what I have written is not
meant to be interpreted as such.

Also your examples seem to be non-sequiturs, neither are relevant to the point
I've made.

~~~
ukigumo
There's always a rift between what one means for other people to understand
and what they actually do. Case in point, I thought I had made a clear
statement that I thought your post was disingenuous and immature and did you a
disservice by casting you as more of a coder than a valuable engineer.

I'm not saying I'm right and you are wrong, I just made a reflection of how
you came across. Was that clearer now?

As for my points being non-sequiturs, I'll admit that I fail to see _any_
point in your post other than you don't know what a product manager _is_ and
you feel attacked somehow, so there's a fair chance you are right.

~~~
a-ghost-fart
It's a direct response to the original post, visit the link at the start. The
point is answering the points raised in that product owner's post.

My point is that product owners should stop telling developers how to do their
job, especially when the "advice" they offer is without value at best, and at
worst insulting.

------
Mithaldu
I find both of these to be a little counter-productive. As it is, the tone of
both of these posts just serves to alienate people from one another and to
harden the lines in the sand by straight-up dropping anti-tank fortifications
on them.

My answer to the original post would be this:

"" Some of the problems you are seeing sound fascinating and i have never ever
seen them in any team i worked with. I would love to hear more about them.
Some of the other problems you mentioned I have seen crop up, usually only
when there has been a disconnect in communication between developers and
managers.

This is an opportunity for both of us to learn some things, if we engaged in a
dialogue on the matter.

You have chosen to post on two platforms where no useful manner of dialogue is
offered, so it would need to happen elsewhere. If you're up for it, what would
your preferred platform be? ""

------
Kurtz79
As a SW Engineer recently turned Project Manager, I find the original post of
the "Product Manager" patronising, ignorant and offensive.

It seems to say "Your job is not to code, your job is to code and in addition
to do my own job as well".

Technical/funcional requirements to satisfy, platforms supported, how to carry
out changes made over the production environment, should be all decisions made
by the product manager in agreement with sales, his boss, and of course the
development team itself, to ensure that they are feasible.

If he has not the necessary technical knowledge or he cannot be bothered to
take these decisions himself, he has no place as a product manager.

------
eitland
> My job is to deliver robust solutions for the target users in the quickest
> time possible, and if that means dropping support for a barely used browser
> or something that’s not financially viable, then I will argue tooth and nail
> to drop it.

Eh. I am a SW engineer and guess I can't be the only one to be happy whenever
I don't have to decide the cutoff point for web browsers.

I can be opinionated on this and other points yes, but I strongly disagree
with the tone of the post.

------
dozzie
Response to a post from a _product_ manager is addressed to _project_ manager
O_o

~~~
a-ghost-fart
I realised this after the fact then thought, hey, my bugbears with project /
product managers are fairly interchangeable.

------
shurcooL
I was very surprised to learn that "focussed" seems to be a correct
spelling/variation of "focused".

~~~
a-ghost-fart
British English, innit. :)

------
Beltiras
Who else thought of this line in Fight Club?

“You are not your job, you're not how much money you have in the bank. You are
not the car you drive. You're not the contents of your wallet. You are not
your fucking khakis. You are all singing, all dancing crap of the world.”

