What can we do to make software engineers obsess over business metrics rather than tech

This is just plain wrong. You can't force engineers to care about business metrics and they won't be good at it. Hell it will make them miserable. Tech will fall into place. It never does This is why companies need an analytics/insights team which handles all business metrics and KPIs. Most of these teams fail because either you are not capturing the right information or the bureaucracy overhead is so high that it makes them inefficient

It is a great idea actually. While you are at it you can also train business people to understand the software side of things as well and maybe allow them to work on some of the killer features that they had in mind for the product. Perhaps send them to some sort of training to understand the tech side of things or a bootcamp? Sarcastic response aside, just understand that it is the responsibility of people in the tech side to be bothered more about the tech rather than business side of things unless they have an actual stake in it. Maybe the CTO should have some level of understanding but that's where I would draw the line. For someone developing a software product, if the business is really large they do allow people in tech to deviate to the business side of things like business analysts / developer relations / product owner etc. But the fundamental assumption that all software engineers should be bothered about the business is plain wrong. They are not paid for that. That should not be their responsibility and if that is the case then it is surely will backfire.

What's the end goal? Just to eliminate the PMs?

Lol.

Zabardasti!! OKR kiss liye hai? Putting basic product sense into engineers, sure. Biz metrics - overkill. Also, why are engineers given one task after another non-stop. Work planned in sprints. Doing even tech support or on-call work. The org clearly wants to churn features out of them as much as possible. Why aren't they part of product discovery and gtm initiatives? It's bcoz what engineers can do, product, marketing, HR can't do. It's best if they do what they are good at or what they enjoy.

Whenever I see teams obsessed with metrics I remind them of Goodhart's law: https://en.m.wikipedia.org/wiki/Goodhart%27s_law Obsession with metrics is never a good thing. As long as your engineers are aware of them, and they know to build what users/customers want, it should be enough

OP can become the first ever engineer to obsess over biz metrics. But first, he needs to become a hardened engineer. He will learn algo/ds. Crack there coding interview. Build 5 prod apps. Get Laid off once. Then he will come to Grapevine and share his experience about everything tech falling into place.

If software engineers obsess over business metrics what will business people obsess over?

Have you worked at a place like this? For eg: Meta I have been at a place where this was a part of the culture. In my perspective, this is a tradeoff that leads to the entire engineering org being less capable than others (speaking broadly). This could work if only the management track folks (EMs, VPs etc.) had to be focussed on business metrics. Also, not everything is easy to calculate accurately as metrics. Attribution and causality will always remain challenging to take into account. One question for the OP: How would you design a business metric for infrastructure work? Like upgrading the Kubernetes version. Would it be insanely high because it allows your product to continue to work or pretty moderate as it's a normal BAU responsibility for an infra team.

I think everyone should care about the business metrics. However, obsession should be reserved only for business and PM.

Software engineers don't care about business metrics because that would make them feel obsolete. If they have to justify the cost of making their product as against the business impact, they would realise that most the products they build do not justify the cost. The cost includes employee costs. Software engineering teams are heavily bloated up by inefficient managers who look to become CTO/Principal. SDEs are an overrated lot. But that doesn't still justify the existence of PMs. PMs don't matter outside big techs and new age startups. SDEs have the potential to become good PMs, but a lot of them don't apply their minds

Can you also share a business metric to measure "everything tech falling into place"?

Solution given by you is totally off.. Schools don't solve shhyt. But, focusing on business metric is a basic necessity and engineers that doesn't do it are on the high end of dumb scale. Solution I feel could be somewhat of copy from the culture of analytics & consultancy firms like Mu-Sigma, Fractal, Tiger etc.. just see how they turn their juniors to be business savvy. So they grow their employees from a random analyst to strong consultants & engagement managers. Basically they train to handle stakeholders, present their work to management and businesses. Which would only happen if you know what to solve, what problems exist and their extent and ofcourse how you solve it. And most importantly how to present your work, where all those metric movements come to play. Every software engineer should have a responsibility of the usage of his product. He should know who is using. how they are using and what is the exact cost of him fucking up something or vice-versa what is the value creation of doing his job right. This ownership is a must. And it does exist to a great extent in analytics services companies... Add data engineering to it and data scientists have it by default(same as analytics) But this ownership must exist for software engineers too. That's how they solve the right problem and provide better reliability, open up more innovation and create a very lean & powerful tech-business relationships.