I was at a gathering of CTOs last week, talking about the antipatterns that make a brittle engineering organization. As a leader, you would never want to work (or create!) an organization where there is fear of conflict and lack of commitment in place of trust.
The challenge is if you are leading a five- to 10-person engineering startup, survival and speed are your North Star. You don’t have the luxury of time, endless resources, or capacity for large-scale cultural initiatives. What if you could create an organization that becomes stronger and more resilient when it is put under stress, as illustrated by Nassim Nicholas Taleb’s book “Antifragile: Things That Gain From Disorder”?
Greatness isn’t about implementing a complex framework; it’s about embedding high-leverage habits early. Here are the three low-cost, high-impact practices your startup team can adopt right now to build a foundation for future scaling.
1. Ruthless Prioritization, aka “Done Is Better Than Perfect”
When resources are tight, every minute counts. The enemy isn’t competition but scope creep and feature paralysis. Early years at Amazon were particularly good at single owners and iteration over perfection, as we were so lean that there was no one else to do the work, so we continued launching and iterating features and products.
- Single owners: For any given project or sprint, only one person should be the primary owner (the “single shovel”). They are responsible for producing the outcome, driving consensus, and saying no to extra features. This eliminates costly design-by-committee delays.
- Iteration over perfection: Before writing a line of code, ask, “What is the smallest possible slice of this that delivers measurable user value?” Cut the next nonessential thing. Your goal is rapid feedback cycles, not pristine code (yet).
- Skip unnecessary meetings: If a decision in a Slack thread could replace the meeting, cancel it. Protect your maker time fiercely.
2. High-Velocity, Low-Ceremony Communication
Miscommunication is the most expensive mistake a small team can make. You need clarity without the overhead of heavy documentation.
- The daily standup: Your 15-minute standup is a daily sync point for resolving dependencies and making immediate decisions. Status can be reported via email and Slack. The facilitator’s job for a standup is to end it with zero unresolved blockers and clear next steps for everyone.
- Eliminate silos: Regularly ask, “If one person got hit by a bus (or won the lottery), would the business stop?” Actively cross-train on key systems. This doesn’t mean everyone codes everywhere, but that system knowledge is a shared artifact, not a personal silo.
3. Invest in Operational Stability
A startup’s biggest threat to capacity isn’t tech debt; it’s unreliable infrastructure and repetitive manual tasks. You can’t afford to have your senior engineers spending hours fixing basic outages or running manual deploys.
- One-click deployment: This is nonnegotiable. If deployment is a manual, multistep process, it’s a huge capacity sink. Invest the time (or a small amount of money in a service) to make deployments boring, reliable, and one-click/automated.
- Runbook-lite: You don’t need a full wiki. For every critical service, create a single shared document (a “runbook-lite”) that answers only two questions: 1) How do I restart it? 2) Where are the logs? This helps everyone with basic operational troubleshooting.
- Postmortems: When an incident happens, focus on what allowed the mistake to happen, not who made the mistake. Keep postmortems short (30 minutes) and focus on one actionable item to prevent recurrence. This builds a culture of continuous learning and trust.
- One of my most memorable early Amazon postmortems involved a deployment engineer who was blamed for crashing the website by having a typo in the command line. In reviewing the deployment logs, it was revealed that she had entered a 200+ character command line over 300 times before that typo. That was when it was highlighted that we had a tooling problem, not a deployment engineer problem.
Takeaway
You are building the organization while building the product. Your constraints are your advantage, so focus on speed, clarity, and reliability. You’re not just surviving; you’re developing the muscle memory of a high-growth, great organization.