The Captain/Engineer analogy later on also has a similar problem. In my experience, engineering is always a major stakeholder in a (healthy) product roadmap. They often have good ideas for how to shape the product, they define what is feasible/costly, and have to build it in the end. On a ship, I don't imagine that engineering would be very involved in helping to set the direction, but I could be wrong.
> On a ship, I don't imagine that engineering would be very involved in helping to set the direction
On a warship at least, engineering would make inputs into command decisions, at least by identifying constraints such as when maintenance is required, redline limits, etc.
In fact the Kirk / Scotty relationship (as per classic Star Trek) is a fairly good model, except that there would be multiple Scotties, representing other functions such as damage control, weapons teams, etc. These different teams would have to mutually deconflict, e.g. scheduling maintenance / repair around critical warfighting activities.
Good point in the difference between a software engineering (SE) team and engineers within a ship.
I've worked as a software engineer myself and indeed SE's usually have a clear view on helping shape the product. Though, depending on how big the org is, engineers may not have much of an influence on the vision (why a product gets made for the user).
So yes it depends. I could certainly highlight where the analogy doesn't work (though at the moment of writing it felt I'd take away from the main point).
