Live data from Hacker News

Great engineering teams focus on milestones instead of projects

rubick.com

41–50 of 93 posts

Re: Great engineering teams focus on milestones instead of projects

#41
post #40

> Estimating one to three weeks of work is easy 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…

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work.

If you estimated the lowest on multiple things - you got the one where you deviated the most.

If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

Re: Great engineering teams focus on milestones instead of projects

#42
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.

Re: Great engineering teams focus on milestones instead of projects

#43
post #40

> Estimating one to three weeks of work is easy 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…

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

This is but a different kind of a rat-race?

Re: Great engineering teams focus on milestones instead of projects

#44

If we stick to strict Project Management definitions, milestones are within a project. 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.

Which would be represented in OKRs. Honestly this article feels like using project management definitions without understanding where they are coming from.

Re: Great engineering teams focus on milestones instead of projects

#45

Earlier quoted context omitted.

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... This is but a different kind of a rat-race?

Code quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up.

Is that something that should've been caught in integration tests? Why did it pass review then?

As long as it's not a pattern, it's not a problem.

If something super severe happens - that's an organization-wide problem...

Re: Great engineering teams focus on milestones instead of projects

#46
post #40

> Estimating one to three weeks of work is easy 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 problem with Sprints is that they come with fixed events and associated ceremonies. If your 2 week task is slipping by 2 days you have to answer why in the retrospective. If you remove the sprint deadlines and make the retrospective etc. adhoc and mostly dev team initiated it takes away all the pressure while keeping monitoring/measurements.

Re: Great engineering teams focus on milestones instead of projects

#47
My high-functioning teams rarely had an extensive backlog, but many loose notes of what a long-term strategy could look like.

We had 1 mission at a time that we were gunning down— the outcomes of which were motivating, in/validating and gave us closure on an swath of planning and theory.

I see some similarity between these properties and the author’s idea of a milestone.

Re: Great engineering teams focus on milestones instead of projects

#48
post #40

> Estimating one to three weeks of work is easy 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…

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

That sounds like a horrible place to work!

Re: Great engineering teams focus on milestones instead of projects

#49
post #40

> Estimating one to three weeks of work is easy 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…

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.
Post reply on HN