How Can Engineering Push Back on Unrealistic Timelines Without Being Seen as Blockers?

“It’ll take longer than that.” If you work in engineering, you’ve said it, and you’ve probably watched the room decide you’re the problem.

That’s the question Stephanie sent in for this episode of Runtime Regret: how can engineering teams push back on unrealistic timelines without sounding defensive or uncooperative? Joe Kennedy, who has spent decades running technology and operations teams, says the answer comes down to one word: transparency.

Why stakeholders think engineering is slow

When the business brings you a list of requirements and a deadline, they usually don’t understand why it takes so long because they can’t see the complexity behind it. To them, it’s “build the feature.” To you, it’s standing up a development environment, getting the right data, validating that data, securing approvals, moving through development and user acceptance testing (UAT), running quality checks and code scans in your CI/CD pipeline, and promoting the release through pre-production into production.

Most of that work is invisible. And invisible work looks like stalling.

Draw the picture: turn your delivery process into a timeline

Joe’s first move is simple. When someone hands you requirements, say “That’s fine,” and then come back with the date it will actually take, along with a schedule that shows why.

* Map every step: data, environments, approvals, development, UAT, pipeline checks, pre-prod and production.

* Put it on a timeline so stakeholders can see that the coding is only one part of the effort.

* Walk them through each callout so the date stops feeling arbitrary.

Once people see all the steps laid out, they understand it’s not just the development effort that takes time. It’s everything around it.

Show the real cost of a change request

The second lesson: when stakeholders change the requirements, use the same picture to show what that change triggers. The change itself might be four hours of work. Orchestrating it might take two or three days, because it has to be re-developed, retested, re-approved and possibly pushed into the next release cycle.

When you make that latency visible, people ask fewer questions and stop treating engineering as the blocker.

You don’t need to be a diagramming expert

Joe recommends PlantUML for building these timeline diagrams, but you don’t even need to learn it. Ask an AI tool like ChatGPT to turn your list of delivery steps into a PlantUML timeline diagram, drop the result into your presentation, and use it to tell the story of what it really takes to ship.

Do that consistently, and you’ll have a much easier time explaining deadlines, managing expectations and building trust with your business counterparts.

Watch the full episode above. Got a question about engineering leadership, delivery or working with the business? Leave it in the comments or send it in the chat, and Joe may answer it on a future episode of Runtime Regret.