[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.

[fl7305]

Writing GUI applications, there's nothing as valuable as standing behind a user who tries to do something for the first time with my application.

Just seeing the moments of hesitation, how the mouse is moved while searching in menus, etc gives me a lot of information.

[wruza]

Watching what and how they do after a month is as valuable. User interfaces have two sides in this regard: initial experience and boring repetition experience. You can optimize for the former, the latter or both.

[fl7305]

Good point. My experience is also that most users don't learn many of the neat features I have built in to speed up their work.

Even if I show them a couple of times, it is often quickly forgotten.

[rudasn]

> That was the first time I really grasped the difference in how we approach software products.

For me as well. I've started my "career" this way, building something very specific for a client (family member) whilst being on prem and having constant and direct feedback, so that's how it was done I thought.

Almost twenty years later, having worked different roles with teams in office and remotely, I have to remind myself, and others around me, that we are building something to be used by real people with real problems and my/your software must not be one of them.

[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.

[atoav]

I don't think your company is worse off if you get rid of those people by giving them a taste of the real world.

[quickthrower2]

No but "those people" is all people, to some extent. All people have life outside of work, like to make more money, see how unaffordable a house is and say "OK I need to earn $200k a year to raise a family the way I want". While they won't be so brazen, there is some effect of "doing thing thing that leads to the carrot". So the company needs to change that carrot - but it is hard because the whole industry has the carrots.

[atoav]

So what you are saying is you have to live with people who demand not dealing with the result of their work, because the rest of the industry is allowing for such behaviour?

Never before have I heard such a good argument for formalizing the job. If architects or civil engineers were to do the same we had building collapsing left and right.

[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 :)