Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one.
I suspect programmers are less correct in their assumption than they would like to believe. Probably more correct than the other two groups of employees, but still less than correct. The sad fact is, most programmers (especially non-entrepreneurs) don't "get" what PM's and BA's do, the same way that most managers don't "get" what programmers do, but their role still provides value (if they're good at their job). The nature of their job often involves filtering crap for their programmers, so the better job they're doing, the more invisible they look.
The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters.
Of course, the above is a perfect world, which is about as common as the mythical sufficiently-smart compiler. Which is to say, it never exists and never will. Nonetheless, there are such things as PM's that provide value. My experience is that ones with non-negative value are about one-in-four, ones with measurably positive value are less than one-in-ten, and if you find one you should pay what it takes to keep them around. YMMV.
----
That said, there are reasons why PM's are paid more than their value more often than programmers are. I agree with the majority of these, but I'm restricting my contributions to the portions of my opinions which aren't echoed throughout this thread.
"Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one."
I think I thought that way about 15 years ago or so, but by 10 years ago I realized that ... almost without exception, I can get the tech stuff done. Of course, I'd like to do it myself, but I can get others smarter than me at XYZ to do the tech stuff. While the tech stuff is sometimes hard, it's almost universally doable.
Have you ever had a project fail because you didn't know how to write to a file, take data input or query a database? I bet not. But... we've all had projects that failed because none of the people involved could accurately communicate what needed to be done (and in some cases, establish reasonable timelines for those needs). Communication is key, and PM/BA types are generally better at it than typical developer types. There are always exceptions, but the PM/BA types are perceived to be better at it, often because they're controlling the communication, almost by definition of their role.
So, while everyone thinks their part is the most important, they're pretty much all equally important, but the PM/BAs tend to be more visible on projects, rightly or wrongly.
> Have you ever had a project fail because you didn't know how to write to a file, take data input or query a database? [...] 10 years ago I realized that ... almost without exception, I can get the tech stuff done.
The examples of "tech stuff" you mentioned are very junior programming tasks. The "programming" the article talks about is all the non-PM/BA stuff: the overall technical design of the system, not just the file writing and database queries; the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc.
> I can get the tech stuff done. Of course, I'd like to do it myself, but I can get others smarter than me [...] to do the tech stuff.
Project managers and business analysts usually try to add technical skills to their resume by dabbling in some of the "tech stuff" of the projects they're managing. Usually this is the highest level stuff like architecture design or programming language selection or programmer analysis/selection: generally the stuff with the greatest impact on the success or failure of a project. You write "Of course, I'd like to do it myself" so I guess you're one of them. But those with PM/BA experience are the least able to do this project-critical tech stuff.
Project Managers get to dabble in this work because of their power in an organisation. They also try to keep their jobs by "creating" work and problems, just like middlemen everywhere. They stop technical people gaining too much power by splitting the systems into arbitrary projects. They give programming jobs to their mates in return for loyalty.
Despite their talk about being accountable for their results, in reality they cover their behinds in case they fail. When the tech stuff goes wrong, they leave behind a huge mess for programmers to clean up, usually with extra hours and overnight standbies. The business users get to do unit testing as part of their change acceptance process. The PM's go into recruitment and back into management somewhere else. A recruiter once told me "if I had a job like that on my books, I'd apply for it myself".
"You write "Of course, I'd like to do it myself" so I guess you're one of them."
Umm.... no, not really. I'm a developer who's gradually moved in to more business-oriented consulting over the last several years. I still do a lot of development (> 50%, certainly), but I've realized that for the majority of the projects I work on, the difficulties are not programming or tech skills/knowledge, it's making sure we all know what is to be programmed, and dealing with any changes that come up.
Everyone thinks they're stuff is unique/cutting-edge/hard/impossible/ground-breaking tech marvels. In some cases it is, but I'm finding those instances to be more rare the older I get. Why? My own skills are getting better (slowly), there's far more tools and libraries to tackle much larger problems better, and my own network of people I can tap has grown to include some insanely talented people.
"the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc."
I would posit those are far more in the realm of "communication" issues I brought up. Yes, you need to have a technical background to do them correctly, but you don't do that stuff in a vacuum. You do those things in concert with other people (customer, team, etc).
For example - the basics of build and deployment are known problems. One might even class them as 'junior' problems. How many times have you had builds fail because someone didn't know how to schedule jenkins properly? Or because an alert wasn't set up to notify someone of an issue? The mechanics aren't very hard, but deciding what the specifics of the processes should be is hard, because you have to communicate ideas/deadlines/responsibilities/etc with multiple people or teams. That's what I'm getting at.
I've had projects fail because we couldn't get the core algorithms working ...
Hell, most of my interesting failures so far have been "Okay, so computers can't do X (yet), or I'm too stupid to figure it out and don't know anyone smart enough to solve X"
A lot of my projects would sell like hotcakes, once someone figures out a practical implementation, or at least an impractical one.
I'd thought about that angle, and I've known a couple of those myself over the years (mostly second hand). But even in the cases I've seen, things might have gone much smoother had there been stronger communication about the specifics and what was (and was not) possible much earlier.
As soon as things look to be not possible, tell someone. If you're able to pull a rabbit out of a hat later on, great, but let people know that real hard limits (algorithm, processing speed, etc) are being hit. sometimes what someone was indicating was a hard requirement turns out to be a 'oh, it'd be nice to have that, let's move on' sort of thing.
So, while I get your point, I think overall there's still things people can do wrt communication even when there are fundamentally tech issues at stake.
Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased.
We need not rely upon opinions here, we can be objective instead.
Let's ask how many business analysts without programming skills have made working software. Similarly, let's ask the same of the managers. And finally, let's ask programmers without any managerial or business skills how many pieces of software they've made.
My guess is that the numbers are 0, 0, and a lot. That's because programming is necessary to write software, whereas management and business analysis is only "nice to have". There is lots of great software that was not crafted by managers or analysts; Linux, Emacs, Google search, Facebook, and so on. Most of the stuff designed by product managers is one-off software that will have made no impact other than paying the team's salary for a while.
That's because programming is necessary to write software, whereas management and business analysis is only "nice to have".
That is an interesting philosophy, but it has never been true in real life. Every major corporation in the world has added business analysts and PMs. Even the great technology companies you mention have many, many business analysts.
I love finding exceptions to rules, but I can't find an exception to the rule that if you want to accomplish truly great things with your company, you will eventually add business analysts and PMs.
Small companies will realize that the value of having a marketing professional over a "growth hacker" is when the marketing professional can call a major company and negotiate an ad deal due to their experience doing so. Or when a finance professional can help hammer out terms of a new round of debt financing that allow the company to grow without giving up equity etc.
As a business professional, I understand that hackers have value, but I also understand that even HR people have value. Just because I don't know all the value they have, does not mean it doesn't exist.
This is a cross-industry problem. As engineers, we are trained to find value in concrete products. We see it in software development, as well as in, for example, construction (ask any structural engineer about how architects are perceived)
We tend to forget that, not so long ago, "classical" engineers looked at programmers as lowly-technicians that only used their computers, which were the real valuable product.
But working software does not mean successful software. If it wasn't used, if it didn't helped people or solved a problem, how can it be considered successful?.
ALL of those products/projects you list did required managment and business skills to be successful.
If it wasn't used, if it didn't help people or solve a problem, how can it be considered successful?.
The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success. Similarly, many clients have commissioned many silly projects that they paid for and never used. (I was once tasked with writing a fourm system for an insurance company's customers, where they could discuss their experiences in having that company's insurance. Despite the software being up to their spec, the project was cancelled because it was a terrible idea. I got paid nonetheless, which could be considered a success.)
ALL of those products/projects you list did required managment and business skills to be successful.
Where's your proof? I'd say that projects like Emacs and Linux are successful in spite of their leadership's social skills.
I got paid nonetheless, which could be considered a success.
Then that's the problem, we mean different things when we say "success". For me, and for a lot of people I believe, "successful software" does not equals to just "the team got paid".
Where's your proof? I'd say that projects like Emacs and Linux are successful in spite of their leadership's social skills.
So, are you implying that all the others were?
Business/Management != Social Skills. I'm not familiar with Emacs history as a product (and I'm not sure if it was "successful" under your criteria), but Linux did required incredible management skills, and a lot of business-savy people for spreading it in the comercial world.
The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success.
The question that must be asked here is whether your level of fun should be the best indicator of success. It would seem to me that the entity paying the money should be the one to define the criteria for success, and I think it's quite logical to presume that they would not accept the developer team's level of fun as success criteria for what I hope are self-evident reasons. I believe it would also be self-evident why the entity paying the money should be the one to define the success criteria also. In your case's case, they'd probably say the project was an unfortunate failure and waste of money, but maybe worth the try anyway, so oh well (i.e. we were aware that there were risks, too bad the risks became reality).
For open-source projects, nobody is paying the money usually (as they're usually staffed by volunteers), so of course the developers can define the success criteria in those cases.
I agree. Good/Great programmers do it because they like to. They could go a million years and never make any money with the software they write (assuming they don't need to pay bills) because there is value in the process for them.
To the business, even in a software company where development is tier 1, and not a traditional "cost center" and bundled in with IT, development still needs to produce tangible business results. This requires skills that do not directly overlap with development skills.
Programmer: I can build it, I should get paid more
VS
BA/PM: I can tell you what to build so we can attract paying customers and both get paid.
Software is needed. But so are customers. Getting customers is a more valued skill because its the blood of the business. Programming is necessary, but I'd say 95% of the problems needing to be solved are not technology problems.
> Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one.
This is all true. However, you forgot this additional piece:
Managers and business analysts generally sit higher in the organizational chart than programmers, and thus have an advantage when negotiating salaries, presenting the programmer's relative value to the rest of the organization, etc.
> The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters.
However, many would argue that translating abstract business requirements into technical requirements is a technical matter.
That said, the notion that programmers always make less is not universally true, and many organizations are more sane about paying commiserate with value generated.
FWIW, I think the question should have been "Why do bad PMs/BAs frequently get paid more than good programmers?"
As far as I can tell, that question has traditionally been our motivation for inventing "a narrative of moral superiority". When you're faced with an ugly truth such as "it sucks that the world is not fair", you need something to make you feel better about it. That "something" is usually along the lines of "Yeah, but I am a better person!"
In today's economically rationalised world, almost every position in a company is important. If it wasn't, they wouldn't pay for it. Saying who is more important to the process is somewhat meaningless - wages are generally aligned to how difficult it is to replace a person's skillset.
The core activity of a band is making music. The bottom line can be helped a lot by marketing. Other roles may be very important to allow the musicians to focus. Sometimes musicians need to be kept sober or made to practice more, with which others can help. So other people can make value in a band and deserve to get paid. But take away the musicians, and you have absolutely nothing. Plenty of people have made good music without lots of managers over them. In that specific sense, musicians are the most important part of a band.
I think that's a flawed analogy, because the band is set up to sell the specific art of the musicians. Software companies are set up to provide a product using the craft of the programmers. It's a lot easier to keep the same flavour in your product if you have to replace a lead programmer instead of a lead singer. Programmers in companies don't do the equivalent of "I'm going to change tack and do a blues album this time".
I suspect programmers are less correct in their assumption than they would like to believe. Probably more correct than the other two groups of employees, but still less than correct. The sad fact is, most programmers (especially non-entrepreneurs) don't "get" what PM's and BA's do, the same way that most managers don't "get" what programmers do, but their role still provides value (if they're good at their job). The nature of their job often involves filtering crap for their programmers, so the better job they're doing, the more invisible they look.
The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters.
Of course, the above is a perfect world, which is about as common as the mythical sufficiently-smart compiler. Which is to say, it never exists and never will. Nonetheless, there are such things as PM's that provide value. My experience is that ones with non-negative value are about one-in-four, ones with measurably positive value are less than one-in-ten, and if you find one you should pay what it takes to keep them around. YMMV.
----
That said, there are reasons why PM's are paid more than their value more often than programmers are. I agree with the majority of these, but I'm restricting my contributions to the portions of my opinions which aren't echoed throughout this thread.