This is a good article. Not because it's got some crazy insights or radical suggestions - but because it's pragmatic and sensible advice for any project. It definitely resonates with my experience - the biggest risk is just losing focus or losing track of what you're meant to do.
It's refreshingly free of buzzwords and rigid "process" too!
It's interesting to take the counterfactual, what it looks like when large projects are run poorly. The answer often looks like:
* Poorly defined goals / definition of success
* Overly-complex plans, slowly executed against
* A focus on issues that aren't the real bottleneck
* Large cost and time overruns
* Project is eventually cancelled
I've had the interesting experience of watching the same type of "transformation" project run twice at similar companies. In the first case, the project was bogged down to the extent that I genuinely updated to believe it wasn't possible to achieve. In the second case, I saw incredible progress / pace with a much smaller team, pushing on all the key points with the right planning, and learned some lessons I wish I'd known on take 1.
Can't speak for ML training, but I absolutely love using the OODA loop as a simplification of the decision and operating pattern in competitive industries. Boyd really did put together an easy to understand framework to help describe where an organization/process needs to tighten up.
> Participants deeply understand the root goal and can autonomously choose the most important next things to work on
It didn't work that way on projects I led. Maybe everyone at Anthropic is a "10."
I was lucky when I had one person who could do that ("deeply understand the root goal and can autonomously choose the most important next things to work on"), who could take over if I went on vacation or got hit by a bus.
But I had reports who just wanted to work in their area of specialization, and had no curiosity whatsoever outside that. Or the guy who, no matter what I said, would never tell me when he had finished something - the only way I found out would be when I walked past his cube and saw him reading a science fiction book.
Don't tell me I should have just fired them, and gotten someone better. They did useful work, contributed to the project, and they were what the company had to work with. A big part of management is figuring out what people can do, want to do, are capable of doing in the future if encouraged.
Mostly really good. Because it’s HN I have a few quibbles:
What’s wrong with a daily synchronous call?
Some of this reads like micromanagement. Why does a project organizer need to spend lots of time tracking people, why aren’t they recording what they’re working on in a transparent manner?
> “Maintain a detailed plan for victory
A specific tool that I’ve found critical for staying oriented and updating quickly is a detailed plan for victory, i.e., a list of steps, as concrete as possible, that end with the goal being achieved.”
This reads a lot like Waterfall to me. This is what I was used to 20 years ago. The project manager wanted a daily email of my progress. We had a weekly meeting where everyone’s blockers were discussed. This took all day for complex projects.
The idea of writing down all the steps required, aka way too many steps, some people love to tell you all the ways things are impossible and "you will need to do X too". When after the fact you discover X wasn't important.
8 comments
[ 2.4 ms ] story [ 21.7 ms ] threadIt's refreshingly free of buzzwords and rigid "process" too!
* Poorly defined goals / definition of success
* Overly-complex plans, slowly executed against
* A focus on issues that aren't the real bottleneck
* Large cost and time overruns
* Project is eventually cancelled
I've had the interesting experience of watching the same type of "transformation" project run twice at similar companies. In the first case, the project was bogged down to the extent that I genuinely updated to believe it wasn't possible to achieve. In the second case, I saw incredible progress / pace with a much smaller team, pushing on all the key points with the right planning, and learned some lessons I wish I'd known on take 1.
It didn't work that way on projects I led. Maybe everyone at Anthropic is a "10."
I was lucky when I had one person who could do that ("deeply understand the root goal and can autonomously choose the most important next things to work on"), who could take over if I went on vacation or got hit by a bus.
But I had reports who just wanted to work in their area of specialization, and had no curiosity whatsoever outside that. Or the guy who, no matter what I said, would never tell me when he had finished something - the only way I found out would be when I walked past his cube and saw him reading a science fiction book.
Don't tell me I should have just fired them, and gotten someone better. They did useful work, contributed to the project, and they were what the company had to work with. A big part of management is figuring out what people can do, want to do, are capable of doing in the future if encouraged.
What’s wrong with a daily synchronous call?
Some of this reads like micromanagement. Why does a project organizer need to spend lots of time tracking people, why aren’t they recording what they’re working on in a transparent manner?
This reads a lot like Waterfall to me. This is what I was used to 20 years ago. The project manager wanted a daily email of my progress. We had a weekly meeting where everyone’s blockers were discussed. This took all day for complex projects.
The idea of writing down all the steps required, aka way too many steps, some people love to tell you all the ways things are impossible and "you will need to do X too". When after the fact you discover X wasn't important.