This is the direction of my thinking, too.

Earlier discussion focuses on writing software at a slower pace to inject more accuracy and robust thinking/design/code. Conceptually, yes, I get it!

But in numerous practical scenarios, some adherence to a recurring schedule seems like the only way to align software to business outcomes. My thinking is tied more to enterprise products (both external and internal) rather than open-source.

I like an active dialog with engineers. (I'm neither SWE nor PM). Let's talk together about estimates. What's possible and not possible. Where do you feel most uncertain, most certain. What dependencies/externalities do you expect to cause problems.

Those conversations help me (business/analytics-side) do things like adjust my own deadlines, schedules. Communicate with c-suite to realign on what's possible and not. Adjust time.

▲

DrewADesign a day ago | parent [-]

The main problem I’ve had is the unpredictability of where the complexity lies. Unless you’ve done exactly what you’re doing, before, with the same tools and requirements, there’s a good chance that some discrete trivial aspect could take up an incredible amount of time, and that won’t indicate whether the main goal will take more or less time. I’ve worked both as a developer and as a designer, and while some aspects of design can be really nebulous and uncertain compared to dev work, it lacks some of the unpredictability — it’s not like I’m going to unexpectedly have to re-make the logo.

I feel for anyone that has to wrangle these tasks into a business-consumable time frame.

	▲	grvdrm a day ago \| parent [-]
		> The main problem I’ve had is the unpredictability of where the complexity lies. Unless you’ve done exactly what you’re doing, before, with the same tools and requirements, there’s a good chance that some discrete trivial aspect could take up an incredible amount of time, and that won’t indicate whether the main goal will take more or less time What a great articulation. Completely agree. This is why I don't blame PMs anymore than devs anymore than business folks throwing requirements at PMs. Possible to find fault everywhere. I think the broader problem is scale and growth. Many people in many roles are caught in growth-mind or scale-mind companies where the business wants to operate at a velocity that may not align with the realistic development work we're discussing. PMs are similarly caught with less time to understand, scope, plan, etc. Business folks ask questions like "why isn't this ready" to devs that may not understand the reasons why the business operates the way it does, or the business at all. Full disclosure: I'm in insurance. Seeing lots of these problems play out in front of me. C-suite moving at speed 100, devs moving at a perceived speed of 50. Silos and communication problems and unclear requirements up and down the stack. So, in my interactions, the way I try to help is just to understand the most basic components and their ability to come alive or not. Is there anything to show? Yes, ok - let's celebrate a small win. Is there a rather large delay? Why - ok, let's use that to reinforce building something robust vs. crap. But, there are schedules! Someone above mentioned sqlite. Another example comes to mind: Obsidian. I think they're anomalies (good ones) rather than examples that broadly prove the point to slow down.