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.

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".

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.

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.

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.

Granted, there might be a better way to solve it than devise some technology to do so that I never thought of.

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 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.

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.

ALL of those products/projects you list did required managment and business skills to be 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.

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 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.

This sort of attitude is one reason why PMs and BAs get paid more than developers.

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.

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.

To commiserate is to share in someone's kvetching.

This right here should have been the top rated comment on StackExchange. And, everything else the parent said is dead on.

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!"