15 years in software delivery. Some lessons I had to learn the hard way (and a few I'm still relearning). "On track" means nothing to me anymore. Tell me what's blocking you, what decision you need from me, or what's worrying you — that's an update. Everything else is just a word. Half the scope creep I've dealt with wasn't scope creep at all. It was discovery we skipped because everyone was in a hurry to start building. You pay for that later, with interest. A red status reported on Monday is fine. A green status that turns red the Friday before launch means somebody knew and didn't say anything. That's the actual problem, not the delay. I started using AI to draft my sprint summaries and risk logs about a year ago. Honestly thought it would make me feel less useful. Opposite happened — I spend that hour on actual conversations with the team now instead of formatting a report nobody reads closely anyway. If your team needs a meeting just to understand the JIRA board, the board is the problem, not the team. "Not my problem" is the fastest way I've seen a PM lose a team's trust. Once that happens, good luck getting honest updates from anyone again. Rollback plans aren't a DevOps checkbox. They're the difference between "we hit an issue, fixed it in 10 minutes" and a very long, very bad call with the client. You don't need to write code to be technical. But if you can't follow what an engineer is telling you, you can't actually defend their timeline to anyone — and that's most of the job. Still figuring some of these out, honestly. Curious what's on your list — what's a lesson that took you way longer to actually learn than it should have? #ProjectManagement #LessonsLearned #SoftwareDelivery