The tool decides the org chart

I went to a talk at Stripe Sessions recently where the Collison brothers sat down with Daniel Gross and Nat Friedman. They covered a lot of ground: AI capex as a share of global GDP, agents as economic actors, the aesthetics of data centers, and more. At one point, Nat was talking about his time at GitHub and what lets organizations move fast. His point was that tools drive company culture far more than people realize.

He gave an example from Meta. They had a labeling tool that was cumbersome, with lots of approvals and friction to spin up a new task. As a result, nobody fired off small labeling jobs. People bundled many tasks into one big run, did them less often, and structured their work around the fact that labeling was expensive. If a tool is hard to use, the org orients around the tool being hard.

There are a ton of instances where this is obvious once you see it. Slow CI means feature flags everywhere and long-lived branches. Painful deploys mean release trains and change-review boards. A clunky CRM means a sales ops team whose job is mostly translating between the CRM and reality. Each is a rational adaptation to a sharp edge in the tooling.

His next point was that as individual processes get harder, work becomes harder to coordinate. It gets chopped into smaller pieces so smaller teams can own them. Your team architecture ends up mirroring your software architecture, or your implementation architecture.

You can't desprawl the processes without desprawling the team, which deadlocks most large organizations into mediocrity. You need to make individual contributors feel like superheroes who can control and contribute to many different surfaces at once.

You can map this frame directly onto enterprise software implementation. The tooling most implementation teams run on is a patchwork of Word docs, Slack threads, Zoom recordings, Salesforce records, spreadsheets, and Jira tickets that weren't designed to talk with each other and don't. Every artifact is expensive to produce, expensive to review, and expensive to handoff.

That's where the handoff culture comes from. Discovery, requirements capture, solution architecture, and build each get their own owner, their own deliverable, and their own gate between phases. From the inside this looks like specialization and rigor; but in actuality it resembles Nat’s labeling tool at Meta, where work is getting bundled into infrequent batches to make the painful thing tolerable rather than the underlying work good.

If you have spent time inside a mature SI firm, you can see how deep this goes. There are dedicated positions and incredibly well-developed processes for all the different handoffs between teams. From sales to delivery, then from discovery to build, then from build to deployment. Roles emerge like engagement manager and PM whose job descriptions, as practiced today, are largely a product of antiquated processes. The PM who spends Thursday afternoon Slacking the lead architect for status before writing Friday's report is doing work that exists only because the information is sprawled across Jira, Slack, and call recordings.

Handoffs aren’t a feature of the work, they are a tax that firms pay due to lack of standardization. Discovery insights don't carry cleanly into requirements, requirements don't carry cleanly into the build, and the senior consultant who understood the client's business is three projects away by the time the implementation team hits the question that needed her context.

Handoff culture is a rational response to old tooling, and like most rational responses to constraints, it stops being rational when the constraint lifts. Agents can now pull context across everything that's relevant: SOWs, call recordings, Slack, Jira, spreadsheets, and that opens the door to rethinking the tooling, roles, and process from the ground up. This is what we spend most of our time on at Datafruit — trying to understand how we can better organize people around implementations and empower them to contribute across all the relevant surfaces.

The inheritors of a working system are reluctant to break it. The process feels load-bearing because it has been load-bearing. I'd bet that the implementation teams of the next ten years will look much less like a relay race and more like a basketball team where everyone can handle the ball, read the floor, and contribute wherever the play breaks.