Most of the time, we’re docile and content and easy to please. We write software for big enterprises and tiny startups alike, create our own startups once in a while, and only occasionally pen a blog post on the perceived slights against our profession.
The complaint is a common one, though instead of being offended at the thought of doing the grunt labor as a startup’s technical cofounder, Techcrunch is saying that even at big companies, engineers aren’t given the respect that is apparently reserved for executives and managers and MBAs. The central premise is that given software is pretty hard to build, having the ability to create and manage complex pieces of code is a signal of general competence and should be applicable in other areas – like making business decisions. After all, what is respect but a recognition of talent and ability and proven history? Game should respect game1, no?
I do agree with the general sentiment that as a software engineer, you’d want to work for companies whose main product is software. Even if there are plenty of opportunities to write world-eating software in almost every field of business, common sense should indicate that firms tend to reserve respect for the folks who supply its core competencies, the people directly responsible for its products. For the vast majority of our industries, software and software development is seen as a cost center to optimize, not a source of revenue to grow.
But as to the notion that a highly analytical and technical background translates to good product and business decision-making, I’m not seeing evidence to make the case. Yes, in our current climate, engineers have an easier time implementing their own ideas as a startup, raise a round or two of funding, and look for an acquisition exit if the product doesn’t work out. If success is defined as a non-zero exit, then the value placed on engineers from big acquiring companies do give these startups a leg up, but that simply obfuscates whether the underlying product and business around it was actually working.
In fact, this is playing out in a very public way with indie developers in the App Store: some developers have noted, with hard numbers and painful detail, how difficult it is to build a business off of the crowded store that has seen 75 billion downloads. Working hard to produce well-engineered and well-designed apps by itself is empathically not a guarantee of success, and the ingredients to build, maintain, and grow a business (as opposed to, say, a codebase or a software offering) is different enough from development that even the best engineers struggle to stay independent.
There was a recent rant that tried to highlight how companies – as evident by its interview processes – perceive the difference between lowly software engineer types and mighty manager types. As ridiculous as the author makes the latter, it is not a given that engineers can take on the additional roles and responsibilities that come from the “other half”; bad engineering managers and executives abound, likely promoted for the wrong reasons, and can’t figure out the supposedly easier but vastly more respectable job. In fact, most good engineers are cognizant of this shift and explicitly avoid the management ladder completely.
Of course, to some degree, software engineers do this to themselves. At top technology companies where developers run the show, engineers end up relegating everybody else to a lower status (e.g., support, QA, product managers, sometimes people managers too) and then rank themselves on some combination of hacking prowess and computer science trivia, justified as a measurement of intelligence and “understanding of the fundamentals.” Those tough, drawn-out, degrading technical interview gauntlets? It’s not the non-technical folks who are asking for lengthy interview panels; it’s the engineering organization that sets the bar and devotes its engineers’ time to finding qualified peers, often with the assumption that harder is better. After all, it was Google’s recruiting team that reduced the number of interviews for a technical candidate down from ten to around four.
I suppose as an engineering manager, it’s not surprising that my initial take on the problem is for developers to earn (more) respect through increased collaboration and better communication, even if there’s no desire to go into management directly. Unfurling the political playbook is not only more cynical, but would probably be massively unsuccessful: if the grievance against management is that they use politics to elevate status, playing their game on their terms seems like a recipe for failure. Some of the best executives I’ve worked for have gone out of their way recognize individuals, those who made themselves known not by clamoring for status, but by actually doing important2 work.