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

[eropple]

Right - like, you'd think it's obvious that of course you'd just do the right thing. But developers are expensive and market research, talking to customers, planning for the future, etc. becomes rivalrous to building things. And that stuff is generally much less interesting, so without compulsions to solve those problems, they frequently then don't get solved.

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