The product manager, whether it is a formal position or not, or even if the actual pm differs from the official one, is the one I listen to.
The reasons are simple: he knows the product, he has stakes in it and the responsibility of managing its direction. Therefore I can and will provide my expertise and my opinions but ultimately the choice and the repercussions aren't mine.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Defer to the person who you determine to be the SME in the decision and has some investment in the outcome (i.e., some "skin in the game"; is a stakeholder). For system-level architectural decisions, someone in the architect role is a natural choice. For product-level decisions, the Product Manager has the ultimate decision making authority (within reason). For technical decisions, a senior developer is a good source of wisdom and best practices. Ultimately, however, all decisions have to be made by yourself--even if the decision is to defer to a SME.
One major problem that has plagued me for all my professional life: How to get anyone, whoever they might be, to give any decent feedback at all. It is like when you send out any document for comments on the technical contents: Two thirds of the reactions span from spelling mistakes to unintended double space characters.
You propose an API, and they bring up a long discussion about the names of the formal parameters. You have used a GUI prototyping system for presenting a functional demo, and the main feedback is that the boxes should have rounded corners. Things like that.
That is if you get them to say anything at all. It really is difficult to get any significant input at all, something that matters, in specific questions. General rules are no problem ("In method xxx you are not honoring our company indentation rules" or "Our company's software should follow ISO standards so-and-so"), but essentially, those are things that neither team members, managers nor marketing people need to see my specific code, those specific decisions I have to make. They are all general, specific-decision-independent statements.
If you are lucky, you get a chance to present your alternatives to actual users, and to explain to then the consequences of choosing A rather than B. Then you might get some decent response. But very few of us get at real chance to meet users at that level, and given the freedom to ask for their input. (I am obviously talking about non-technical users - not the kind of software and users where you can ask them to generate a pull request with the proposed changes.)
I'm the team lead, so 2 apply for me. I listen to the Product Manager because they, like me, were a user of the product at one point and have actual domain experience. I also listen to two other team mates, both of who have been supporting/developing the product longer than me. The rest of the team mates all take direction from me.
That 5 answers:
* team lead
* product manager
* (some) users
* (some) team mates
Keep all things as simple as possible, but no simpler. -said someone, somewhere
The question should be specified more! What kind of decisions? In-app architecture? Then I will probably ask my team mate. Enterprise architecture? Then probably the architect is the person to talk to. Features? Totally different story!
Because a lot of development decisions seem the have been make by marketing and U/X folks, and not actually by technical people that know what they are doing.
And if you need any evidence to support this, just look at the gross failure of Microsoft, versus the tremendous success of the technical expertise based software of the *nix communities, in non-technical markets.
I actually don't even hate to say it. But if the person who is paying the bills is happy. Usually everyone is happy. I have quite often in the past had a PM or other go between miss-hear what the money person says. When I double check(annoys the go between) I end up with a clearer picture and the go between actually gets a clearer picture as well.
Money talks and BS walks people
To err is human to really elephant it up you need a computer
I listen to my boss(es), since they sign my check. They also set my priorities, which helps me spend my efforts where they do the most good.
I listen to my coworkers, since we cooperate well and respect each other' domain expertise within our products. In one case that respect extends farther into general issues since he's a smarter programmer than I am.
I listen to my users, because I do the UI's for our products. UI/UX development has the same basic precept as writing: consider your audience. If you fail to do that, it's immaterial what you've implemented.
(yes, I know 'depends on the situation' covers this case)
if it is a good idea, I don't care where / who it comes from...
if it is a bad idea, it depends wether he / she sits higher than me in the hierarchy and/or is possible that he/she have a look to the code and understand enough to see I ended doing what I wanted and not necessarily what I was told
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.