There are three levels of engineering teams' engagement. Interestingly, each sees themselves as high-performing contributors who work hard each day, using their professional skills to the fullest.
1st level of engagement - focus on input.
Engineers are smart people, and they know how to solve problems. But they expect organizations / PMs to tell them what to do. They don't care about goals, deadlines, or outcomes. They assess their value by the potential they have.
Too often, I saw these people nodding to unrealistic deadlines. Job is done when they say it's done. One quarter later than estimated? The PM failed to predict dependencies, the CEO pushed too hard, or the scope changed too often.
There is zero trust between engineering and the rest of the organization. The original deadline is used as a checkpoint to see what else needs to be done. The product team has its own timeline, adding weeks or months to the original deadline. Engineering doesn't care about deadlines too - "no one is listening to us", they used to say.
2nd level of engagement - focus on goals.
There are roadmaps and features that have to be delivered. Team performance is assessed by meeting their goals. There is some collaboration between product and engineering. Deadlines are being met, and potential blockers are being communicated proactively. Bigger scope means a farther deadline.
For many companies, this is the desired state. The bad thing is that when the features are done (e.g., pushed to production), the engineering job is done. They celebrated the launch, and now it's the org's job to take care of the feature. Adoption fails? It's PMs problem, marketing failed, or whatever.
3rd level of engagement - focus on the outcome.
The true desired state is when the product launch is just the beginning. The team is accountable for the outcome, not just coding being done. Here engineers will be the first ones to look at product insights. Adoption fails? Empowered teams take it as a challenge and celebrate when it's being sorted out.