I'm a software attorney - I negotiate software development, installation, support and licensing, deals, including agile software development, SaaS, PaaS, API agreements, SLAs - you name it. I was also in house counsel for a group of tech startups for five years prior to my current role. Finally, I write software, actively - these days in Node - yes, I know this is an invitation to mockery, which I welcome. All of this is a long-winded introduction to try to say I know a thing or two about this.
tl;dr:
1. The most important thing for developers to understand is the business goal of the software they are delivering.
2. The second most important thing for software developers to understand is how much they cost and their opportunity cost - especially if they are on staff.
To explain in more detail:
1. Software you develop professionally serves a business goal. Engineering decisions should be made in support of this goal - they are, themselves, not the primary motivating force. There are often cases where an engineering decision is a key part of the business offering - e.g., a specification, compliance with a protocol or a law or regulation, performance metric, systems compatibility - but this is still a business point. You are still building software for it to be sold. Part of understanding the business goal of the software is how the client (whether that is your employer or your actual client, if you are an independent developer or studio) actually makes money off of that software or how it fits into their business model. This means that, by and large, while executives are actually very sympathetic to engineering decision - you have to understand that a very large number of engineering decisions (possibly a majority?) are non-responsive to business concerns - i.e., they truly do not care if you go with react as opposed to angular for engineering reasons - but they do care if you tell them that there are more developers out there familiar with angular, they are easier to find and hire, the codebase is more actively maintained, it is less prone to failure, it is more likely to continue to be stable in five years, and it will not cost as much to re-factor the old parts of your production-software to this new platform as opposed to an old platform (NB: this example is made up. I have no idea if it is or is not true, with regard to react v angular). They don't care if one is shinier or newer - unless it has a material impact on the ability of software developers to perform and deliver, or it will have a material impact on the stability, security or performance of the underlying software.
2. Software developers are monstrously expensive. Mind-bogglingly so. And non-technical people have a very, very hard time understanding what you do all day. The many, many attempts to metricize software development - velocity, kanban boards, (god forbid) LoC measurements - are an attempt for non-technical people to try and match cost to output. Please understand that this is well meaning - they do respect what you do, they just do not fully understand it, which is why they have to build these elaborate systems to try and make sense of it. To express this another way - you cost money with every breath you draw, and you are fantastically expensive to keep around. A few months ago I was at a JS meetup here in NYC, where a CTO walked through how much work it took to install bower, grunt and babel into their production stack. He said it took 3-4 senior engineers three months of dedicated time to make this transition. I thought to myself, he must have made a great business case, the business managers must have understood this was necessary for the health of the product, his managers must defer to him without question, or the organization has very loose controls, or some combination of the foregoing, because that is somewhere on the order of 3.5 (persons) * 150 hours (productivity / month) * $125/hr (cost of a senior dev, fully loaded) * 3 months = ~$200,000 worth of work for changes to the stack that were purely internal. The math is crude and very back of the envelope - but consider the opportunity cost - that was senior dev time not being put into feature development, critical bug fixes, or performance optimization - it was purely back-end refactoring. Personally, I have no idea if this investment will turn out to have been worth it - I don't know enough about what it was like to write code in that org before and after these changes - I do know a tiny fraction of JS devs work in es6 - so I am skeptical of the utility of babel at this point, but that may be very shortsighted. What I can say with some certainty, however, having negotiated many, many millions of dollars worth of software development agreements, that this was a major operation, even for an 'internal' client. To put it another way, if you hired outside guns to do this same thing, double the cost. The whole point of this story is realize that, when this was all pitched to the management, who are decidedly not software developers, they had to put tremendous faith in their engineering team that this really large cost was worth it, when I'm sure there was a yard-long list of bugs, features and optimizations that were being de-priotized for this fix that the managers would never actually see, touch or interact with directly. When you are pitching engineering decisions to your clients, you have to make it very expressly clear why it matters for the business case - not just why it matters for the engineering case. You may be right and they may even understand and agree - but in the end, unless the engineering changes are going to have a business impact, it is not a good business decision to invest in them. Please understand - sustainability, security, performance and the happiness of the software development staff are important business considerations - so you can include them in your pitch. But if you just tell a manager that react fiber is better and the way of the future, and you must do a full-stack migration from your static HTML forms to react fiber and it will take 1000 hours of dev time, don't be surprised if you get the stinkeye. Tell them this is an investment in the sustainability of the product and it will mean it will work on more systems, more browsers, work better on mobile and make it easier to hire engineers? You may succeed in your pitch.
tl;dr: 1. The most important thing for developers to understand is the business goal of the software they are delivering. 2. The second most important thing for software developers to understand is how much they cost and their opportunity cost - especially if they are on staff.
To explain in more detail:
1. Software you develop professionally serves a business goal. Engineering decisions should be made in support of this goal - they are, themselves, not the primary motivating force. There are often cases where an engineering decision is a key part of the business offering - e.g., a specification, compliance with a protocol or a law or regulation, performance metric, systems compatibility - but this is still a business point. You are still building software for it to be sold. Part of understanding the business goal of the software is how the client (whether that is your employer or your actual client, if you are an independent developer or studio) actually makes money off of that software or how it fits into their business model. This means that, by and large, while executives are actually very sympathetic to engineering decision - you have to understand that a very large number of engineering decisions (possibly a majority?) are non-responsive to business concerns - i.e., they truly do not care if you go with react as opposed to angular for engineering reasons - but they do care if you tell them that there are more developers out there familiar with angular, they are easier to find and hire, the codebase is more actively maintained, it is less prone to failure, it is more likely to continue to be stable in five years, and it will not cost as much to re-factor the old parts of your production-software to this new platform as opposed to an old platform (NB: this example is made up. I have no idea if it is or is not true, with regard to react v angular). They don't care if one is shinier or newer - unless it has a material impact on the ability of software developers to perform and deliver, or it will have a material impact on the stability, security or performance of the underlying software.
2. Software developers are monstrously expensive. Mind-bogglingly so. And non-technical people have a very, very hard time understanding what you do all day. The many, many attempts to metricize software development - velocity, kanban boards, (god forbid) LoC measurements - are an attempt for non-technical people to try and match cost to output. Please understand that this is well meaning - they do respect what you do, they just do not fully understand it, which is why they have to build these elaborate systems to try and make sense of it. To express this another way - you cost money with every breath you draw, and you are fantastically expensive to keep around. A few months ago I was at a JS meetup here in NYC, where a CTO walked through how much work it took to install bower, grunt and babel into their production stack. He said it took 3-4 senior engineers three months of dedicated time to make this transition. I thought to myself, he must have made a great business case, the business managers must have understood this was necessary for the health of the product, his managers must defer to him without question, or the organization has very loose controls, or some combination of the foregoing, because that is somewhere on the order of 3.5 (persons) * 150 hours (productivity / month) * $125/hr (cost of a senior dev, fully loaded) * 3 months = ~$200,000 worth of work for changes to the stack that were purely internal. The math is crude and very back of the envelope - but consider the opportunity cost - that was senior dev time not being put into feature development, critical bug fixes, or performance optimization - it was purely back-end refactoring. Personally, I have no idea if this investment will turn out to have been worth it - I don't know enough about what it was like to write code in that org before and after these changes - I do know a tiny fraction of JS devs work in es6 - so I am skeptical of the utility of babel at this point, but that may be very shortsighted. What I can say with some certainty, however, having negotiated many, many millions of dollars worth of software development agreements, that this was a major operation, even for an 'internal' client. To put it another way, if you hired outside guns to do this same thing, double the cost. The whole point of this story is realize that, when this was all pitched to the management, who are decidedly not software developers, they had to put tremendous faith in their engineering team that this really large cost was worth it, when I'm sure there was a yard-long list of bugs, features and optimizations that were being de-priotized for this fix that the managers would never actually see, touch or interact with directly. When you are pitching engineering decisions to your clients, you have to make it very expressly clear why it matters for the business case - not just why it matters for the engineering case. You may be right and they may even understand and agree - but in the end, unless the engineering changes are going to have a business impact, it is not a good business decision to invest in them. Please understand - sustainability, security, performance and the happiness of the software development staff are important business considerations - so you can include them in your pitch. But if you just tell a manager that react fiber is better and the way of the future, and you must do a full-stack migration from your static HTML forms to react fiber and it will take 1000 hours of dev time, don't be surprised if you get the stinkeye. Tell them this is an investment in the sustainability of the product and it will mean it will work on more systems, more browsers, work better on mobile and make it easier to hire engineers? You may succeed in your pitch.