Skip to content
Engineering

The engineering culture of teams that ship every day

What separates startups that deploy 30 times a day from those stuck on weekly trains. It's not the tooling - it's six cultural choices.

Aakash Sisodiya1 min read
Close-up of circuit board components with shallow depth of field

I've worked at three startups that deployed 30+ times a day and four that struggled to ship weekly. The tooling was almost identical. The difference was always cultural.

1. Trunk-based development is not optional

Long-lived feature branches are the single biggest predictor of slow shipping. Once a branch lives more than 48 hours, the cost of integrating it grows super-linearly with every passing day.

# What a healthy day looks like
git switch main
git pull
git switch -c kai/fix-billing-rounding
# small change, 90 minutes of work
gh pr create --fill && gh pr merge --auto --squash

2. CI is sacred

If your CI takes longer than 8 minutes, you don't have continuous integration. You have a slow approval ritual. Every minute over 8 directly reduces deploy frequency.

3. Feature flags decouple deploy from release

Deploying code and releasing functionality are two different events. Conflating them is the root cause of "we ship on Thursdays" culture.

A simple flag system that respects users, environments, and percentages is enough - you do not need LaunchDarkly on day one.

4. Postmortems without blame, but with teeth

A culture of blameless postmortems falls apart if the action items never ship. The blameless part is for the people. The teeth are for the system.

5. Production access for everyone who builds for it

If your engineers can't read production logs without filing a ticket, they will optimize for not needing to read them - by avoiding edge cases. The result is software that's brittle in exactly the places customers notice.

6. The first deploy of the day belongs to the most junior person on the team

This sounds gimmicky but it's the most diagnostic culture metric I know. If a junior engineer can comfortably ship to production on day three, your deploy pipeline is healthy. If they can't, you're carrying invisible toil that only the senior people work around.

The teams that deploy every day weren't born that way. They built six small habits, in this order, over about six months. The tooling came last.

Frequently asked questions

  • If you have a real customer base, you should be deploying at least once per business day. Smaller, more frequent deploys are dramatically safer than batched weekly releases.
Share

Keep reading

All articles →

The weekly briefing

One curated email every Tuesday. Founder essays, engineering deep dives, and the week's most important startup news. No spam.

Comments are coming soon. In the meantime, share your thoughts on social.