More work can mean less progress

Bigger is better, right?  Bigger company, more engineers, more product managers, more output.  We know that isn't reliably true, but "one more person" still feels like the obvious answer whenever the roadmap starts slipping.

Engineering teams have their own version of If You Give a Mouse a Cookie.  Add an engineer and you also add product decisions, design questions, code review, QA, management, priority negotiation, and another person who needs to understand why the work matters.

The communication surface grows especially quickly.  Five people have ten possible links between them.  Ten people have forty-five.  Cancel every meeting if you want; the coordination still shows up in planning, handoffs, reviews, and the Slack thread where six people discover they made three different decisions.

That doesn't mean smaller is always better.  A one-person team has no redundancy, and a sick day can stop everything.  The useful middle is enough people to absorb reality without swamping the rest of the organization.

Before hiring, find the actual constraint.  If customer work is waiting on decisions, review, or ownership, another engineer may simply give the bottleneck more work to hold.

I worked through the tradeoffs, including the team-size math, in "Bigger is not Better": https://huntersoftwareconsulting.com/posts/2026-09-06-bigger-is-not-better/

I recorded a short solo episode this week about the line between a hobby and a business.

It isn't whether the project makes a little money.  A hobby can make money.  It isn't whether you work hard on it, either; plenty of hobbies consume heroic amounts of time.

The useful distinction is who gets to direct the work.  A hobby can exist entirely for you.  A business eventually has to answer to customers, including the annoying questions: Do they have this problem?  Will they pay for the solution?  Do the economics still work once you count your own time?

The funny thing is that a healthy business often gets a bit boring.  You know who the customer is, what they buy, and how to deliver it repeatedly.  If you're constantly inventing another side project, you may be protecting the novelty at the expense of learning whether any one of them works.

Watch "Business vs. Hobby - Why Side Hustles Need Customers": https://www.youtube.com/watch?v=Yfehy6Pbaks

Kevin Walkup described a sales habit I wish more people used: occasionally send something useful with no ask attached.

Not a disguised meeting request.  Not "thought you might find this interesting" followed by four paragraphs about your product.  Just a useful article, observation, or introduction that helps the person on the other side.

Kevin compared it to making deposits instead of withdrawals.  He had prospects come back years later because he stayed useful and stayed top of mind without trying to force the timing.

This is close to how I think about give-first outreach.  You can still qualify, sell, and ask directly when the moment calls for it.  The relationship just shouldn't exist only when you want something.

There is a strategic benefit too.  To send something genuinely useful, you have to understand the customer's world well enough to recognize useful material.  That makes you better at the eventual sales conversation, even if that conversation happens three years later.

AI has made a lot of work cheaper.  It has not made all of that work worth doing.

This is one of the stranger traps I see right now.  A low-value task used to drop off the list naturally, because nobody wanted to spend a day on it.  Now somebody can say, "An agent can knock that out," and the task sneaks back onto the plan.

Except it still needs instructions.  It still needs review.  It still creates another artifact for somebody to understand, maintain, or unwind.  The cost moved out of building; it did not disappear.

Before delegating a task to AI, ask: if this comes back perfectly, what changes for the customer or the business?

If the honest answer is "nothing," do not automate it.  Delete it.  Save the tokens for the big, tangly priorities instead.

Ask the founder (or if you’re the founder, ask someone near you), product lead, and each engineer one question separately: what is the company's number-one priority this quarter?

Then count the answers.

If you get three or five different answers, you do not have a priority.  You have a stack of reasonable suggestions, and the team is spending its week negotiating between them one ticket at a time.

Do not answer that by adding another dashboard.  Pick the business outcome and work back from there. Name the person who can own the tradeoff, and let them lead the team down this determined path.

Ten minutes of uncomfortable answers can save months of very busy non-progress.

More work is easy to create.  Deciding what deserves to survive is the actual job. See you next week.

- Hunter