Jan 25, 2023
A good product-minded engineer is worth their weight in gold. One critical skill these engineers have is the ability to look at the business and understand why they are asking you to build what you're building. Then figure out if what is asked of you will achieve the intended goals.
Understanding the business
First, if you don't understand how your business makes money (or intends on making money), and how your role and team fit into that equation, then you need to stop whatever you're doing and figure this out. Businesses are in the... business... of making money. Everything else is window dressing.
Second, you need to understand the priorities of the business. What does the business want you to focus your efforts on to help the business achieve its goals (of ultimately making money)? Your team should have its own goals (which at a bare minimum you should know... right?). Understanding how your team's goals roll up into the company's goals means you have a clear path to... drum roll please... understanding how your work makes the business money.
Third, you need to understand the tempo of the business. Is it wartime or peacetime? Is it business as usual or is everything on fire? If your company has good leadership, they will flat out tell you. Otherwise, it's usually intuitive. However, you'd be surprised how many people are oblivious to their environment, only looking up to discover everything is on fire. Tempo dictates your work, and how you produce it. It can also be a proxy for how the company is doing. The big-brained move is to fully understand your company's financial position (as well as how to assess it) and use that to understand what the tempo should be.
Time and complexity tradeoffs
When approaching a task, there is usually an optimal solution and a hacky-as-hell-yuck-this-is-bad-don't-do-this-why-would-you-do-this-please-stop solution.
There are an infinite number of ways to accomplish a goal in software engineering. When approaching a task, there is usually an optimal solution and a hacky-as-hell-yuck-this-is-bad-don't-do-this-why-would-you-do-this-please-stop solution. A lot of software engineering literature out there focuses on the optimal solution, which in a vacuum, is all well and good.
However, the business is probably spending a lot of money on your time. There is an inherent return on investment (ROI) calculation done on your time versus the impact of implementing your solution. As engineers, we don't usually know how much the business is willing to spend on a particular task.
If you're more junior and have a Product Manager, it's easy to just present them a menu of options and have them pick. Give them the pros and cons of each solution and let them decide. If you have a particular solution you think is worth doing, make sure they know what it is and why.
More senior engineers, when equipped with a deep understanding of the business and tempo can make the call themselves on the optimal solution. When asked, they can provide the rationale of why they picked that particular solution. Product Managers usually trust these engineers to make the right call.