Comment by rramadass
2 years ago
You have missed the point.
It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand.
This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...).
I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...
Relevant Excerpt:
Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
There is a difference between "understanding the work" and "knowing how to do the work".
I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time.
None of them could code a mobile game to save their life.
What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates.
Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
>There is a difference between "understanding the work" and "knowing how to do the work".
True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system.
>Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
> You have missed the point.
No, I think at least in large part, you missed the point.
> It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever).
As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)
You are talking about the meaningfulness/meaninglessness of the Business/Technology Objective itself. That aspect is certainly relevant and can be Bullshit (eg. companies selling Scrum master/Agile coach certifications :-) but in the context of this thread we are talking about the bullshit jobs created within an organization in the bureaucratic/administrative/managerial/leadership "roles". This is what is more insidious and needs to be rebelled against.
From https://en.wikipedia.org/wiki/Bullshit_Jobs :
... as he describes, five types of entirely pointless jobs: ... 5. Taskmasters, who create extra work for those who do not need it, e.g., middle management, leadership professionals.
In companies, he concludes that the rise of service sector jobs owes less to economic need than to "managerial feudalism", in which employers need underlings in order to feel important and maintain competitive status and power.
From https://en.wikipedia.org/wiki/Bullshit_job :
Graeber also formulated the concept of bullshitization, where previously meaningful work turns into a bullshit job through corporatization, marketization or managerialism.