20 ms·

I'm sorry. As a former software engineer and now CTO I have to disagree completely. Adding value is everyone's responsibility and the product/business/pricing

I'm sorry. As a former software engineer and now CTO I have to disagree completely. Adding value is everyone's responsibility and the product/business/pricing ideas that come from engineering can be as valuable and influential to a business strategy as those from the CEO or PO. If you want to write software that isn't rooted in building business value you should be an academic or hobbyist but in any well run business that depends upon or sells software /SaaS services, engineering should be a critical influence on the business's strategy. If an engineer is just a cog in the machine and doesn't get or care about what they are building, who it's for, and how it changes experience and increases shareholder value then how can they take a wider appreciation of their work and its impact on the real world?

rrgok 4y ago
I never said we should not be adding value. I, as Software Engineer, add value. I write the software ultimately. Whether that software has value for you CTO, CEO or whoever own the software, cannot be my responsibility right? My problem is that seeing value in a software product/service is dictated by the vision of the company and the market. The vision for a product is not a cog's responsibility. To make an example. If all the engineers of Tesla were asked to build a car, not from Elon, but someone else who didn't see value in EV. What would've happened? I don't think the engineers would come up with an EV. The value is create by you CEO, CTO and owners of the product. If Tesla with Elon had failed, is the engineers responsibility to not have produced value? The vision was wrong, simple. Heck, how many Apple/Microsoft products didn't take off and don't tell me they were badly engineered, that can't be the only reason, or the engineer didn't produce value. Wether I write software rooted in business value or has an impact in real world is a moral decision, right? And I think we can both agree that morality has nothing to do with value of a product/service. Example, military weapons. I would not morally do it, but there is value in it right? Who dictates the value of it? If a shareholder invest money in something, it is because they see value in it, right? Or they invest blindly and expect engineers to create value?
- bradwood 4y ago
  > I, as Software Engineer, add value. I write the software ultimately. Yeah, but if you wrote the wrong software (maybe because the PO specified the wrong thing and it wasn't your fault) -- did you still add value? No, you burned story points for no upside at all.
  - rrgok 4y ago
    As I said in another comment. You people keep moving the goal post. If I produce wrong software, it is my fault I agree. But I can still produce correct software without any value. Should I be at fault to producing something you asked for but that doesn't have any value in market? The problem is putting the pressure on software engineers on producing software that has value. This need other competency that the business should study and plan properly. It is not just a software engineering thing.
- computerdork 4y ago
  I think I can see where you're coming from (we engineers are implementers, and not in charge of the vision for the product, which is mostly true). But yeah, I still disagree with your point overall. In my humble opinion, as engineers, it is still our responsibility to deliver value to the CTO/CEO and the company overall. Because engineers have the best understanding of the system, and often are the best counterpart to the business people. We guide them on what is and isn't possible, and even more than that, we often understand the business domain nearly as well as they do (from a more technical aspect). Just off the top of my head, I worked at a US eCommerce company that was trying to open their site to new markets in Europe. The business people designed a flawed payment system because they had a poor understanding of how payments worked. A coworker of mine realized what they had done was wrong and would cost the company hundred's of thousands if it was used, and worked with the business people to rework it (see below for more info). He didn't simply follow what tasks he was given, he saw that he needed to step in and help them pick a better solution. In the end, the goal of the job is to do work that improves the system and benefits the company. You could just focus on just being a great implementer (the ultimate hammer), but to me, this is not how a true software engineer thinks, but maybe how a lower level dev might work. ... And, the problem my coworker worked on was this: the business people decided if anything went wrong with payments in a foreign currency, the system would default to US dollars. This is a bad idea, because this will create enormous accounting headaches and greatly complicate the system. The best solution is surprisingly to let it fail. Yeah, if there is an error in a payment's currency, something is seriously wrong and we need to know about it.
computerdork 4y ago
Agree with you. Have been a software engineer myself for 20 years (and also had, in the past, studied a lot of design and process books in my free time). Yeah, I also think this person's comment is not right. In fact, the second and third points in the list ("the hardest parts of the system are building the right thing," and "The best software engineers think like designers") are directly addressing the fact that devs first need to figure out what to build before they even write any code. Yeah, in fact, one big tweak I'd make to this list is on item #17 ("Keep your processes as lean as possible"). Yes, it should be extremely lean, but the requirements phase should be a necessity for all development. One of the first steps in development should be a thorough collection of info on the task at hand: talk to the users, the business people, the former engineers, and anyone else that has any connection to the change you're about to make. You'll solve dozens of problems before you even write a single line of code. Yeah, agile overall is how we should work, but personally, think requirements is the one step that needs to be emphasized and even defined in greater detail. I know this doesn't directly tie to "adding value" but solving the correct problem for your business almost always adds value.

rrgok 4y ago

I never said we should not be adding value. I, as Software Engineer, add value. I write the software ultimately. Whether that software has value for you CTO, CEO or whoever own the software, cannot be my responsibility right? My problem is that seeing value in a software product/service is dictated by the vision of the company and the market. The vision for a product is not a cog's responsibility. To make an example. If all the engineers of Tesla were asked to build a car, not from Elon, but someone else who didn't see value in EV. What would've happened? I don't think the engineers would come up with an EV. The value is create by you CEO, CTO and owners of the product. If Tesla with Elon had failed, is the engineers responsibility to not have produced value? The vision was wrong, simple. Heck, how many Apple/Microsoft products didn't take off and don't tell me they were badly engineered, that can't be the only reason, or the engineer didn't produce value. Wether I write software rooted in business value or has an impact in real world is a moral decision, right? And I think we can both agree that morality has nothing to do with value of a product/service. Example, military weapons. I would not morally do it, but there is value in it right? Who dictates the value of it? If a shareholder invest money in something, it is because they see value in it, right? Or they invest blindly and expect engineers to create value?

bradwood 4y ago
> I, as Software Engineer, add value. I write the software ultimately. Yeah, but if you wrote the wrong software (maybe because the PO specified the wrong thing and it wasn't your fault) -- did you still add value? No, you burned story points for no upside at all.
- rrgok 4y ago
  As I said in another comment. You people keep moving the goal post. If I produce wrong software, it is my fault I agree. But I can still produce correct software without any value. Should I be at fault to producing something you asked for but that doesn't have any value in market? The problem is putting the pressure on software engineers on producing software that has value. This need other competency that the business should study and plan properly. It is not just a software engineering thing.
computerdork 4y ago
I think I can see where you're coming from (we engineers are implementers, and not in charge of the vision for the product, which is mostly true). But yeah, I still disagree with your point overall. In my humble opinion, as engineers, it is still our responsibility to deliver value to the CTO/CEO and the company overall. Because engineers have the best understanding of the system, and often are the best counterpart to the business people. We guide them on what is and isn't possible, and even more than that, we often understand the business domain nearly as well as they do (from a more technical aspect). Just off the top of my head, I worked at a US eCommerce company that was trying to open their site to new markets in Europe. The business people designed a flawed payment system because they had a poor understanding of how payments worked. A coworker of mine realized what they had done was wrong and would cost the company hundred's of thousands if it was used, and worked with the business people to rework it (see below for more info). He didn't simply follow what tasks he was given, he saw that he needed to step in and help them pick a better solution. In the end, the goal of the job is to do work that improves the system and benefits the company. You could just focus on just being a great implementer (the ultimate hammer), but to me, this is not how a true software engineer thinks, but maybe how a lower level dev might work. ... And, the problem my coworker worked on was this: the business people decided if anything went wrong with payments in a foreign currency, the system would default to US dollars. This is a bad idea, because this will create enormous accounting headaches and greatly complicate the system. The best solution is surprisingly to let it fail. Yeah, if there is an error in a payment's currency, something is seriously wrong and we need to know about it.

computerdork 4y ago

Agree with you. Have been a software engineer myself for 20 years (and also had, in the past, studied a lot of design and process books in my free time). Yeah, I also think this person's comment is not right. In fact, the second and third points in the list ("the hardest parts of the system are building the right thing," and "The best software engineers think like designers") are directly addressing the fact that devs first need to figure out what to build before they even write any code. Yeah, in fact, one big tweak I'd make to this list is on item #17 ("Keep your processes as lean as possible"). Yes, it should be extremely lean, but the requirements phase should be a necessity for all development. One of the first steps in development should be a thorough collection of info on the task at hand: talk to the users, the business people, the former engineers, and anyone else that has any connection to the change you're about to make. You'll solve dozens of problems before you even write a single line of code. Yeah, agile overall is how we should work, but personally, think requirements is the one step that needs to be emphasized and even defined in greater detail. I know this doesn't directly tie to "adding value" but solving the correct problem for your business almost always adds value.