There’s a claim that’s often made about software engineers, which is that we “don’t want anything to do with the business”. To hear the typical story told, we just want to put our heads down and work on engineering problems, and have little respect for the business problems that are of direct importance to the companies where we work. There’s a certain mythology that has grown up around that little concept.
Taking a superficial view, this perception is accurate. The most talented software engineers seem to have minimal interest in the commercial viability of their work, and a rather low level of respect for the flavor-of-the-month power-holders who direct and supervise their work. It’s easy to conclude that software engineers want to live in an ivory tower far away from business concerns. It’s also, in my experience, completely incorrect. Business can be intellectually fascinating. As I’ve learned with age, new product development, microeconomics and game theory, and interpersonal interactions are just as rich in cognitive nutrition as compiler design or random matrix theory. I might prefer to study hard technical topics in my free time, in order to keep up a specialty, but I’m a generalist at heart and I don’t view business problems or interpersonal challenges as inferior or “dirty”. More to this, I think that most software engineers agree with me on that. We’re not ivory tower theoreticians. We’re builders, and as we age, we begin to respect the challenges involved in large projects that present interpersonal as well as technical challenges.
So why are so many talented software engineers seemingly averse to the business? Why do most talented programmers fly away from line-of-business work, leaving it to the less capable and credible? It’s this: we don’t want to deal with the business as subordinates. That, stated so, is the truth of it.
There are a few who protect their specialties with such intensity that any business-related work is viewed as an unwanted distraction, and I’m glad that they exist, because the hardest technical problems require a single-minded focus. I’m not speaking (not here and now, anyway) for them. Instead, I’m talking about a more typical technologist, with an attraction to problem-solving in general. Is she willing to work for “the business”? Of course, but not as a subordinate. If she’s going to be called in to mix business concerns with her work, she’s going to want the authority and autonomy necessary to actually solve the problems put in front of her. It’s when working with the business doesn’t come with these requisite resources and permissions that she’d rather slink away and build interpreters for esoteric languages.
The stereotype is that software engineers and technologists “don’t care” about business problems. The reality is that they avoid working on line-of-business software because the position is inherently subordinate. Give them the authority to set requirements, instead of coding to them, and they’ll care. Make them partners and drivers instead of “resources”, and they’ll actually give a damn. But expect them to interact with the business in a purely subordinate role, as in a typical business-driven “tech” company, and the talented ones (who are invariably smarter than the executives shouting orders, but have chosen not to participate in the political contest necessary to get to that level) will hide from the front lines.
If a company views software engineering as a cost center, and programming as a fundamentally subordinate activity, it will find that talented programmers avoid direct interaction with the business (which will, by design, happen on subordinate terms) and software it builds will either be of low quality or irrelevant to its business needs– because those who have the ability to write high-quality software won’t even bother to make their work relevant. However, this pattern of degeneracy (although common) should not be taken as a foregone conclusion. There are more similarities than differences between business problems and engineering problems, and it’s quite possible to give people with programming and engineering talent the incentive to learn about the business. While technical talent flies away from “business-driven programming” like a bat out of hell, there’s no intrinsic animosity between programming talent and “the business”. To the contrary, I think that people with experience solving these two classes of problems could have a natural affinity, and have a lot to learn from each other. Any such meeting has to come on terms of equality, however. If working with the business means doing so as a subordinate, then no one with technical talent will do so in earnest.
