[meander_water]

Great read, but I was expecting something different based on the title.

This sounds like his approach working on personal projects. I'm really curious about large technical team projects though. What's the best approach to getting stuff done and making sure everyone is working towards the same goal etc.

After 15 years I have yet to see a technical project that hasn't run over budget, over time, under delivered or burnt people out.

I'm sure there are people out there with counter examples who know exactly how to deliver projects at a massive scale. Any links/suggested reading would be appreciated!

[makeitdouble]

> over budget, over time, under delivered

TBH these are fine in my book.

"over budget" is only an issue if there's really no more money, and I think it's pretty rare for IT projects. Most of the time it's just someone complaining the estimate was off.

"Over time" is the same, it's an issue if there was a real deadline, but the best practice is not plan unflexible events (e.g. do a huge PR campaign with the date on it) before it's basically done.

"under delivered" is a matter of expectations, the real pointis that it was delivered at all.

> or burnt people out.

This one is not like the others. People shouldn't burn out over bullshit deadlines.

[BrkAway21]

Maybe I’ll get maligned for saying this, but as someone who’s managed and successfully delivered software projects of all sizes, I’ve become somewhat of a convert to the Scaled Agile Framework. I treat it exactly as intended, as a framework. It’s a strawman to adapt based on context, and what I value most is how it led me to explore deeper source material and form my own conclusions.

Over the years, I’ve learned that true success starts with clearly understanding why you’re building something. Without clear goals, it’s impossible to prioritize or even know where to start. That clarity drives better sequencing, and sometimes the wisdom to not build something at all.

The next critical factor is empathy. You have to see through your customer’s eyes and validate that what you’re building actually solves their problem. That doesn’t mean giving them everything they ask for, but rather understanding their pain points well enough to deliver real value.

Ultimately, most projects go over budget or underdeliver because teams spend too much time building the wrong things. If we instead focused on continually steering toward desired, valuable functionality (things people genuinely want or will pay for), more software projects would appear like successes.

[Nevermark]

> If we instead focused on continually steering toward desired, valuable functionality (things people genuinely want or will pay for), more software projects would appear like successes.

Yes! All overbudget, late to complete, successes of course.

I jest a bit. I think the term "deadline" is completely inappropriate for most projects.

I prefer, "target series", for any significant project.

Each word communicates something very important.

The first target should be set via (1) known knowns/unknowns, (2) some wisdom about unknown unknowns, and (3) mindful optimism.

The last should almost always ensure the project misses its first target. Which sounds backwards, until accounting for the considerable creative impact, and absolute time savings, that a time constraint creates. And how much a team can improve its productivity over time, by continually targeting informed optimistic targets.

Improving a teams rate of return has compounding value, for everyone.

But this is a self-imposed, let's see how well we can beat ourselves, time constraint. Never an, OMG I might lose my job / standing / reputation / customer credibility time constraint.

If the first target is missed, or as soon as it is clear it is wildly unachievable, a second target is set the same way, with the new information.

Each target in a series should require less padding. If more padding is added it is a sign to step back and consider what is not being understood.

Over time, a team should develop a pretty good pattern of completion at target 2 or 3, or something like that. In a way that becomes fairly predictable. It doesn't really matter what the number is, just that the team develops a rhythm that actually does provide some predictability based on current knowledge, even if it isn't in absolute time terms.

This is the best path for optimizing both rate of progress, fast recognition of problems with progress, and realistic levels of project arc predictability. In my experience anyway.

[dboon]

well, the project in question is ghostty, which definitely qualifies