Last week, Karri Saarinen, CEO of Linear, shared his frustration at what he called an internal DDoS attack at his company. His teams are producing so much with AI now that it’s become impossible to assess whether each feature, pull request or change is worth shipping. I’ve written about this here before. Saarinen admitted that if a feature can be created in 20 minutes, it feels ridiculous to hold an alignment meeting about it the next day. Multiply that by the roughly 1000 pull requests Linear is creating per day and you have a rare, vulnerable public admission from a tech company CEO that AI is overwhelming the team and driving the production and deployment of a lot of features that probably shouldn’t see the light of day. When everyone’s a builder, how do we build some value filters on all that output?

The “can we” vs “should we” argument is now on steroids

The only thing a working implementation of a feature proves when it’s complete is that something can be built, not that it actually belongs in the product. This isn’t to say that the staff at Linear or at every other company using AI to build and deploy is creating deliberately low-value work. On the contrary, everyone likely believes they are building useful, usable improvements to the product. It’s just that with the exponentially increasing amount of output, all of the organization’s resources, including its key decision makers (like the CEO in this case) are being stretched so thin there’s limited capacity to understand why something was made, review the data and decisions behind and then determine how to proceed. 

Prior to AI, we had, to some extent, the luxury of cognitive bandwidth to discuss what we believed was worth building. Those decisions went through a limited number of people usually but there were opportunities to present options to them, defend each one and then work with these stakeholders to decide what the team was going to build. Saarinen notes in his post that he restricted the internal release channel to limit team overlap and duplicate work. By his own admission, this helped him track what was changing but not whether all that work added up to meaningful change for the customers and the business. 

Don’t slow builders down. Spread the question, “Does a customer need this?”

The genie has left the bottle. Every company is using AI and has tasted the sweet nectar of exponential production capability. It’s going to be very difficult to reverse that trend. We shouldn’t try to slow our builders down. Instead, we should democratize the ability for every builder, product manager, engineer and designer to answer the question, “Does a customer need the thing that I am working on?” And, to follow that up with, “How will we know that?” 

At the executive level this means that leaders are responsible for coming up with a clear strategic direction for the organizations. They need to make that direction clear, obvious and accessible to everyone in the company. They need to assign success criteria to that strategy and ensure everyone understands how their specific remit ties up to that strategy. 

Once that’s defined, to tame what Saarinen called the “internal DDOS” attack that is choking companies’ abilities to sift through the glut of AI output, consider the following three suggestions:

1. Everyone can build. Not everyone can ship. The path to deployment should force the builder to go through evidence-based gates. Start small, deploying only on the builder’s own machine. Sanity check with the internal team. From there expand the release to a few internal or prospective users and then finally on to production. Moving through each gate requires evidence that must be captured and acknowledged. This controls scope by killing early ideas and experiments at the local level. This is a healthy culling of features that won’t deliver value. Every feature that clears a gate must meet the strategic bar set by leadership.
   
2. Make the “why” of every feature visible. In short, nothing goes live to production without a hypothesis and success criteria tied to the strategic goals. Anyone who builds a feature should be able to clearly say who the feature is for, why they need it and how this will impact the user and the business. This creates visibility for what each team or individual builder is working on reducing duplicate effort before code is written. In addition, any agent-based automations now have an objective outcome to check pre and post production against.
   
3. Stop measuring builders by the number of features shipped. Saarinen said it himself. Output does not equal value. If the organization pressures teams to release more the flood of useless features will continue. Incentives drive behavior. Reward your teams for bringing the company closer to its stated strategic goals and objectives. This way, teams are incentivized to cut features that don’t help the goals. They end up being a cost, not an achievement. With this incentive in place it becomes a lot easier to determine if the company, as a whole, is moving towards something beneficial.

What does the leader’s job become in the “everyone can build” world?

The leaders in your organization are not able to keep up with AI-powered production. They won’t review everything. Instead, they should be the authors of the company’s strategy, goals and the bets the org should take. They are in charge of establishing and enforcing the bar for success. This doesn’t mean they have to understand every pull request. It does mean they have to keep an eye on how the work that is being deployed is moving those needles. The middle layer of the organization, along with the individual contributors, become responsible for getting the company to those goals. They become the ones that check each team’s outputs and PR’s against the desired success criteria and help make the kill/pivot/persevere decisions.

If you don’t already read my free, bi-monthly newsletter, you should sign up for it over on Substack.