8 Lessons 14 Years of Software Delivery Taught Me
I’ve spent 14 years managing software delivery — web, mobile, AI, SaaS, enterprise, you name it. Distributed teams, vendors in different time zones, stakeholders who want a one-line answer to a problem that took three weeks to create.
Somewhere along the way, I picked up a few lessons. Not the kind you find in a PMP textbook — the kind you only learn after something quietly goes wrong and you spend a weekend figuring out why.
Here are eight of them.
1. “On track” is not a status update
For years I accepted “on track” as a real answer. It isn’t. It’s a placeholder for either “I haven’t checked” or “I don’t want to tell you something uncomfortable yet.”
A real update tells me what’s blocking the work, what decision you need from me, or what’s quietly worrying you. Everything else is just noise dressed up as information. Once I started asking “what’s blocking you” instead of “are we on track,” the quality of every standup I ran changed almost overnight.
2. Most “scope creep” is really skipped discovery
Early in my career, I blamed clients for scope creep more than I want to admit. Looking back, most of it wasn’t scope creep at all — it was discovery we rushed through because everyone was eager to start building.
You don’t avoid that cost. You just defer it. And it always comes back with interest — usually in week six of a sprint, in the form of a “small” requirement nobody surfaced in week one.
3. A red status on Monday is fine. A red status the Friday before launch is a trust problem.
Nobody likes reporting bad news early. But a risk flagged on day one is just information. A risk that surfaces the week before launch — after weeks of “green” — isn’t a delivery problem. It’s a communication failure, and usually a fear-based one. Somebody knew, and decided silence was safer than the conversation.
Get Kailash Malav’s stories in your inbox
Join Medium for free to get updates from this writer.
The earlier I get the uncomfortable version of the truth, the more options I have to actually fix it.
4. AI didn’t make me less useful — it gave me my time back
About a year ago, I started using AI tools to draft sprint summaries, risk logs, and stakeholder reports. I’ll be honest — part of me wondered if automating that work made me less necessary.
It was the opposite. I got an hour or two back almost every week — time I used to spend formatting updates that half the recipients skimmed anyway. Now that time goes into actual conversations: unblocking someone, pressure-testing a timeline, sitting with a stakeholder who’s nervous about a release. That’s the part of the job AI can’t do, and it turns out that’s most of the job that matters.
5. If your team needs a meeting to explain the board, the board is broken
I’ve inherited JIRA setups so over-engineered that new team members needed a 30-minute walkthrough just to log a bug. A workflow that requires explanation has already failed at its one job — making work visible. The best boards I’ve built are the ones nobody ever asks me about.
6. “Not my problem” is the most expensive sentence in delivery
I’ve watched good PMs lose a team’s trust in a single sentence — usually some version of “that’s not really my responsibility.” Maybe it’s technically true. It doesn’t matter. The moment a team believes you’ll pass on a blocker instead of helping solve it, they stop bringing you blockers early. And a PM who hears about problems late is, functionally, not doing the job.
7. Rollback plans are project management, not just DevOps
I used to think of CI/CD pipelines, quality gates, and rollback plans as engineering’s domain — something to nod along to in a planning meeting. Then I sat through an incident call where there was no rollback plan, and I was the one explaining to a client why a “routine release” had taken down a production environment for four hours.
I don’t write the pipeline code. But I own whether a rollback plan exists before a release goes out. That’s not optional anymore.
8. You don’t need to write code to be technical — but you do need to follow the conversation
I have a hands-on technical background, and I’m grateful for it, but that’s not really the point. The point is that if an engineer tells you why something will take longer than expected, and you can’t follow the reasoning, you can’t defend their timeline to a stakeholder who’s pushing back. Technical fluency isn’t about writing code as a PM. It’s about not needing someone to translate the bad news for you.
