I found myself in a conversation with a junior software engineer friend when she posed this question:
"I don't want to be burdened with product concerns. After all, I'm on the engineering team. Why should I have to consider the users?"
Upon hearing the question, I found myself unable to provide an immediate answer because I simultaneously resonated with and challenged her perspective.
I want to share my dual-sided bias and perhaps find a conclusive response for both my junior software engineer friend and myself.
Before I started software engineering, I was a copywriter for many businesses, as I have once shared here. Hence, I already had a business and entrepreneurial mindset before becoming a software engineer.
Being product-oriented means having a deep understanding of the customer and their needs, which translates into effective communication with non-technical line managers. Let me show you an example;
In my current workplace, I had an experience that made me stand out within the first month of joining. I met a feature that required a message broker to serve as a queue for asynchronous tasks in a Django project. My fellow Django developers already know that tool.
The implementation I met used Redis as the message broker. Redis is a great tool but too expensive to be used as only a broker. I needed to know more about that feature and why the previous engineer used such an expensive tool.
I asked my line manager (who is not technical, by the way) about the feature. He explained it to me, emphasising that the feature is offered free.
The feature's purpose is solely to attract more users and doesn't contribute significantly to the core application functionality.
I understood the assignment, we were deploying the Django application on an EC2 instance on AWS, so I switched the broker to SQS instead of Redis. AWS experts already know what's up! 😂
Using SQS with an EC2 instance costs is FREE! That single switch I made 16 months ago has saved my company about $2400 in AWS cost, approximating $150 per month in infrastructure cost! That is $150 more user acquisition cost per month.
It's a lot!
I wouldn't have known to do that if I had not thought about how the users interact with the feature and what that feature was bringing to the business financially.
On the other hand, If you're working in a huge team where all the business-related concerns have been addressed by a more senior engineer or an engineering manager, you may be getting your daily tasks already filtered to meet the exact user's need while giving optimum value to the business and all you have to worry about is the technical details!
But is that a reason to stick to only understanding technical concepts and ignore the business concepts of the users of a product?
Well, I eventually responded to her like this:
One thing I'm certain of is that major tech companies employ managers who grasp both the business and product aspects.. That means if you're like me, who's aspiring to be a manager at some big tech company, then you must get familiar with business and entrepreneurial concepts because it positions you as a proactive contributor to the company's success!
If you were to offer advice to my junior software engineer friend, how would you respond?
Should all software engineers be product-oriented?