> Trust your engineers to do the right thing on their own and they might just surprise you.
Yes, they might surprise you. That's potentially quite terrible because there's a whole ton of other people & roles involved in the success of a product... and of course that's assuming that the project is what the customer wants, requires no marketing message for the customer to understand, and sells itself.
I mean - trust but verify. While I largely agree with you it's always demotivating for the team to realize one dev is doing no actual work and getting away with it. Obviously not good for the business either.
For the way we do it, when a stakeholder wants our team to do something, they come to us with user stories and acceptance criteria that matter to them. Then we hash out the rest of it. I don’t really see a useful way we could be trusted more. The Marketing department knows best what feature it is they want on the website, and why. So they specify that part. We estimate complexity and the business weighs the priority of that feature against other stuff in our backlog and it falls into an appropriate sprint based on that and other motivating factors. Then we do the work.
I don’t see a lack of trust? So I’m curious where you see it and feel it should be done better?
But outside of a very small company to me it’s a bigger crime to waste engineer time with all the meetings necessary to give them that full perspective. When I started at my current company I was the only developer and I worked directly with the CEO and our single marketing person. Back then I helped decide priority. Now the company is too big for that. I don’t have time for all the manager and marketing and business planning meetings to be able to decide priority.
As far as defining features, we can propose them like anybody else but I think I already explained why usually it makes sense for them to come from whoever owns that piece of what you’re doing. But this of course again depends on the structure of your company.