Your job is not to tell us how to do our job
privatepaste.com
Your job is not to tell us how to do our job
1–10 of 21 posts
Re: Your job is not to tell us how to do our job
#2Response to a post from a product manager is addressed to project manager O_o
Re: Your job is not to tell us how to do our job
#3Response to a post from a product manager is addressed to project manager O_o
I realised this after the fact then thought, hey, my bugbears with project / product managers are fairly interchangeable.
Re: Your job is not to tell us how to do our job
#4I was very surprised to learn that "focussed" seems to be a correct spelling/variation of "focused".
Re: Your job is not to tell us how to do our job
#5Who 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.”
Re: Your job is not to tell us how to do our job
#6I 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? ""
Re: Your job is not to tell us how to do our job
#7Does 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.
Re: Your job is not to tell us how to do our job
#8Does 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…
I didn't say I assume the right to drop support, I said I will fight tooth and nail to drop it, that does mean following necessary process to do so. If the specification doesn't change because the stakeholders don't go for it, then that's life.
As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done.
Re: Your job is not to tell us how to do our job
#9> 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.
Re: Your job is not to tell us how to do our job
#10As 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.