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?
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.
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?
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.
I don't know. Something must be wrong with the way I think.
In your eCommerce example, what is the product/service? The payment system? Is the payment system A? Or payment is B? All these answers are wrong. The product/service is "make the eCommerce for Europe". That service should have value, how is that "bringing to Europe" value a software engineer's responsibility? In order to materialize the "eCommerce Europe" we need a payment system. Now comes the role of the software engineer: design, propose payments systems. A payment system has nothing to do with the value of the product.
My responsibility is to provide a correct, within the specs, payment system. In your example, the first solution is not acceptable (I don't even consider it a solution).
Now suppose you shipped the "eCommerce Europe" with correct payment system. But the product/service "eCommerce Europe" didn't take off as in US. Didn't the Software Engineer produce value? It doesn't make sense to me. The Software Engineer produced the value: designed, developed, tested and shipped the payment system. Thats the value of a software engineer.
If you can point to the requirements you were given, the technical clarifications you sought, etc. and show how you fulfilled them, then you as a SWE did your job. If you happen to have the domain knowledge to challenge the whole thing on principle, that's great - but that's something that should happen before it hits your desk.
I recently got a haircut. It was exactly what I asked for, but it doesn't suit me at all. I tipped my hairdresser (who is great, and I should have paid attention when she said "really?") well, as usual, because it's not her fault I asked for something stupid. Could she have pushed back harder? Sure, but that's not really her job and it would be unfair to blame her for not doing so.
The point is not to just say: "Hey man, I did my job and built what you wanted. It's on you if you asked me to build the wrong shit". While this technically might be 100% correct, in terms of roles and responsibilities in the firm; it is ultimately (a) unhelpful to the business's agenda and (b) not really focused on adding real customer value. Yeah, you did your job, great! But we're still fucked.
If you were wanting to add true value you should, IMHO, be saying "Hold on a moment there, buddy, you are asking me to build the wrong shit -- have you thought about this? what about if we do that? surely this is a better/safer/more effective way?"
All good business/product people I know love it when engineering comes forward with this kinda stuff. It's what separates the good from the great. If you are working in an environment where the CxO, PO, sales guy tells you to "fuck off and just code what you've been told to" the you are so in the wrong job and you need to get a new one. Fast.
Why we are moving the goal post? The problem was not building something right or wrong. The problem is building/producing/delivering something of value. A lot fo wrong things have immense value, and the opposite is also true. How should I know if the thing I'm building has any value in the target market and it aligns with vision of the company? Is it my job to do market research or to build the thing asked for?
To make the point clear, I'm gonna make an extreme example.
If some one asked me to build the next social media to a poor country, where the immediate problem for 80% of the population is to find stable source of food and a shelter, and I'm payed to do so. What should I do? If I don't have the knowledge, as software engineer (which is almost always the case, i.e. not knowing a lot of the business decisions), about the target market, what should I do? Now, as software engineer, should I also do market research? How, I'm gonna know all the business decision about a product? Maybe the people commissioning me the engineer side of the business have already some client ready to buy? How am I supposed to know the business strategy? This is absurd. This is again putting everything on the shoulder of software engineers.
It is unhelpful, as you correctly say it. I don't denied that. But you should not deny that finding product that have any value for business agenda, is a role a market researcher should do, or someone else more competent in that area.
The fact the reality is how you say it is, it is sad story. But that doesn't make any less unfair. I did a B.Sc in Computer Science and nobody thought me anything about business, product, market research, pricing techniques. I don't how to do it properly nor I can guarantee that the product I'm building for you have any value in whichever market you are going to sell it. And I'm not comfortable taking that kind of responsibility. It is unfair and dishonest for both the buisiness and me.
In my opinion, we're kind of just going in circles. Yes, we as engineers don't have a full understanding the "overall" and "high-level" value of the work we do. 100% true. But, our value is at a smaller level. Is the feature we created going to meet the project's (and the company's) goals or not? (as we understand them)
Requirements gathering has always been apart of software engineering, and actually, we're usually a necessary part of creating that spec. As we all know, a business person has a vague idea of what they want and they work with a technical person to see if this possible or even a good idea). We try to create the right solution given our understanding of the goals of the project and feature. The value again is smaller.
...Although, I do see your point, it can be easy as the technical expert to start giving opinions on things that aren't your responsibility (like marketing strategy). Maybe you've gotten hit by this before? (this is always touchy subject, but I've definitely been scapegoated for problems in the past, never fun). But still, typically, tend to find that the business person is ultimately in charge of the business decisions and I'm responsible for the technical ones.
.. oh, and just to add one more thing, seems like the higher you go, the more of a business person you become anyways. Because for most decisions, the technical and business aspects go hand in hand - should we implement a new payment system in Europe? If we do, how long do we think it will take? Or is it even feasible? If we it is, will it work in all European countries? Will it be easy to maintain?
The business person often has little idea on any technical estimates, but these are crucial to making an informed decision. We work together with them to come up with our best belief on whether the idea is worthwhile.
And agreed, it is a lot of responsibility, but again, it's only when an engineer rises in their company.
Nice example, thank you. Worst when the hairdresser change the style throughout the process because they think something else is better for my head. Maybe at the end I go home sad and frustrated, because (a) I didn't get the style I asked for (b) the one I got does'n fit my face and worsen my value and (c) I had to pay too.
> 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.
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.
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?