How I've run major projects (2025) | Hacker News Reader

How I've run major projects (2025)

benkuhn.net

131 pointsthomascountz28 comments

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

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.

Good thing AI is taking away two of those at the least. Now companies can just focus on Purpose.

None.

But it was kind of nice being able to pay my mortgage and my kid's college tuition.

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.

You play the hand you're dealt, or you get out of the game. Getting out of the game is always an option, of course. But you don't always have the ability to choose or change your cards.

You’re the one who dealt the cards! You’re the alleged (self-described) manager here. No wonder you got pushed around by somebody who was able to do their work. You seem to see yourself as the victim of circumstance rather than in control of anything.

Why the hostility? I didn't hire them. I didn't have the authority to fire them.

Hostility? What did I say that wasn't true?

They should probably have promoted the guy who was reading the book. 0% chance he'd let one of his reports make him do work that the report should've been doing themselves.

Of course you can't know that without knowing how valuable the employee's contributions are. If they're good, a good manager will walk by their cubicle a few times a day instead of firing them.

The kind of person who gets pushed around by their reports like this will end up walking by everyone’s cubicle a few times a day because they’re afraid to tell the bad employees why the good employee gets special treatment.

Read the guys story again. He wasn’t a manager. He was at best a babysitter.

If the guy reading novels is that valuable, fire the pushover manager and pay somebody $10/hr to walk by his cubicle.

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.

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'.

> “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.

Now AI is summarizing your daily progress from your commits and AI is writing the planning docs (with HITL). And version control makes it a historical record of your planning process. Keeping detailed planning docs doesn't take your whole day anymore and can be an integral part of any IC's workflow now.

CICD is a vast improvement over the manual deployments I was involved in. Usually those were on Friday nights and 10+ people had to wait their turn before deploying. Sometimes it only took a couple of hours; some deployments lasted until the morning.

Some projects, where the constraints are hard (immovable deadlines, inflexible scope, etc.) can still benefit from detailed estimation as far as possible. This way any problems or misalignments have a chance to come out early.

Most stuff I do that is long term isn't that critical and gets broken into reasonable size phases; the closest one is planned in detail, the next one has no major open questions, and the rest have a brief summary of what will be accomplished / what is the goal of that phase only.

That gets rid of a lot of the lack of flexibility of waterfall, and it does happen that priorities change a lot and many projects don't get to the latter phases (often, by definition/priority, the less "immediate fire" ones).

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.

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?

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.

The best project manager I ever had was a young woman from Russia. She came over as a student shortly after the wall fell. She was extremely hard working, very sharp, and spotted bullshit from miles away.

Legit. I think people spend too much on planning instead of focusing on getting to work and closer to the finished output. If you are fixated on a plan... good luck dealing with situations that throw you off piste.

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.

Reply on news.ycombinator.com