What can we do to make software engineers obsess over business metrics rather than tech
If absolutely all software engineers obsess over business metrics rather than technology it would be net-net great outcome for the ecosystem as well for the individual economically, socially. I find it childish when a CTO/Architect/Principal engineer obsess over code & infra architecture, low level/high level design, scalability. Outcome: --- I want engineers at all seniority levels and all disciplines must only care about biz metrics. Product management should cease to exist. Everything tech will fall into place. If you were the product manager of the "bangalore", how would you approach this? One approach i thought - --- To get into Bangalore tech ecosystem you must need a certification from a institution (For ex: Tech School), absolutely mandatory from this school irrespective of your college background. This tech school will allow everyone to enter, online lectures, teach customer empathy, research, industry standard tech, product management, design. Aim is to set correct mindset for growth and first principle thinking. This will make college background irrelevant.
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
Engineers are naturally analytical.
Putting builders close to consumers is always win win for everyone involved.
BengaluruLandLord
Stealth
a year ago
Hey. That's such a wishful imagination. 'they won't be good at it' 🤦
Though am from analytics and ds background, I strongly feel every engineer should know the cost of him building the product right, cost of messing it up and exact visibility of his product usage.
That way he will solve the right problem, be lean and provide high reliability, plan exactly to reduce the cost of something going wrong.
This is basic.
OnADietCoke
Stealth
a year ago
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.
BengaluruLandLord
Stealth
a year ago
Wow. No wonder soo many engineers are dumb.
OnADietCoke
Stealth
a year ago
Tell me, does it make sense to you calling engineers dumb when they are in fact required to build out the fundamental platform or idea?
Please feel free to have opposing opinions but just don't make a gross generalisation of an entire set of professionals to be 'dumb'.
See more comments
Bumpy_Stock
Stealth
a year ago
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
Bumpy_Stock
Stealth
a year ago
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.
OverdueTrim
Stealth
a year ago
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.
Why are you updating ki version ? - stability? New features?
What will happen if you achieve increased stability or new features? - reduced error rates or faster & predictable blue green deployments
So what ? - maybe your MTTR improved
So what ? - % of revenue loss due to deployment/infra related downtimes reduce.
See at the end almost everything is bound to a business metrics.
Outages in complex systems are rarely attributable to 1 issue like the lack of the latest Kubernetes version. How do you attribute how much revenue loss was prevented due to this upgrade if its absence doesn't directly lead to an outage but contributes to it? I think it's very hard to attribute change to a business metric to 1 issue in complex systems. Heck, there's an entire field of data science around causality that's attempting to solve this problem - it remains generally unsolved.
Similarly, there will be a lot of multi-factor attribution problems when trying to gauge the business impact of everything in engineering. Sure, you can hire a team of data analysts and data scientists to maintain all sorts of metrics. Heck, maybe even train all engineers to do it themselves. But will all of this lead to any tangible business impact? Is this the best way to spend all those resources to generate business impact? Hard to predict and once again hard to attribute.
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"?
A ton -
- Loss of revenue per MTTR spike
- Rate of reduction of MTTR
- Rate of change of revenue loss attribute to slow queries
- Resurrected revenue for customers whose SLA breached
etc.
BengaluruLandLord
Stealth
a year ago
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.
Discover More
Curated from across
