> 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.
Of course they should be fired if it’s been made clear that behavior is unacceptable (which it should be). Culture is what you let people get away with.
But seems like the company (and you) thought that was acceptable so who knows.
Out of curiosity what kind of "extra" incentives did you have in the project succeeding (e.g. bonus, promotion, or stocks)? And what kind of incentives did the direct reports have?
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.
> “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.
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!
Yeah the hardest thing is to focus intensely and have a strong vision for what exactly the output should be directionally. The second hardest is actually getting the project finished - that requires sustained intense focus.
Theres nothing more to it than that. Frameworks etc blah blah blah. Who cares. Get the work done.
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?
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.
This is surprising to me. The advice about what team members should be able to is the stuff I find agents least capable of doing, e.g. autonomously identifying the most important work and knowing when something is done.
> 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.
My current ratio is about 1.5 people in 10. The .5 is someone who knows what to do but doesn’t have the technical skill to do it.
Of course they should be fired if it’s been made clear that behavior is unacceptable (which it should be). Culture is what you let people get away with.
But seems like the company (and you) thought that was acceptable so who knows.
Out of curiosity what kind of "extra" incentives did you have in the project succeeding (e.g. bonus, promotion, or stocks)? And what kind of incentives did the direct reports have?
At a certain point cash isn’t an incentive. Autonomy, Mastery and Purpose become much bigger rewards. Check out Drive by Daniel Pink.
Seems too fairytale-esque to me.
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.
> “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.
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!
Yeah the hardest thing is to focus intensely and have a strong vision for what exactly the output should be directionally. The second hardest is actually getting the project finished - that requires sustained intense focus.
Theres nothing more to it than that. Frameworks etc blah blah blah. Who cares. Get the work done.
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?
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.
"Overly-complex plans, slowly executed against"
lol this usually happens when those leading the project have no vision and aren't ruthless about achieving a well-defined outcome state.
Having a vision is understated and very rare to find in people. Many people pretend/wish they had 'it'.
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.
There is tons of good advice. This blog post can be easily turned into a skill for agents.
This is surprising to me. The advice about what team members should be able to is the stuff I find agents least capable of doing, e.g. autonomously identifying the most important work and knowing when something is done.