This article is part of a series of notes on Gergely Orosz's What is Old is New Again talk that attempts to put his predictions (that strongly resonate with me) into practical steps for smart software engineers.
"Become more product-minded / business-minded"
I like to call product-minded engineers simply a product engineers, because it is important for me to acknowledge, that I own the product I am building.
It is not a nuance.
I have seen engineers not giving much thought about what their code is going to be used for. I have seen engineers not testing their code, because (their own words) the company pays for a dedicated QA person. I have seen engineers not releasing their code to production, leaving it for others (including emergency rollbacks). I have seen engineers ignoring analytics.
And those engineers, IMHO, do not understand the single most important aspect of building a successful, effective software.
Ownership
I did what the task said, why do you put blame on me?
-a random engineer
In some companies, I assume, there is a great chasm in between technology and product people. Product people think about what and why, and then produce a task. Technology then solves the how and deploys the output. If the output backfires, technology puts the blame on product guys, because engineers just did what PMs said.
As soon as you, as an engineer, degrade your presence in the company into how, you essentially became a workforce producing code. And you know machines do replace workforce, do you?
We will never be able to take what from product, because that is the essence of their roles (that's a good thing!), but we can - and should - contribute to why, if not to both.
And this is done by firstly acknowledging, that we, as product and technology together, own the product.
Influence
As soon as you take ownership seriously, a door to product world opens up and you can observe, understand, and influence the business decisions. This is extremely important, because your proactivity can produce or save huge money. And whatever your boss told you about vision, mission and values - just remember that (except for non-profits) your company exists to make profit. The more you contribute, the more valuable you are. 💸
Gergely wrote an amazing blog with practical steps towards this attitude.
And this mindset is simply invaluable in recessions, where every dollar earned or saved is celebrated. You essentially become recession-resistant engineer.
Bonus: Do not be afraid to speak up
It may be tempting to be silent during brainstorming / ideation sessions as an engineer (or not attend at all), because you may thing that product people have much more information about the subject. I urge you to raise your voice for two main reasons:
Your perspective is different. They hear customers (current ones and the future ones), query analytics, see business implications and are trying to make meaningful compromise. But only you can see that the analytics isn't set up correctly and the data cannot be trusted. Only you can see that one feature will take 10x less time to build. Only you can see that the external tool they want to use is missing an API - an important piece for automation. Do raise your voice, do not be afraid to look stupid.
Your opinion is equal to the others. This is especially true for brainstormings. I have experienced this an endless times. What sounds like a stupid idea in my head wins the most votes. You just never know.
Stay tuned for the third note in which I will conclude this series with my thoughts on "AI" replacing engineers.
Top comments (0)