> This let's you focus on the craft of delivery
I don't give a rat's ass about the craft of delivery! What a reductionist thing to think of engineers as "delivery machines". Me and my team mates are not a factory that simply takes input from a task master and produces code to their bidding.
I care only about one thing: solving the problem! That encompasses learning, understanding and, finally: delivery. To do that, I need to speak to stakeholders MYSELF, I need to see how they are using the product MYSELF, and any regulation I am gonna implement, I need to understand in depth. I don't need somebody to summarize findings for me, I can make my own damn conclusions.
Sure, I will ask the domain experts of their opinion, but me and my teams will decide what to build, when, and how, and do we will do it together, based on all our shared learnings, not based on what a PM told us.
Who prioritises the problems?
If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
---
> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
Ah, I see. There is a concept known as a separation of concerns that prevents this on most teams.
There is a good saying for complex service delivery that most developers operate with in application development and support. If you want to go fast, go alone. If you want to go far, go together. That "together" brings more skillsets that most small engineering teams have on staff, and is typically not beneficial for them to focus on gaining.
In times of plenty, this works, and I think it can have high velocity. Especially with very small teams that all have high levels of direct investment in the result.
There are also times of famine, however, and the work that keeps the lights on is often not work that even invested software developers want to prioritize. When making money is on the line, there's always somebody who's there to make you eat your vegetables. Who, in your conception of the problem, is that?
What kind of work is that? And why are the developers willingly not wanting to prioritize it, if the alternative of not doing it is becoming jobless? Do we need some kind of PM figure to say things like: "If we don't make this feature for the client, we are doomed, so start coding. Chop chop!". And do we need to keep that guy on the payroll for simply relaying a message?
Yes, and yes! I believe you're starting to see. Good management has value. Even if that is to deflect invalid criticism for devs.
"But if you don't do these things, the company fails!" Yeah, and look at all those small, engineering-heavy companies that do exactly that! And further--eventually, as you scale you reinvent division of labor because as much as we like to kid ourselves, software developers are not, universally, better at doing everyone else's job. (If you find yourself in a position where you are better at doing everyone else's job, you should probably find a new company to work at.)
> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
There's two types of problems that developers solve. Problems that they, themselves created (oh no, I wrote a bug), and problems that are given to them.
The second type (traditionally, the "business problems") are being prioritized and solved by the people who care about them. Namely, the CEO and the exco. Those guys set overall strategy, culture etc. and then the delegate the implementation and some of the detail to people with more expertise.
Developers do not run the business. They are delegated to to solve specific problems in the context of running the business. Not all of the business' problems will be solved by developers, but all of the business' problems should be solved in a coherent and harmonious way that accounts for the context of all the other problems in the domain (market, regulatory, finance & tax etc.)
For a specific product, the place where this context is managed is usually by someone wearing a hat with "Product Manager" written on it.
Middle men only improve transfer of knowledge between people under very specific circumstance. Usually they just make things worse
Let children play Chinese whispers, I don't need that in my life
- financial
- medical
- data protection
and you might need different experts' opinion for that. Do you suggest that they are all product managers?