I’ve spent two decades inside software teams that couldn’t ship a goddamn thing, and a handful that moved so fast it felt like a continuous deployment pipeline for the soul. The difference was never the tech stack. It was never the funding. It was never the presence or absence of a foosball table. The difference was a set of invisible, self-reinforcing organizational patterns—what I’ve come to call the sociotechnical event loop. When that loop is blocked, you get a startup that talks about shipping. When it’s unblocked, you get a startup that actually ships.
This isn’t a motivational post. I’m not going to tell you to “move fast and break things.” That’s a bumper sticker for people who’ve never had to fix a production database at 2 a.m. Instead, I’m going to dissect the hidden architecture of team behavior—the race conditions, blocking calls, and deadlocks that live not in your codebase, but in your standups, your planning meetings, and your Slack channels.
The Sociotechnical Event Loop: Why Your Team Is Stuck in a Blocking Call
In software, a blocking call is a function that halts execution until some external resource responds. Your team has its own version. It’s the meeting where no one will admit they don’t understand the requirements. It’s the pull request that sits open for three weeks because the reviewer is “too busy.” It’s the architecture decision that gets deferred to a committee that never meets. Each of these is a blocking call on your team’s ability to deliver value. And just like in code, a single blocking call in a critical path can freeze the entire system.
Startups that ship have learned to identify their organizational blocking calls and either make them asynchronous or eliminate them entirely. They treat decision latency as a bug, not a feature of “being thorough.” They understand that a bad decision today, corrected tomorrow, is cheaper than a perfect decision made three months late. The market is a ruthless integration test, and it doesn’t wait for your architecture review board to convene.
The Decision Queue and Its Discontents
Every team has a decision queue. In a healthy system, this queue is processed with predictable throughput. Decisions flow from “proposed” to “decided” in hours or days, not weeks. In a talking-about-shipping startup, the decision queue is a black hole. Items enter, but nothing emerges. The team compensates by building elaborate scaffolding around the void—more meetings, more documents, more alignment sessions—none of which actually resolve the underlying block.
I once consulted for a company that had spent four months debating whether to use a monorepo or polyrepo. Four months. The engineers were writing design docs, running benchmarks, and having philosophical debates about dependency management. Meanwhile, the product they were supposed to be building hadn’t shipped a single feature. The decision queue was blocked, and the entire team was in a spinlock, burning CPU cycles on nothing.
The fix wasn’t technical. It was cultural. We flipped a coin, picked a repo structure, and agreed to revisit the decision after shipping three features. The team shipped more in the next two weeks than they had in the previous four months. The sociotechnical event loop was unblocked.
Legacy Systems Are People, Too
In code, a legacy system is something that’s hard to change because nobody fully understands it, and the original authors are long gone. In teams, legacy systems are the unwritten rules, the tribal knowledge, and the “that’s how we’ve always done it” reflexes that accumulate over time. A startup that talks about shipping is usually running on a legacy operating system of fear: fear of breaking things, fear of looking stupid, fear of being blamed.
I call this the Blame-Driven Development (BDD) pattern. In BDD, every decision is optimized not for customer value, but for personal defensibility. Engineers write overly complex solutions because if it fails, they can point to the design doc and say, “See? We thought of everything.” Product managers add endless acceptance criteria to avoid being held responsible for a missed edge case. The result is a system so over-engineered that it never leaves staging.
Startups that ship have replaced BDD with what I call Learning-Driven Development (LDD). In LDD, the primary goal of shipping is to get a signal from reality. A failed experiment isn’t a career-limiting move; it’s a data point. The team’s psychological safety is high enough that people can say, “I don’t know, let’s find out,” without fearing a retroactive performance review. This isn’t soft-skills fluff. It’s a hard requirement for any system that needs to adapt quickly. A team without psychological safety is like a distributed system where every node is running a different consensus algorithm. It will never converge on a decision.
Refactoring the Blame Culture
Refactoring a team’s culture is harder than refactoring code, because you can’t just write a unit test to confirm the behavior changed. But the principles are the same: make small, observable changes; get feedback; iterate. Start with the retrospective. If your retros are a polite recitation of what went well and what could be improved, with no concrete action items, you’re not doing a retro. You’re doing a group therapy session that nobody asked for.
A shipping team’s retro is a debugging session. You identify the root cause of the most painful failure, you assign an owner, and you fix it before the next sprint. Not a process document. Not a “let’s be more careful next time.” A real, observable change to how the team works. Maybe it’s a new linting rule. Maybe it’s a change to the on-call rotation. Maybe it’s telling the CTO to stop joining standup and asking “status” questions that make everyone defensive. Whatever it is, it’s a code change to the team’s operating system.
Race Conditions in the Standup
A race condition in software happens when two processes access shared data and the outcome depends on the order of execution. In teams, race conditions happen when multiple stakeholders compete for the same resource—usually engineering attention—without a clear priority mechanism. The result is thrashing: context switching so severe that nothing gets finished.
I’ve seen startups where the CEO, the VP of Sales, and a key customer all have direct access to individual engineers. They ping them on Slack, tap them on the shoulder, and inject “urgent” requests into the sprint. The engineers, trying to be helpful, context-switch constantly. The sprint board becomes a work of fiction. The team is busy, but nothing ships. This is a classic race condition: multiple uncoordinated writers to a shared resource, with no mutex or semaphore in sight.
The fix is a priority queue with a single gatekeeper. In practice, this means a product manager or engineering lead who says “no” or “not now” with the authority of the entire team behind them. It’s not about being a jerk. It’s about protecting the team’s ability to execute. Without a gatekeeper, the team’s attention is a public good that gets tragically overconsumed.
The Cost of Context Switching
Context switching isn’t just annoying. It’s computationally expensive. Research on task switching shows that it can take over 23 minutes to fully regain focus after an interruption. If your engineers are getting interrupted three times a day, they’re losing over an hour of productive time. That’s a 12.5% tax on your engineering capacity, and it compounds. The startup that ships protects its engineers’ focus like a scarce resource, because it is one.
The Synchronous Standup Antipattern
Daily standups are supposed to be a quick sync. In practice, they often become a blocking call that wastes 30 minutes of every engineer’s morning. The standup is a synchronous operation in an otherwise asynchronous system. It forces everyone to be available at the same time, which is especially painful for remote teams across time zones.
Shipping teams replace synchronous standups with asynchronous updates in a shared channel. They use the freed-up time for actual collaboration: pair programming, design reviews, or just uninterrupted deep work. The standup becomes a written log, not a performance. If you need a meeting to find out what your team is doing, you have a visibility problem, not a scheduling problem.
The Deployment Pipeline as a Sociotechnical Mirror
Your CI/CD pipeline isn’t just a tool. It’s a mirror reflecting your team’s actual behavior. A pipeline with flaky tests, manual approval gates, and deployment windows that nobody respects is a symptom of a team that doesn’t trust its own work. A clean, fast, reliable pipeline is a sign of a team that has invested in quality and automation—not just in code, but in process.
I’ve seen teams spend months “setting up CI/CD” without ever shipping to production. They’re optimizing a system that doesn’t deliver value. It’s like tuning a race car engine while the car is still on cinder blocks. The shipping team’s approach is different: they get a minimal pipeline working, deploy something—anything—to production, and then improve the pipeline based on real feedback. The pipeline is a product, and the team is its first user.
Flaky Tests Are a Cultural Problem
Flaky tests are often treated as a technical nuisance. They’re not. They’re a signal that the team tolerates unreliability. When a test fails intermittently, a shipping team treats it as a P0 bug and either fixes it or deletes the test. A talking-about-shipping team adds it to the “flaky test quarantine” and learns to ignore the red build. Over time, the build is always red, and nobody trusts it. The pipeline becomes a dead letter box. The team has trained itself to ignore failure signals, which is exactly the opposite of what a healthy sociotechnical system should do.
Architecture as a Social Construct
Conway’s Law states that organizations design systems that mirror their communication structure. I’d add a corollary: teams that can’t communicate directly will produce systems that can’t communicate directly. If your backend team and frontend team are in separate silos, you’ll end up with a brittle API contract that nobody wants to change, because changing it requires a cross-team meeting that takes three weeks to schedule. The architecture becomes a fossilized record of past organizational dysfunction.
Shipping startups invert this. They design the team structure to match the desired architecture. If they want a modular, loosely coupled system, they create small, autonomous teams with clear ownership boundaries. They use internal APIs not just in code, but in how teams communicate: well-defined interfaces, explicit contracts, and a shared understanding that you don’t break the contract without talking to the other team first. This is the sociotechnical equivalent of microservices done right.
The Two-Pizza Rule, Revisited
Amazon’s two-pizza rule—teams should be small enough to feed with two pizzas—isn’t about catering. It’s about minimizing communication overhead. In a team of n people, the number of communication channels grows as n(n-1)/2. A team of 6 has 15 channels. A team of 12 has 66. The talking-about-shipping startup ignores this math and creates “cross-functional squads” of 15 people, then wonders why nothing gets decided. The shipping startup keeps teams small and gives them clear, independent missions. The communication overhead stays manageable, and decisions happen at the edge, not in a centralized bottleneck.
FAQ: Diagnosing Your Team’s Shipping Blockers
How do I know if my team is in a blocking call?
Look for decisions that have been “in discussion” for more than a week with no resolution. Look for pull requests that have been open for more than two days without a review. Look for meetings where the same topic is discussed repeatedly without a clear owner or deadline. Each of these is a blocking call. The fix is to assign a single decision-maker, set a hard deadline, and make the decision with the information available. If it’s wrong, you’ll learn and correct. Indecision is a decision to do nothing, and it’s the most expensive option.
What’s the difference between a good process and bureaucratic overhead?
A good process reduces the cognitive load on the team and increases predictability. Bureaucratic overhead increases cognitive load and creates busywork. The test is simple: if you removed the process tomorrow, would the team ship faster or slower? If faster, it’s overhead. If slower—because quality would drop or coordination would break—it’s a good process. Be honest. Most “process” in startups is just anxiety made visible.
How do we stop the CEO from injecting urgent requests directly to engineers?
This is a boundary problem. The CEO has legitimate needs, but the current communication pattern is creating a race condition. The solution is to give the CEO a better interface: a single point of contact (usually the engineering lead or product manager) who triages requests and provides visibility into when they’ll be addressed. The key is to make this interface faster and more reliable than going directly to engineers. If the CEO gets a clear answer and a predictable timeline, they’ll stop bypassing the system. If they don’t, they’ll keep doing end-runs. The interface has to be better than the workaround.
What if our team is too small to have dedicated roles like product manager or engineering lead?
Then someone wears multiple hats, but the functions still need to exist. The priority queue gatekeeper might be the same person who writes code, but they need explicit authority to say “no” and the team’s agreement to respect that. In very small teams, this can be a rotating role. The important thing is that the role exists and is acknowledged. Without it, you’re back to the race condition.
Conclusion: The Sociotechnical Refactor
The difference between a startup that ships and one that talks about shipping isn’t talent, funding, or luck. It’s the health of the sociotechnical event loop. It’s the ability to identify and remove blocking calls, refactor legacy cultural patterns, prevent race conditions, and design team structures that enable flow rather than impede it.
This is the real engineering work. The code is the easy part. The hard part is debugging the human system that produces the code. Start treating your team’s culture with the same rigor you apply to your architecture, and you’ll be amazed at how fast you can ship. Or don’t, and keep talking about it. The market will eventually make the decision for you, and it’s not known for its patience.
