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.
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.
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.
Wow. No wonder soo many engineers are dumb.
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'.
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.