No management needed: anti-patterns in early-stage engineering teams | Antoine Boulanger

Founders at seed or series A often think they need to manage engineers, but the real answer is to do nothing. The best use of a founder's time is building product and talking to users, not imposing management rituals on a small team. By staying hands-off you keep the team fast and focused.

Motivating engineers by forcing long hours, weekend standups, or constant status checks backfires. Those tactics drive away top talent who have choices and waste the founder's mental energy on symptoms rather than hiring people who are already self-motivated.

Hiring a manager too early adds a layer of coordination that doesn't exist yet. When a team is still figuring out what to build, a manager ends up creating "management work" - 1:1s, career coaching, ticket grooming - that distracts from product discovery. The article outlines three inflection points: the founding stage (5-6 engineers), the multi-team stage (10-15 engineers), and the early growth stage (20-50 engineers), showing why a single technical leader should stay in charge until the team grows large enough to need formal layers.

Copying Google's flashy management experiments is a mistake. Stick to the "node & postgres" of management: simple, well-known practices that don't consume engineering time. Use asynchronous status updates, keep Slack usage minimal, hold ad-hoc 1:1s, rely on a few flexible docs instead of heavy ticketing systems, and make everything transparent to eliminate unnecessary communication.

The actionable takeaways are to hire inherently motivated engineers, let go of bad hires quickly, avoid mandatory meetings, treat Slack as a tool not a crutch, run organic 1:1s, keep documentation lightweight, and practice extreme transparency. These tactics work up to about 20-25 engineers, after which more formal structures become necessary.