Great engineering teams focus on milestones instead of projects

&gt; Estimating one to three weeks of work is easy<p>So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force you to make the wrong compromises. They are typically filled with many disparate tasks that often require you to context switch back and forth repeatedly. If you under estimate the time some tasks take, the numbers paint you as a weak performer. Those who game the system by over estimating every task are viewed as super achievers, even if their actual value contribution is far lower. I think if you take away the metrics aspect of sprints, it actually becomes more useful.

My high-functioning teams rarely had an extensive backlog, but many loose notes of what a long-term strategy could look like.<p>We had 1 mission at a time that we were gunning down— the outcomes of which were motivating, in&#x2F;validating and gave us closure on an swath of planning and theory.<p>I see some similarity between these properties and the author’s idea of a milestone.

I&#x27;m not disagreeing with the article, I&#x27;m just wondering what painful &#x27;project&#x27; oritentated piece of work the writer has had to endure when it crashed into their life.<p>To my mind there are products and milestones as maybe a point releases within a product - Agile&#x2F;Scrum. I&#x27;ve suffered many systems over the years, but this is the one that makes the most sense - and maybe most importantly demarcates responsibilities.<p>Projects are something external to this procress, product management (i.e. me) need to deal with it - a spanner in the works of what we were all happily orchestrating.<p>&quot;A project&quot; is a demo we need to make next week, or a customer requirement the next release needs to address. It&#x27;s something the product needs to deal with - and PM decides whether this should impact dev.<p>It&#x27;s the job of PM to sort out the backlog&#x2F;timeline of the product so it hits the new eternal &quot;project&quot; requirement. Dev shouldn&#x27;t even have to be aware the project exists - they&#x27;ll maybe see their backlog change and just have to deliver on that as normal.<p>Obviously the reality is that they&#x27;re aware of the project once PM has accepted it, and you ask them to change their course - but dev shouldn&#x27;t directly care.

Wow, a lot of negativity here! I found the article to provide quite a helpful mental model.<p>Agile processes definitely provide some of the structure mentioned here, but I&#x27;ve found that they lack sufficient guidance on the optimal size of work chunks- this article provides a compelling case for work chunks (milestones) of a specific size, and that alone is quite valuable to me as a concept.

This is just Agile&#x2F;Scrum to me, which, if used right, is very effective, but it&#x27;s not easy to do it correctly in practice over long period of time.

I ignore so many of these nonsensical articles on here, but this one really got my goat. Is there someone out there that works on &quot;projects&quot; where the goals of the project are not delivering milestones? I&#x27;m probably just lost in the generic management babble.

Think of driving from point A to point B. A project is completing the journey. A milestone is like a major stopping point or identifying landmark that is unique and distinct. A mile marker is like a sprint story.

The ideas in the article are similar (in a good way) to Shape Up by Basecamp [0]. I once got so inspired by it I translated it into Russian, just to better understand what&#x27;s written :-) If you&#x27;re intereseted in the topic, I highly recommend investing some time and reading it.<p>[0] <a href="https:&#x2F;&#x2F;basecamp.com&#x2F;shapeup&#x2F;webbook" rel="nofollow">https:&#x2F;&#x2F;basecamp.com&#x2F;shapeup&#x2F;webbook</a>

Great engineering teams focus on problems over products or milestones.

Great engineering teams have great engineers. Nothing else matters.

ah, but will your mediocre team become a great engineering team by focusing on milestone, instead of projects? Nope, they won&#x27;t.

The core argument in the post makes no sense to me at all. Projects and milestones are <i>orthogonal</i> concepts.

It seems NASA understands the value of milestones <a href="https:&#x2F;&#x2F;blogs.nasa.gov&#x2F;webb&#x2F;2021&#x2F;12&#x2F;24&#x2F;key-milestones-after-liftoff&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.nasa.gov&#x2F;webb&#x2F;2021&#x2F;12&#x2F;24&#x2F;key-milestones-after-...</a>

If we stick to strict Project Management definitions, milestones are within a project.<p>A program (representing a strategic goal) can contain multiple projects big and small. Perhaps the author wants to convey programs which map to company or divisions strategic initiatives.

Isn&#x27;t this just scrum? Scrum is very popular.

This piece puts into words the way I manage personal projects!

If your projects are running without any milestones defined, I have very bad news for you and the managers you hire.

Projects are things that are easy to put on my resume.<p>Milestones, unless they look &quot;project like&quot; are a harder (though not impossible) sell. They complicate the narrative.<p>When I&#x27;m moving on, the thing I want to be able to talk about is what I accomplished or helped accomplished that delivered value.<p>At the end of the day when you&#x27;re being hired you&#x27;re basically selling one of two possibilities: things will get done and you will profit, or I will keep things earning you profit.

You know there is no I in team. I couldnt give a shit for team work or working with others even effectively I behave marginally and do enough to get along. I show up on time at meetings say the correct and currently fashionable buzz words but I focus on my own personal education and profitless side projects.