[cateye]

This article and many people attempting to analyze this topic (and many others) are missing a key element: "incentives"!

Many developers are more passionate about technology itself – coding, solving complex technical problems, and creating efficient solutions. Their formal rewards (like promotions, bonuses, and recognition) are often tied to technical achievements. If a developer spends 40 hours on customer research, this effort might not be as formally recognized or rewarded as much as a technical achievement like developing a new authentication solution that benefits the entire team.

Shifting this dynamic is not just about encouraging developers to spend more time on product management. It requires a systemic change in how organizations value and reward.

Changing the incentive structure to be more user-centric and less technically focused would significantly impact middle and upper management roles. A shift would challenge the very foundations of their roles and responsibilities, potentially leading to a loss of control and influence.

It's likely that such changes would face subtle yet strong resistance from middle and upper management. These individuals often have significant political power within an organization and a vested interest.

[atoav]

This isn't that hard. Just have your developers train people with your software. In every craft you learn the moment the rubber hits the road. A film director can watch the film in the editing room a thousand times, but the one first time watching it with a real audience will teach them more than those 1000 hours together. A carpenter can work away on a piece of furniture merrily all week long and be happy with themselves, but the moment of truth comes when the furniture is placed into the customers room. The same is true for software. If you want your software engineers to care about users they have to get first hand feedback what works and what sucks, preferably with their own eyes.

Every software engineer worth their salt has a certain degree of pride about doing things well. If this only ever is about the code, the commit history or other abstract concepts, but never about how well it can be used by the actual people it was made for, then how would they even start caring?

[vwolf]

I can attest to that. I had worked on a product for a couple of years and received feedback from our support team, but never seen how the product was used in real life. One time, we had a specific bug that the customers were complaining about, and no matter how they described it, we couldn't figure out what the problem was. That was until I went to one of the customer sites and saw how the users were interacting with the product.

When they tried to demonstrate the bug, it was immediately clear to me what the issue was. That was the first time I really grasped the difference in how we approach software products. It also helped me see how the product could improve their job by watching how the process was in real life. Gave me a lot of ideas on how to make their job easier by using the product.

[quickthrower2]

“Incentives” if you do this you better make it pay so I never have to leave. If I have to leave to get a payrise then I am getting on the Omega Star team and slowing down their ISO timestamp roll out to get GraphQL on my CV, so I can hit levels.io and get that extra $100k TC. /s but Poes law applies.

[madeofpalk]

Heh it's funny that your takeaway is "managers hate this". I know a lot of developers who would hate such a thing, thinking the only thing developers should do is write code.

[SigKill9]

Thanks for the comment. And I completely agree. Incentives shapes so much of how people work. I tried to capture that in the 3rd bullet, but your comment is more on-point :)