[tomrod]

No, but it's something a good product manager does for you, and with the economy of comparative and potentially absolute advantages. This let's you focus on the craft of delivery without encumberance of spending research into compliance.

[ath3nd]

I don't consider the engineering having a deep understanding of the domain and compliance to be a "encumberance". The more engineers get into the domain themselves, the more they can make deep decisions about how to build the most effective solutions.

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

[growse]

> I care only about one thing: solving the problem!

Who prioritises the problems?

[ath3nd]

The developer teams, of course. They are solving the problems, so why should they not prioritize them? They just need to have other parts of the org heard, but if you are solving it, you get to choose how to do it, in what order and with what priority.

If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

[tomrod]

What area of insights does the development team need to be able to prioritize for better utilization of their product?

---

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

[growse]

> They are solving the problems, so why should they not prioritize them?

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

[eropple]

> if you are solving it, you get to choose how to do it, in what order and with what priority

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?

[ath3nd]

> and the work that keeps the lights on is often not work that even invested software developers want to prioritize.

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?

[tomrod]

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

Yes, and yes! I believe you're starting to see. Good management has value. Even if that is to deflect invalid criticism for devs.

[TrololoTroll]

Until you inevitably have a question and they need to get in touch with the expert again

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

[marcosdumay]

If the PM does that, the developer has no idea what part of the requirements is important, and won't be able to deal with it when the requirements unavoidably break each other or reality. The developer has to be there too.