4 ms·

Very HN article. The only job that matter in an organization is developers, product managers are useless, marketing is when you don't have a product, sales peop

by polote 4y ago

Very HN article. The only job that matter in an organization is developers, product managers are useless, marketing is when you don't have a product, sales people are liars, Support people prevent developers to know the problems and so on. It's cool sometime to have developers with a product mindset, because they understand better the value they are bringing and can help brainstorming. But first if you had only product-mindset people everyone would want to ship different features and nothing would be shipped. And also the more time developers spend understanding customers the less time they spend coding. I should probably write a satirical article arguing that "Coding should not be left to developers as product managers should code things much closer from their plan"

devoutsalsa 4y ago
You're not seeing the bigger picture. Within developers, you have the 10x developers. But within that, there is the 100x developer... all of a company's success can be attributed to a 500kg neckbeard in the basement powered by a caffeine-adderall intravenous drip (for playing video games, all the actual work is outsourced to that one guy in Afghanistan => https://www.theonion.com/more-american-workers-outsourcing-own-jobs-overseas-1819594812 https://www.theonion.com/more-american-workers-outsourcing-o...)
nrawe 4y ago
I agree with your sentiment about the pros/cons of developers having product mindset. I don't know that this a HN-specific thing, but I think roles very easily become tribes, and everyone thinks their tribe is superior. E.g. I know architects who think product and engineers serve architecture, I know engineers who think they know better than product and give the "yeah-yeah" to architects, I know product managers who hate architecture and engineers because they don't see the progress they want. I often see this as a struggle for power, normally in situations where there isn't good psychological safety/team focus/communication, which leads to a scramble for authority.
Der_Einzige 4y ago
I don't care if you view that line of thinking as something worse satirizing. Companies who treat developers as kings and get out of their ways produce amazing products, content, and experiences. Valve is my favorite example of this. More companies should strive to be like them.
- quickthrower2 4y ago
  I don’t think treating devs as kings is necessary or sufficient for great products. But treating developers well does help. Micromanaged developers will produce great KPIs (close an unfixed bug to stay on target for # JIRA tickets whose status got changed) but not a great product.
MrJohz 4y ago
I don't think the article is saying what you're describing at all, or at least, if it is then I missed it. As I understand it, the article is basically just claiming that to become an outstanding engineer, you can't just code what you're told to code, you need to understand why any particular feature is needed. Obviously that doesn't replace user research, project management, business leadership and strategy, or anything like that - no developer will also be an expert in all of those things, and a good business, like any team, has differentiated roles. But a strong developer understands what's going on in other places - they understand the overall business strategy, even if they wouldn't be able to come up with a strategy on their own; they understand how users are interacting with their product, even if they aren't doing the user research themselves, and so on. I've worked with a number of developers for whom this sort of thing was a complete mystery - they could program very well, but if they were told one day to build one thing, and the next day to build the opposite, they'd just go away and do that, and never question why their instructions made no sense. Whereas a more senior developer would want to understand why they're getting contradictory instructions, and try and explore whether there's a non-contradictory solution.
- polote 4y ago
  Well here is the conclusion of the post > Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
  - MrJohz 4y ago
    Sure, that seems pretty reasonable to me. Features themselves are broadly a software concern - software developers are in the unique position of being able to say what their code is capable of, and so it makes sense for them to be proposing features as solutions to the problems identified by other parts of the business. That's not to say that the development team should never accept feature suggestions from other places - when a user is very clear that they need a particular button, or the business team clear that they need a particular feature to compete in the market, then sure, that also makes sense. But I think the danger in software teams is less often that they only develop what they want, and more often that they only develop what they've been told to develop, and don't connect the dots. As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently. As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.

by polote 4y ago

devoutsalsa 4y ago

You're not seeing the bigger picture. Within developers, you have the 10x developers. But within that, there is the 100x developer... all of a company's success can be attributed to a 500kg neckbeard in the basement powered by a caffeine-adderall intravenous drip (for playing video games, all the actual work is outsourced to that one guy in Afghanistan => https://www.theonion.com/more-american-workers-outsourcing-own-jobs-overseas-1819594812 https://www.theonion.com/more-american-workers-outsourcing-o...)

nrawe 4y ago

I agree with your sentiment about the pros/cons of developers having product mindset. I don't know that this a HN-specific thing, but I think roles very easily become tribes, and everyone thinks their tribe is superior. E.g. I know architects who think product and engineers serve architecture, I know engineers who think they know better than product and give the "yeah-yeah" to architects, I know product managers who hate architecture and engineers because they don't see the progress they want. I often see this as a struggle for power, normally in situations where there isn't good psychological safety/team focus/communication, which leads to a scramble for authority.

Der_Einzige 4y ago

I don't care if you view that line of thinking as something worse satirizing. Companies who treat developers as kings and get out of their ways produce amazing products, content, and experiences. Valve is my favorite example of this. More companies should strive to be like them.

quickthrower2 4y ago
I don’t think treating devs as kings is necessary or sufficient for great products. But treating developers well does help. Micromanaged developers will produce great KPIs (close an unfixed bug to stay on target for # JIRA tickets whose status got changed) but not a great product.

MrJohz 4y ago

I don't think the article is saying what you're describing at all, or at least, if it is then I missed it. As I understand it, the article is basically just claiming that to become an outstanding engineer, you can't just code what you're told to code, you need to understand why any particular feature is needed. Obviously that doesn't replace user research, project management, business leadership and strategy, or anything like that - no developer will also be an expert in all of those things, and a good business, like any team, has differentiated roles. But a strong developer understands what's going on in other places - they understand the overall business strategy, even if they wouldn't be able to come up with a strategy on their own; they understand how users are interacting with their product, even if they aren't doing the user research themselves, and so on. I've worked with a number of developers for whom this sort of thing was a complete mystery - they could program very well, but if they were told one day to build one thing, and the next day to build the opposite, they'd just go away and do that, and never question why their instructions made no sense. Whereas a more senior developer would want to understand why they're getting contradictory instructions, and try and explore whether there's a non-contradictory solution.

polote 4y ago
Well here is the conclusion of the post > Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
- MrJohz 4y ago
  Sure, that seems pretty reasonable to me. Features themselves are broadly a software concern - software developers are in the unique position of being able to say what their code is capable of, and so it makes sense for them to be proposing features as solutions to the problems identified by other parts of the business. That's not to say that the development team should never accept feature suggestions from other places - when a user is very clear that they need a particular button, or the business team clear that they need a particular feature to compete in the market, then sure, that also makes sense. But I think the danger in software teams is less often that they only develop what they want, and more often that they only develop what they've been told to develop, and don't connect the dots. As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently. As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.