How to Manage a 4-Person Engineering Team Without Becoming a Manager

A 4-person engineering team is the most overlooked unit of management in startups.

Big enough that the tech lead can't write all the production code. Small enough that hiring an EM kills velocity and adds a layer of communication overhead the team can feel within a week. Most startup engineering org charts skip from "founding engineer" straight to "Director of Engineering at twenty people" — and pretend the territory in between doesn't have its own playbook.

It does. I've run 3–5 person engineering teams at PopSocial, at InsideTrack during a phase transition, and most recently across two fractional engagements with AI-native startups. The patterns hold. Five rituals that work at this size, three traps to avoid, and the signal that tells you it's time to evolve.

Why 4 is the awkward number

One engineer is a co-founder. Two is a duo. Three is a tight team where everyone communicates by osmosis. By four, osmosis breaks. Engineer A doesn't know what engineer C is working on, two of them ship overlapping changes that have to be reconciled in code review, and the lead starts feeling like they're spending half the day on coordination that didn't exist last quarter.

This is the moment most founders panic and either hire an EM or default to the worst option: announce themselves as the EM and stop coding. Both miss the point. At four engineers, you don't need a manager. You need cadence. Four people running on shared rhythms perform like five-and-a-half. Four people without rhythm perform like three.

The five rituals that work at this size

1. Weekly 1-on-1s, 30 minutes

The single highest-leverage 30 minutes on your calendar. Three sections, in this order: what's blocking you, what's bothering you, what are you working on. The first two are non-negotiable; the third is often obvious from context and can be skipped.

Why this works at 4 engineers specifically: the alternative is finding out your strongest engineer is unhappy via their resignation email. At 20 engineers, you need a layer of management to surface this. At 4, the layer is you, weekly, in 30 minutes.

2. Async daily check-in, in Slack, text only

Three lines per engineer per day, in a single thread. What I shipped yesterday. What I'm shipping today. What's blocking me. No video. No meeting. Twenty seconds to write, two minutes for the team to read.

The crucial constraint: text only. Standups by video at small scale are a tax. The same information conveyed in text takes a tenth of the time and creates a written record you can search later. The team I most recently ran did standups this way for a year and never once felt the lack of synchronous time.

3. Friday demos, 15 minutes

Once a week, on Friday, the team gathers for fifteen minutes. Each engineer shows the most interesting thing they shipped that week. Could be a feature, a refactor, a bug fix with a great post-mortem, anything they're proud of.

The point is not status reporting. The point is visibility — engineers seeing each other's work, picking up patterns, noticing where someone has built something useful that another engineer didn't know existed. At 4 engineers, this is also the highest-bandwidth moment of pure team identity in the week.

4. Quarterly written goal docs, one per engineer

Twice a year is too infrequent at startup pace; weekly is theatre. Quarterly hits the right rhythm. One page per engineer: three goals, written by them, reviewed with you, signed by both at the end of the meeting.

Three goals, not five. They span the three buckets of work: ship something hard, learn something specific, contribute to the team in a defined way. At the end of the quarter you sit back down, look at the doc, and have a real conversation about what happened. This is how you compound performance at small scale without bureaucracy.

5. Monthly retros: what's broken

One hour, last Friday of the month, no calendar invite needed beyond the recurring slot. Single question: what's broken about how we work? Not what's broken in the code. What's broken in the process, the tools, the meetings, the deploys, the comms.

You take notes. The next week, you fix the one thing the team most wanted fixed. The team feels heard, the process actually improves, and the next month's retro builds on a smaller list of complaints. After six months of this, the team's operating practices are visibly better than every other 4-person team you'll ever see.

Three traps to avoid

Trap 1: Hiring an engineering manager at four engineers. The marginal cost is enormous and the marginal value is small. The EM at this scale will inevitably either become a tech lead in disguise (in which case you should have just promoted internally) or spend their day creating process to justify their own existence. Wait until six engineers. Possibly eight.

Trap 2: The lead going full-time managing. This is the most common pre-Series-A founder mistake. You stop shipping code, the team's velocity drops 30% within a month because the senior IC just left the keyboard, and you spend the dropped time on meetings the team didn't want anyway. The right load at this stage is 70/30 IC/management. Below 50/50 management, you're failing the team.

Trap 3: Rituals that drift into status meetings. Every ritual on the list above can collapse into "tell me what you're working on so I know" if you're not careful. The signal a ritual has drifted: the engineers stop volunteering things, you start asking direct questions, and the meeting feels heavy. When that happens, kill the meeting that week. Bring it back next week with explicit re-framing.

The transition signal at six engineers

The model in this post breaks somewhere between five and seven engineers. The exact number depends on team-shape and product-shape but the symptoms are consistent: 1-on-1s start eating your whole Tuesday, the async standup thread is too long to read in two minutes, and the Friday demo runs over because four-out-of-six demos already feels rushed.

The transition is to a sub-team structure: two ICs, two ICs, with a tech lead per group. You're now managing the leads, not the ICs. Different rituals, different cadence, different challenges — and a whole different post.

The good news: getting the 4-person ritual stack right is the foundation everything that follows builds on. The teams that hit Series A with healthy engineering culture are the teams that ran disciplined rituals at four. The ones who skipped the discipline at small scale are the ones spending the year after Series A re-installing it under pressure.

Hiring at the 4-person team size

One topic the rituals don't cover: every hire at this size is a culture-level decision, not just a skill match. At twenty engineers a single wrong hire is a 5% problem. At four, the wrong hire is a 25% problem and you'll feel the consequences inside six weeks.

The implication: the bar for hires 3, 4, and 5 should be unreasonably high. Not "great engineer." Not "really senior." It needs to be: "this person makes the team meaningfully better the day they start, in ways the existing engineers couldn't have produced themselves." Anything less and you're hiring someone who needs to be brought up to the existing team's level, which the existing team will resent at this scale.

Concretely, what's worked for me at this size:

• Every existing engineer is a hard veto. No exceptions. If any of the three engineers on the team has a strong reservation about a candidate, the candidate doesn't get hired, regardless of what the founder thinks. This kills political pressure and keeps the team's culture in their own hands.
• Take-home → trial week → offer. A 3-day paid trial week between final interview and offer is the most predictive single signal at this scale. You're not hiring for resume; you're hiring for whether they fit the team's flow.
• The fifth hire is the one to slow down on. Going from four to five is when team dynamics noticeably shift. Most founders rush this hire. The team performs better at four for an extra month than at five with the wrong addition.

Remote vs in-person at this size

Brief note because the rituals work differently in each setup. Remote 4-person teams need more structure, not less — the async daily check-in becomes load-bearing instead of nice-to-have, and the Friday demo is the single thing that holds team cohesion together. Skip the demo for two weeks in a row and you'll feel the drift.

In-person 4-person teams can run looser. The async standup can be optional because the team is already overhearing each other's progress. The Friday demo is still worth doing but it has less work to carry.

Hybrid is the worst of both worlds at this size. If you can choose one or the other, choose. If you can't, default to remote-first rituals — they degrade gracefully when half the team is in the room and the rest are remote. In-person-first rituals don't.

One last note on cadence. Founders sometimes ask whether all five rituals run from week one with a new hire. The answer is yes — the new engineer joins the existing rhythm rather than the team adapting to them. New hires actually onboard faster when they're plugged into a working ritual stack on day one, because the rituals make the team's expectations legible. Skip the rituals during onboarding and the new hire spends three weeks figuring out norms that should have been transmitted in week one.